From owner-mpls@UU.NET  Tue Aug  1 12:02:14 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17829
	for <mpls-archive@lists.ietf.org>; Tue, 1 Aug 2000 12:02:14 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjajo03240;
	Tue, 1 Aug 2000 16:01:11 GMT
Received: by mail-control.mail.uu.net 
	id QQjajo25481
	for mpls-outgoing; Tue, 1 Aug 2000 16:00:46 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjajo25242
	for <mpls@mail-control.mail.uu.net>; Tue, 1 Aug 2000 16:00:41 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjajo27333
	for <mpls@uu.net>; Tue, 1 Aug 2000 12:00:28 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjajo06147
	for <mpls@uu.net>; Tue, 1 Aug 2000 16:00:11 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA04511
	for mpls@uu.net; Tue, 1 Aug 2000 12:00:10 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjajn23316
	for <mpls@mail-control.mail.uu.net>; Tue, 1 Aug 2000 15:59:36 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjajn27016
	for <mpls@UU.NET>; Tue, 1 Aug 2000 11:59:10 -0400 (EDT)
Received: from ogma.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ogma.cisco.com [144.254.74.39])
	id QQjajn01268
	for <mpls@UU.NET>; Tue, 1 Aug 2000 15:58:55 GMT
Received: from europe.cisco.com (europe.cisco.com [144.254.52.73])
	by ogma.cisco.com (Postfix) with ESMTP
	id D38BA1FE; Tue,  1 Aug 2000 17:58:53 +0200 (MET DST)
Received: from flefauch-8kcdt.cisco.com (sj-dial-2-164.cisco.com [10.19.226.165])
	by europe.cisco.com (8.8.8+Sun/8.8.8) with SMTP id RAA29820;
	Tue, 1 Aug 2000 17:58:47 +0200 (MET DST)
Message-Id: <4.0.2.20000801113940.02298700@europe.cisco.com>
X-Sender: flefauch@europe.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 
Date: Tue, 01 Aug 2000 11:51:45 +0200
To: Lou Berger <lberger@labn.net>
From: Francois Le Faucheur <flefauch@cisco.com>
Subject: RE: Two last calls (draft-ietf-mpls-diff-ext-06.txt)
Cc: Francois Le Faucheur <flefauch@cisco.com>,
        Shahram Davari <Shahram_Davari@pmc-sierra.com>, mpls@UU.NET
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-mpls@UU.NET
Precedence: bulk

Lou,

>>We have agreed on an "escape code" above (the first "SHOULD") which allows 
>>one to maintain whatever flavor of "standard, non-DS, LSP" he/she liked. I 
>>think this is all the Diff-Serv spec probably needs to say and would 
>>prefer to avoid having to mention in any way QoS support which were 
>>pre-Diff-Ext. So I'd like to leave out the new recommendation.
>>
>>In any case, if a statement about Override option was to be included, I 
>>would argue that it should be a MAY and not a MUST.
>
>I believe I said "SHOULD" not MUST. 

You did say SHOULD, and I did mean that "it should be a MAY and not a SHOULD".

> I'd be fine with a MAY.

Then, can we agree on the principles of this "compromise" position?  i.e.:
	- The text would say that when there is RSVP signaling without the Diff-Serv object, the LSR SHOULD (instead of MUST) interpret this as a request for an "E-LSP using Preconfigured EXP<-->PHB Mapping".
	- the text would say that an implementation MAY include an option that overrides this.  When this "override option" is set, the LSR then treats LSPs signaled without the DiffServ object as standard, non-DS, LSPs.

If yes, I'll propose exact wording to reflect this.

Thanks

FRancois

_________________________________________________________________
Francois Le Faucheur   
Development Engineer, IOS Layer 3 Services 
Cisco Systems 
Office Phone:   	+33 4 92 96 75 64
Home Office Phone:     +33 4 92 94 00 78
Mobile :               +33 6 89 108 159
Vmail:                 +33 1 58 04 62 66
Fax:                   +33 4 92 96 79 08
Email:          	flefauch@cisco.com
_________________________________________________________________
Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - France
_________________________________________________________________ 



From owner-mpls@UU.NET  Tue Aug  1 14:08:10 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14941
	for <mpls-archive@lists.ietf.org>; Tue, 1 Aug 2000 14:08:10 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjajw19844;
	Tue, 1 Aug 2000 18:07:12 GMT
Received: by mail-control.mail.uu.net 
	id QQjajw10408
	for mpls-outgoing; Tue, 1 Aug 2000 18:06:27 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjajw10395
	for <mpls@mail-control.mail.uu.net>; Tue, 1 Aug 2000 18:06:23 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjajw03004
	for <mpls@uu.net>; Tue, 1 Aug 2000 14:05:54 -0400 (EDT)
From: Ted44tedT@netscape.net
Received: from imo-d06.mx.aol.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imo-d06.mx.aol.com [205.188.157.38])
	id QQjajw18834
	for <mpls@uu.net>; Tue, 1 Aug 2000 18:05:53 GMT
Received: from Ted44tedT@netscape.net
	by imo-d06.mx.aol.com (mail_out_v27.12.) id 1.ec.96b86 (16216)
	 for <mpls@uu.net>; Tue, 1 Aug 2000 14:05:48 -0400 (EDT)
Received: from  netscape.com (aimmail10.aim.aol.com [205.188.144.202]) by air-in01.mx.aol.com (v75_b3.11) with ESMTP; Tue, 01 Aug 2000 14:05:48 -0400
Message-ID: <743C92B3.3DD92558.02882A9A@netscape.net>
Date: Tue, 01 Aug 2000 14:07:19 -0400
To: mpls@UU.NET
X-Mailer: Franklin Webmailer 1.0
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi, 

I have a question about RSVP LSP:

if we have a LSP like below:

A--LER1--LSR--LER2--B

A,B are none rsvp nodes. LER1, LSR and LER2 are RSVP nodes. 
if LSP is setup from A to B, what happened to LER1, LSR and LER2?

Is there a RSVP LSP established from LER1 to LER2? or they just forward sessions without another RSVP LSP setup?


Thanks in advance
John

----------
Get your own FREE, personal Netscape Webmail account today at http://home.netscape.com/webmail/


From owner-mpls@UU.NET  Tue Aug  1 16:42:14 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03684
	for <mpls-archive@lists.ietf.org>; Tue, 1 Aug 2000 16:42:13 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjakg18640;
	Tue, 1 Aug 2000 20:41:06 GMT
Received: by mail-control.mail.uu.net 
	id QQjakg17032
	for mpls-outgoing; Tue, 1 Aug 2000 20:40:30 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjakg17010
	for <mpls@mail-control.mail.uu.net>; Tue, 1 Aug 2000 20:40:18 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjakg17761
	for <mpls@UU.NET>; Tue, 1 Aug 2000 16:39:57 -0400 (EDT)
Received: from brick.setuidzero.org by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: brick.setuidzero.org [209.183.207.172])
	id QQjakg18527
	for <mpls@UU.NET>; Tue, 1 Aug 2000 20:39:26 GMT
Received: from ebrookhousew2k (clovertech02.clovertech.com [209.122.17.226] (may be forged))
	by brick.setuidzero.org (8.9.3/8.8.7) with SMTP id PAA04798;
	Tue, 1 Aug 2000 15:37:50 -0400
Message-ID: <007601bffbf8$72d97ba0$960ea8c0@ebrookhousew2k>
From: "Edward Brookhouse" <ebroo@setuidzero.org>
To: <Ted44tedT@netscape.net>, <mpls@UU.NET>
References: <743C92B3.3DD92558.02882A9A@netscape.net>
Subject: Re: 
Date: Tue, 1 Aug 2000 16:38:27 -0400
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.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Just making sure I understand the scenario, do you mean that you are
stitching the two LSP's together across and LSR?

If not, would this be more like...

A - LIR-TLSR-LER-B

    LIR= Label Ingress Router
   TLSR=Transit Label Switch Router
    LER=Label Egress Router

Just making sure I caught what you were asking.

Edward Brookhouse
Greenwich Technology Partners
ebrookhouse@greenwichtech.com


----- Original Message -----
From: <Ted44tedT@netscape.net>
To: <mpls@UU.NET>
Sent: Tuesday, August 01, 2000 2:07 PM


> Hi,
>
> I have a question about RSVP LSP:
>
> if we have a LSP like below:
>
> A--LER1--LSR--LER2--B
>
> A,B are none rsvp nodes. LER1, LSR and LER2 are RSVP nodes.
> if LSP is setup from A to B, what happened to LER1, LSR and LER2?
>
> Is there a RSVP LSP established from LER1 to LER2? or they just forward
sessions without another RSVP LSP setup?
>
>
> Thanks in advance
> John
>
> ----------
> Get your own FREE, personal Netscape Webmail account today at
http://home.netscape.com/webmail/
>



From owner-mpls@UU.NET  Tue Aug  1 16:46:22 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04170
	for <mpls-archive@lists.ietf.org>; Tue, 1 Aug 2000 16:46:21 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjakh21259;
	Tue, 1 Aug 2000 20:45:41 GMT
Received: by mail-control.mail.uu.net 
	id QQjakg17475
	for mpls-outgoing; Tue, 1 Aug 2000 20:44:50 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjakg17458
	for <mpls@mail-control.mail.uu.net>; Tue, 1 Aug 2000 20:44:38 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjakg18530
	for <mpls@uu.net>; Tue, 1 Aug 2000 16:44:32 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88])
	id QQjakg20339
	for <mpls@uu.net>; Tue, 1 Aug 2000 20:44:01 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id NAA22627
	for <mpls@uu.net>; Tue, 1 Aug 2000 13:44:16 -0700 (PDT)
Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id QAA11751 for mpls@uu.net; Tue, 1 Aug 2000 16:44:00 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjajv26928
	for <mpls@mail-control.mail.uu.net>; Tue, 1 Aug 2000 17:45:59 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjajv29444
	for <mpls@uu.net>; Tue, 1 Aug 2000 13:45:57 -0400 (EDT)
Received: from web5404.mail.yahoo.com by wodc7mr1.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: web5404.mail.yahoo.com [216.115.106.142])
	id QQjajv04016
	for <mpls@uu.net>; Tue, 1 Aug 2000 17:45:57 GMT
Message-ID: <20000801174556.15456.qmail@web5404.mail.yahoo.com>
Received: from [132.177.119.129] by web5404.mail.yahoo.com; Tue, 01 Aug 2000 10:45:56 PDT
Date: Tue, 1 Aug 2000 10:45:56 -0700 (PDT)
From: John Sparr <johnrdb@yahoo.com>
Subject: RSVP LSP
To: mpls@UU.NET
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

I have a question about RSVP LSP:

If there is a LSP like below:

    A---LER1---LSR---LER2---B

A and B is none RSVP nodes. If we want to establish a
LSP from A to B. What happened to LER1/2 and LSR?
They setup RSVP LSP tunnel automatically
(LER1--LSR--LER2)? or just forward sessions to B?

Thanks in advance

John

__________________________________________________
Do You Yahoo!?
Kick off your party with Yahoo! Invites.
http://invites.yahoo.com/



From owner-mpls@UU.NET  Tue Aug  1 23:55:32 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26572
	for <mpls-archive@lists.ietf.org>; Tue, 1 Aug 2000 23:55:32 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjalj29020;
	Wed, 2 Aug 2000 03:54:33 GMT
Received: by mail-control.mail.uu.net 
	id QQjalj02338
	for mpls-outgoing; Wed, 2 Aug 2000 03:54:13 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjalj02330
	for <mpls@mail-control.mail.uu.net>; Wed, 2 Aug 2000 03:54:06 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjalj11142
	for <mpls@UU.NET>; Tue, 1 Aug 2000 23:53:53 -0400 (EDT)
Received: from griffin.host4u.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: griffin.host4u.net [209.150.128.163])
	id QQjalj21524
	for <mpls@UU.NET>; Wed, 2 Aug 2000 03:53:23 GMT
Received: from nfloat.labn.net (labn.net [209.204.240.82])
	by griffin.host4u.net (8.8.5/8.8.5) with ESMTP id WAA10311;
	Tue, 1 Aug 2000 22:53:04 -0500
Message-Id: <4.3.2.7.2.20000801225758.00def3d0@mail.labn.net>
X-Sender: lberger@mail.labn.net
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 01 Aug 2000 23:53:23 -0400
To: Francois Le Faucheur <flefauch@cisco.com>
From: Lou Berger <lberger@labn.net>
Subject: RE: Two last calls (draft-ietf-mpls-diff-ext-06.txt)
Cc: Lou Berger <lberger@labn.net>, Francois Le Faucheur <flefauch@cisco.com>,
        Shahram Davari <Shahram_Davari@pmc-sierra.com>, mpls@UU.NET
In-Reply-To: <4.0.2.20000801113940.02298700@europe.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

Francois,

At 11:51 AM 8/1/00 +0200, Francois Le Faucheur wrote:
>Lou,
>
> >>We have agreed on an "escape code" above (the first "SHOULD") which allows
> >>one to maintain whatever flavor of "standard, non-DS, LSP" he/she liked. I
> >>think this is all the Diff-Serv spec probably needs to say and would
> >>prefer to avoid having to mention in any way QoS support which were
> >>pre-Diff-Ext. So I'd like to leave out the new recommendation.
> >>
> >>In any case, if a statement about Override option was to be included, I
> >>would argue that it should be a MAY and not a MUST.
> >
> >I believe I said "SHOULD" not MUST.
>
>You did say SHOULD, and I did mean that "it should be a MAY and not a SHOULD".
>
> > I'd be fine with a MAY.
>
>Then, can we agree on the principles of this "compromise" position?  i.e.:
>         - The text would say that when there is RSVP signaling without 
> the Diff-Serv object, the LSR SHOULD (instead of MUST) interpret this as 
> a request for an "E-LSP using Preconfigured EXP<-->PHB Mapping".
>         - the text would say that an implementation MAY include an option 
> that overrides this.  When this "override option" is set, the LSR then 
> treats LSPs signaled without the DiffServ object as standard, non-DS, LSPs.
>
>If yes, I'll propose exact wording to reflect this.

Agreed.  Thank you.

I must also apologize.  In all the discussion I dropped one minor, 
hopefully non-contentious point.  When the above option is set, it is still 
desirable to allow the setup of E-LSPs that use default mapping.

To signal this, I suggest using a DiffServ Object with the MAPnb set to 0.

Is this too agreeable?

Thanks,
Lou

>Thanks
>
>FRancois
>
>_________________________________________________________________
>Francois Le Faucheur
>Development Engineer, IOS Layer 3 Services
>Cisco Systems
>Office Phone:           +33 4 92 96 75 64
>Home Office Phone:     +33 4 92 94 00 78
>Mobile :               +33 6 89 108 159
>Vmail:                 +33 1 58 04 62 66
>Fax:                   +33 4 92 96 79 08
>Email:                  flefauch@cisco.com
>_________________________________________________________________
>Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - France
>_________________________________________________________________



From owner-mpls@UU.NET  Wed Aug  2 02:53:10 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17805
	for <mpls-archive@lists.ietf.org>; Wed, 2 Aug 2000 02:53:09 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjalv11619;
	Wed, 2 Aug 2000 06:52:32 GMT
Received: by mail-control.mail.uu.net 
	id QQjalv17334
	for mpls-outgoing; Wed, 2 Aug 2000 06:52:13 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjalv17329
	for <mpls@mail-control.mail.uu.net>; Wed, 2 Aug 2000 06:52:04 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjalv14021
	for <mpls@uu.net>; Wed, 2 Aug 2000 02:51:53 -0400 (EDT)
From: seenu@samsung.co.kr
Received: from omail01.samsung.co.kr by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: omail01.samsung.co.kr [203.254.197.73])
	id QQjalv11205
	for <mpls@uu.net>; Wed, 2 Aug 2000 06:51:37 GMT
Received: from localhost (root@localhost)
	by gp_xman. (8.8.8H1/8.8.8) with ESMTP id PAA01095
	for <mpls@uu.net>; Wed, 2 Aug 2000 15:52:22 +0900 (KST)
X-OpenMail-Hops: 3
Date: Wed, 2 Aug 2000 15:53:33 +0900
Message-Id: <H0000e6501976d71.0965198572.secsw0@MHS>
Subject: LDP TEST CASES ON THE NET
MIME-Version: 1.0
TO: mpls@UU.NET
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline; filename="mail.txt"
	;Creation-Date="Wed, 2 Aug 2000 15:42:57 +0900"
	;Modification-Date="Wed, 2 Aug 2000 15:53:21 +0900"
Content-Transfer-Encoding: 8bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit

Hi,

MPLS-LDP Test cases are available on the net.
Whoever wants, can access it at :

MS word doc :     www.geocities.com/smilybits/mpls-ldp-test-cases.doc

PDF format    :   www.geocities.com/smilybits/mpls-ldp-test-cases.pdf


DISCLAIMER
---------------------

Use information present in this document at your own risk.

SAMSUNG INDIA SOFTWARE OPERATIONS, is not responsible for any misinterpretation of drafts or any such matter.
 We do not claim that this document is complete and exhaustive. This is just an attempt to help someone who wants to
 start defining LDP test cases. 

Information in this document is based on draft-ietf-mpls-ldp-06.txt. While we have tried to keep this document accurate
and up-to-date, we cannot guarantee that it is. If you see something in this document that should be corrected or updated,
send mail to this address seenu@samsung.co.kr. We'll see if the information can be corrected.

Unless otherwise noted, the web information does not represent official statements or views of Samsung Electronics India Software Operations.



Author's Address

MPLS Team
Samsung Electronics Co. Ltd.
India Software Operations (SISO)
Level - 6 & 7 , Prestige Meridian - II
No. 30, M.G. Road, Bangalore -560 001

Tel 	: 91-80-5550555
Fax 	: 91-80-5581301
 



From owner-mpls@UU.NET  Wed Aug  2 06:59:30 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21027
	for <mpls-archive@lists.ietf.org>; Wed, 2 Aug 2000 06:59:30 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjaml29214;
	Wed, 2 Aug 2000 10:59:03 GMT
Received: by mail-control.mail.uu.net 
	id QQjaml16777
	for mpls-outgoing; Wed, 2 Aug 2000 10:58:34 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjaml16760
	for <mpls@mail-control.mail.uu.net>; Wed, 2 Aug 2000 10:58:32 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjaml07951
	for <mpls@uu.net>; Wed, 2 Aug 2000 06:58:22 -0400 (EDT)
Received: from mailhost.iitb.ac.in by wodc7mr1.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: mailhost.iitb.ac.in [203.197.74.142])
	id QQjaml28350
	for <mpls@uu.net>; Wed, 2 Aug 2000 10:58:06 GMT
Received: (qmail 7047 invoked from network); 2 Aug 2000 11:05:02 -0000
Received: from bhairav.ee.iitb.ernet.in (144.16.100.100)
  by mailhost.iitb.ac.in with SMTP; 2 Aug 2000 11:05:02 -0000
Received: from localhost (gabhijit@localhost)
	by bhairav.ee.iitb.ernet.in (8.8.8/8.8.8) with SMTP id QAA20781
	for <mpls@uu.net>; Wed, 2 Aug 2000 16:25:15 +0530 (IST)
Date: Wed, 2 Aug 2000 16:25:15 +0530 (IST)
From: Abhijit <gabhijit@ee.iitb.ernet.in>
To: mpls@UU.NET
Subject: doubt in LDP Label Mapping procedure.
Message-ID: <Pine.GSO.3.96.1000802161439.19966A-100000@bhairav.ee.iitb.ernet.in>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk



Hi all,

In the ldp-06 draft in Appendix A, in procedure of label mapping message,

LMp. 14 says is the LSR ingress for FEC?

How an LSR can know beforehand that it is ingress for a particular FEC? A
particular LSR can be egress for a particular FEC, but whether it is
ingress or not is dependent upon the source from where packet is entering
MPLS domain. 

Consider

         A-----------B-------------D
                     |
         C___________|


Here let a set of 4 routers A, B, C, D be the MPLS domain. When packet
enters this domain through A , A is the ingress and when it enters through
C, C is the ingress, If there is also a link between A & C and
shprtest path to B from A is via C, C will be ingress for a set of packets
but it won't be ingress for other set of packets, So how can you decide 
beforehand that C is ingress or not?

-abhijit




From owner-mpls@UU.NET  Wed Aug  2 07:42:56 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05608
	for <mpls-archive@lists.ietf.org>; Wed, 2 Aug 2000 07:42:56 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjamo06562;
	Wed, 2 Aug 2000 11:42:28 GMT
Received: by mail-control.mail.uu.net 
	id QQjamo00642
	for mpls-outgoing; Wed, 2 Aug 2000 11:42:06 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjamo00637
	for <mpls@mail-control.mail.uu.net>; Wed, 2 Aug 2000 11:42:00 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjamo25758
	for <mpls@uu.net>; Wed, 2 Aug 2000 07:41:41 -0400 (EDT)
Received: from zrtps06s.us.nortel.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [47.140.48.50])
	id QQjamo28721
	for <mpls@uu.net>; Wed, 2 Aug 2000 11:41:11 GMT
Received: from zmers013 (actually zmers013.ca.nortel.com) 
          by zrtps06s.us.nortel.com; Wed, 2 Aug 2000 07:39:37 -0400
Received: from zcard00p.ca.nortel.com by zmers013;
          Wed, 2 Aug 2000 07:39:24 -0400
Received: from americasm01.nt.com (PHILIPMA-1 [47.72.241.92]) 
          by zcard00p.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) 
          id QCDZ0GHK; Wed, 2 Aug 2000 07:39:20 -0400
Message-ID: <39880865.FD5BB43D@americasm01.nt.com>
Date: Wed, 02 Aug 2000 07:39:17 -0400
X-Sybari-Space: 00000000 00000000 00000000
From: "Philip Matthews" <philipma@nortelnetworks.com>
Organization: Nortel Networks
X-Mailer: Mozilla 4.72 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Comments on draft-mpls-rsvp-lsp-tunnel-06.txt
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Orig: <philipma@americasm01.nt.com>
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

I know that I have missed the last call deadline for comments on this draft,
but I hope the authors will consider the following comments.
Even if it is too late for them to be considered for the draft,
I would still very much appreciate answers to the various questions 
that are interspersed with the comments.

- Philip


2.6. Path MTU
  The text says "The following algorithm applies to all unlabeled IP datagrams
  and to any labeled packets which the node knows to be IP datagrams ...".
  Could the draft be a bit more specific about the rules for determining
  when a labeled packet is an IP datagram? Specifically, could the draft
  explicitly include the case where the labeled packet was received on an
  LSP whose L3PID value is IPv4?
  Also, does this procedure apply to IPv6 datagrams?
  

4.1. Label Object
  The packet format says "(top label)". This seems to be a carry-over
  from when multiple labels could be carried. Suggest replacing this
  by just "Label".


4.1.1.1. Downstream
  The text says "A node is expected to send a Resv message before its
  refresh timers expire if the contents of the LABEL object change."
  When could this happen? Once an LSP is set up, is the downstream node
  allowed to change the LABEL object in a Resv refresh?

  Also, there is a typo: "cooresponding" instead of "corresponding"
  (ditto in section 4.1.1.2)


4.1.1.2. Upstream
  This section says that one way a received LABEL object can be
  unacceptable is if "the implicit null label was assigned, 
  but the node is not capable of doing a penultimate pop for the
  associated L3PID".
  How does the downstream node know if the upstream node is capable
  of doing PHP?
 

4.3.4.1. Selection of the Next Hop
  Three items here:
  1) When selecting the next hop when the next subobject is a loose subobject,
     must the next hop be on the _SHORTEST_ path to the next abstract node,
     as specified by the routing table?
     In particular, in the following example, must C be selected as the next hop,
     even though the path will fail, while the path through B would work?
                                B
                              /   \
                        X -- A      D -- Y
                              \   /
                                C
     [Here X has specified a loose route to Y. Link A -- C is on the shortest path,
      but has insufficient bandwidth. Link A -- B and B -- D have sufficient bandwidth,
      but IGP metrics may this path more expensive]

  2) When selecting the next hop when the next subobject is a strict subobject,
     are there any rules about which links must be selected?
     In particular, some vendors today require that a strict hop to an interface address
     arrive on that interface, while a strict hop to a loopback address can arrive
     on any interface.

  3) Could this section describe what happens to a loosely routed LSP
     when the routing table changes? In particular, does a node just stop
     sending Path messages to the old NHOP and start sending them to the
     new NHOP?


4.4.1.3. Subobject 0x03, Label
  Here the text uses the term "global label" where the architecture draft used the term
  "platform-wide label". 

  Also, there seems to be a conflict here with the sentence in section 4.1.1 which states
  "Labels received in Resv messages on different interfaces are always
   considered to be different even if the label value is the same."
  Could the draft be more precise as to when a label is interface-specific and when
  it is platform-wide?


4.4.3. Handling RRO
  The text states "The initial RRO contains only one subobject - the
  sender's IP addresses." 
  I believe that the text meant to say just "address" (not "addresses"),
  and that the description below about how to select the address in the
  transit case also applies here. Could this be made clear?

  Also, could the draft be explicit on what address to use in this subobject
  in the case where the outgoing link is unnumbered?


4.5. Processing RRO
  The text says "The Label Record subobject is pushed onto the RECORD_ROUTE object
  prior to pushing on the node's IP address."
  Which label is pushed: the label for the upstream link or the label for the
  downstream link?


4.7.4. Reroute and Bandwidth Increase Procedure
  Could this section mention the "Ingress node may reroute" flag in the
  SESSION_ATTRIBUTE object?


4.8.1. Format without Resource Affinities (for SESSION_ATTRIBUTE object)
  Under the "Ingress node may reroute" flag, the text says "A tunnel egress node
  SHOULD use the SE Style when responding with a Resv message."
  Doesn't this "SHOULD" have to be a "MUST" in order
  a) for the reroute and bandwidth increase procedure to work, AND
  b) to correctly verify that bandwidth exists along the path when 
     processing the Path message as described in section 2.2?

  Also, when this flag is not set, doesn't the text need to specify whether
  the egress node should use FF or SE style for reason (b)?


4.8.3. Procedures applying to both C-Types
  There are some missing words in the sentence "Since the Label subobject is not needed
  for all applications of the it is ...".


4.8.4. Resource Affinity Procedures
  There is a incomplete sentence: "If the test fails a error message".


General
  Could the draft specify what is allowed to change in a Path or Resv refresh?
  In particular, are the following objects allowed to change:
    - LABEL
    - LABEL_REQUEST
    - EXPLICIT_ROUTE
    - SESSION_ATTRIBUTE
    - SENDER_TSPEC
  What should the receiving node do if one or more of these objects change?


From owner-mpls@UU.NET  Wed Aug  2 10:00:11 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21471
	for <mpls-archive@lists.ietf.org>; Wed, 2 Aug 2000 10:00:10 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjamx23248;
	Wed, 2 Aug 2000 13:59:03 GMT
Received: by mail-control.mail.uu.net 
	id QQjamx04758
	for mpls-outgoing; Wed, 2 Aug 2000 13:58:36 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjamx04748
	for <mpls@mail-control.mail.uu.net>; Wed, 2 Aug 2000 13:58:27 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjamx15306
	for <mpls@uu.net>; Wed, 2 Aug 2000 09:58:04 -0400 (EDT)
From: Ted44tedT@netscape.net
Received: from imo-d05.mx.aol.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imo-d05.mx.aol.com [205.188.157.37])
	id QQjamx22229
	for <mpls@uu.net>; Wed, 2 Aug 2000 13:57:49 GMT
Received: from Ted44tedT@netscape.net
	by imo-d05.mx.aol.com (mail_out_v27.12.) id p.f0.94db7 (16215);
	Wed, 2 Aug 2000 09:57:03 -0400 (EDT)
Received: from  netscape.com (aimmail01.aim.aol.com [205.188.144.193]) by air-in01.mx.aol.com (v75_b3.11) with ESMTP; Wed, 02 Aug 2000 09:57:03 -0400
Message-ID: <5CD08371.72D2E707.02882A9A@netscape.net>
Date: Wed, 02 Aug 2000 09:55:42 -0400
To: Guy.Davies@telindusk.net
Cc: ebroo@setuidzero.org, mpls@UU.NET
Subject: RSVP LSP
References: <356D1F13C9C9D311A16800508B715DBD3786AF@CAIN>
X-Mailer: Franklin Webmailer 1.0
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


Hi,

Thanks for your answer.

In (1) case, you mean two diffrent LSPs. I understand one is of LDP signaling, the second is of RSVP signaling. Is that right? 

If the LSP from A to B is LDP signalled, then it should use label stack at case (2), is that right?

In case (2), is LER1(LIR, Edward says) configured not use RSVP signaling?  

Is that possible that a whole LSP is composed with two parts, one is LDP signalled, and one is RSVP signalled?


Thanks in advance
Ted
Guy Davies <Guy.Davies@telindusk.net> wrote:
>
> Hi,
> 
> Let's assume that there is already an RSVP signalled LSP from LER1 to LER2
> and, as you've stated, A and B don't speak RSVP (at least on the interfaces
> to LER1 and LER2 respectively).  There are two possibilities.
> 
> 1: You statically configure/LDP signal an LSP right from A to B.  This is
> totally independent of the existing, RSVP signalled LSP from LER1 to LER2
> and (if you use LDP to signal the path) requires LER1, LSR and LER2 to
> understand LDP in addition to RSVP.  In this case, you have two LSPs between
> LER1 and LER2, one of which extends right out to A and B.
> 
> 2: You configure an LSP from A to B using the LSP from LER1 to LER2 to make
> that "hop".  In that case, you require label stacking.  i.e. you push a
> label at A and transmit to LER1, you push a second label at LER1 and
> transmit to LSR, you swap/pop the top label at LSR and transmit to LER2, you
> pop the top label (if it's still there) and swap/pop the bottom label at
> LER2 then transmit to B.  At B, you pop the bottom label (if it's still
> there) and forward the packet using IP.  In this case, you have a single LSP
> from LER1 to LER2.  It just happens to be "carrying" another LSP.  This is
> analogous to an ATM VP.
> 
> In 2, the swap/pop decision is based on whether penultimate hop popping is
> configured.
> 
> Finally, remember that you'll have to configure a reverse path LSP to carry
> the return traffic (B to A) since LSPs are unidirectional.
> 
> Regards,
> 
> Guy
> ---
> Guy Davies              Telindus K-NET Ltd
> IP Architect            Hatchwood Place, Farnham Road, 
> e: guy.davies@telindusk.net Odiham, Hants, RG29 1AB
> t: +44 (0)1256 709285  f: +44 (0)1256 709210  m: +44 (0)7879 434214
> 
> 
> > -----Original Message-----
> > From: Edward Brookhouse [mailto:ebroo@setuidzero.org]
> > Sent: Tuesday, August 01, 2000 9:38 PM
> > To: Ted44tedT@netscape.net; mpls@UU.NET
> > Subject: Re: 
> > 
> > 
> > Just making sure I understand the scenario, do you mean that you are
> > stitching the two LSP's together across and LSR?
> > 
> > If not, would this be more like...
> > 
> > A - LIR-TLSR-LER-B
> > 
> >     LIR= Label Ingress Router
> >    TLSR=Transit Label Switch Router
> >     LER=Label Egress Router
> > 
> > Just making sure I caught what you were asking.
> > 
> > Edward Brookhouse
> > Greenwich Technology Partners
> > ebrookhouse@greenwichtech.com
> > 
> > 
> > ----- Original Message -----
> > From: <Ted44tedT@netscape.net>
> > To: <mpls@UU.NET>
> > Sent: Tuesday, August 01, 2000 2:07 PM
> > 
> > 
> > > Hi,
> > >
> > > I have a question about RSVP LSP:
> > >
> > > if we have a LSP like below:
> > >
> > > A--LER1--LSR--LER2--B
> > >
> > > A,B are none rsvp nodes. LER1, LSR and LER2 are RSVP nodes.
> > > if LSP is setup from A to B, what happened to LER1, LSR and LER2?
> > >
> > > Is there a RSVP LSP established from LER1 to LER2? or they 
> > just forward
> > sessions without another RSVP LSP setup?
> > >
> > >
> > > Thanks in advance
> > > John
> > >
> > > ----------
> > > Get your own FREE, personal Netscape Webmail account today at
> > http://home.netscape.com/webmail/
> > >
> > 
> This e-mail and any attachments may contain privileged, confidential and/or
> copyright information and is for the sole use of the intended addressee. If
> you are not the named recipient, please notify the sender immediately and do
> not disclose the contents to another person, use it for any purpose, or
> store or copy the information in any medium.This message is subject to and
> does not create or vary any contractual relationship between Telindus K-NET
> Ltd and you.
> 

----------
Get your own FREE, personal Netscape Webmail account today at http://webmail.netscape.com/


From owner-mpls@UU.NET  Wed Aug  2 10:13:01 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25699
	for <mpls-archive@lists.ietf.org>; Wed, 2 Aug 2000 10:13:01 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjamy03549;
	Wed, 2 Aug 2000 14:12:29 GMT
Received: by mail-control.mail.uu.net 
	id QQjamy17045
	for mpls-outgoing; Wed, 2 Aug 2000 14:11:55 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjamy17033
	for <mpls@mail-control.mail.uu.net>; Wed, 2 Aug 2000 14:11:52 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjamy17827
	for <mpls@UU.NET>; Wed, 2 Aug 2000 10:11:34 -0400 (EDT)
Received: from csa.iisc.ernet.in by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: csa.iisc.ernet.in [144.16.67.8])
	id QQjamy02190
	for <mpls@UU.NET>; Wed, 2 Aug 2000 14:10:46 GMT
Received: from helios.csa.iisc.ernet.in (IDENT:prasanna@helios.csa.iisc.ernet.in [144.16.67.46])
	by csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id TAA06684;
	Wed, 2 Aug 2000 19:20:16 +0530
Received: from localhost (prasanna@localhost)
	by helios.csa.iisc.ernet.in (8.9.3/8.9.3) with SMTP id TAA18984;
	Wed, 2 Aug 2000 19:19:58 +0530
X-Authentication-Warning: helios.csa.iisc.ernet.in: prasanna owned process doing -bs
Date: Wed, 2 Aug 2000 19:19:57 +0530 (IST)
From: Gaitonde Anandprasanna <prasanna@csa.iisc.ernet.in>
To: Ted44tedT@netscape.net
cc: mpls@UU.NET
Subject: Re: your mail
In-Reply-To: <743C92B3.3DD92558.02882A9A@netscape.net>
Message-ID: <Pine.LNX.3.96.1000802191439.14667A-100000@helios.csa.iisc.ernet.in>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk



Well i think even if there are applications running on hosts A and B ,
though the RSVP deamon is not running on theses machines. these
applications can signal their requirement for setting up a RSVP LSP to the
RSVP process running on the LER and thus can use that LSP.
  But in case the applications are unable to do the above then the data
flow from tha application will be considered as any other data which has
not requested for the RSVP LSP. and will recieve normal service.




                 
                     _____________________________                  
                   _ |ANANDPRASANNA GAITONDE     | _ 
                  / )|COMP. SCIENCE & AUTOMATION |( \
                 / / |D-7,IISc HOSTEL            | \ \
                / /  |INDIAN INSTITUTE OF SCIENCE|  \ \
              _( (_  |BANGALORE-560012.          |  _) )_
              (((\ \>|_/->___________________<-\_|</ /)))
              (\\\\ \_/ /LAB Ph.(080)3092906  \ \_/ ////)
               \       /HOSTEL Ph.-            \       /  
                \    _/     (080)3092452        \_    /     
                /   /-----------------------------\   \                  
               /  Email Id-                            \ 
              /      prasanna@csa.iisc.ernet.in         \
	     ---------------------------------------------
            -----------------------------------------------

--------------------------------------------------------------------------------
		
*************************************************************************  
| | | | __ ___   _____     __ _    _ __ (_) ___ ___     __| | __ _ _   _
| |_| |/ _` \ \ / / _ \   / _` |  | '_ \| |/ __/ _ \   / _` |/ _` | | | |
|  _  | (_| |\ V /  __/  | (_| |  | | | | | (_|  __/  | (_| | (_| | |_| |
|_| |_|\__,_| \_/ \___|   \__,_|  |_| |_|_|\___\___|   \__,_|\__,_|\__, |
*************************************************************************



On Tue, 1 Aug 2000 Ted44tedT@netscape.net wrote:

> Hi, 
> 
> I have a question about RSVP LSP:
> 
> if we have a LSP like below:
> 
> A--LER1--LSR--LER2--B
> 
> A,B are none rsvp nodes. LER1, LSR and LER2 are RSVP nodes. 
> if LSP is setup from A to B, what happened to LER1, LSR and LER2?
> 
> Is there a RSVP LSP established from LER1 to LER2? or they just forward sessions without another RSVP LSP setup?
> 
> 
> Thanks in advance
> John
> 
> ----------
> Get your own FREE, personal Netscape Webmail account today at http://home.netscape.com/webmail/
> 



From owner-mpls@UU.NET  Wed Aug  2 10:32:45 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02256
	for <mpls-archive@lists.ietf.org>; Wed, 2 Aug 2000 10:32:45 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjana17840;
	Wed, 2 Aug 2000 14:32:07 GMT
Received: by mail-control.mail.uu.net 
	id QQjana18870
	for mpls-outgoing; Wed, 2 Aug 2000 14:31:18 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjana18857
	for <mpls@mail-control.mail.uu.net>; Wed, 2 Aug 2000 14:31:13 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjana07701
	for <mpls@UU.NET>; Wed, 2 Aug 2000 10:30:50 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQjana25584
	for <mpls@UU.NET>; Wed, 2 Aug 2000 14:30:35 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA26635
	for <mpls@UU.NET>; Wed, 2 Aug 2000 10:30:32 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA10987
	for <mpls@UU.NET>; Wed, 2 Aug 2000 10:30:33 -0400 (EDT)
Message-ID: <398830B0.89BC1D9E@marconi.com>
Date: Wed, 02 Aug 2000 10:31:12 -0400
From: David Charlap <david.charlap@marconi.com>
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: Comments on draft-mpls-rsvp-lsp-tunnel-06.txt
References: <39880865.FD5BB43D@americasm01.nt.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

I think I can answer one of these....

Philip Matthews wrote:
> 
> 4.1.1.1. Downstream
>   The text says "A node is expected to send a Resv message before its
>   refresh timers expire if the contents of the LABEL object change."
>   When could this happen? Once an LSP is set up, is the downstream
>   node allowed to change the LABEL object in a Resv refresh?

Normally, a downstream node will not change the LABEL object.  But there
are scenarios where it could happen.  For example.  Imagine this
topology:

	A---B---C---D

A Path and Resv go through and an LSP is established from A to D.

Now, the inbound interface on D goes down, but the outbound interface on
C remains up.  (Perhaps it was administratively disabled - obviously,
this wouldn't happen if the fiber was disconnected.)

C thinks the link is still up and continues sending Path refreshes.  D
thinks the link is down and tears its state.

Now, before C misses enough Resv refreshes to presume link failure and
generate a PathErr, the inbound interface on D comes up again.

D receives a Path from C (one of the usual refreshes), but it sees it as
a new Path (since it no longer has the old state in memory).  So it
allocates a new LABEL (which will almost certainly be different from the
one it had before) and sends this to C in its Resv messages.

Admittedly, this is a rare (and a bit contrived) sitation, but it can
happen.

> General
>   Could the draft specify what is allowed to change in a Path or Resv
>   refresh?

In general, in keeping with the soft-state nature of RSVP (see RFC2205),
any parameter can change, unless explicitly stated otherwise.  In actual
practice (especially when used as a part of MPLS), most are unlikely to
actually change.

>   In particular, are the following objects allowed to change:
>     - LABEL
>     - LABEL_REQUEST

These shouldn't, under normal circumstances.  But, in the case where
only one side of a link goes down and later comes back up, a switch can
receive a "refresh" where these objects have changed.

>     - EXPLICIT_ROUTE

In theory.  It is, however, preferred that the ingress node use the
"make before break" procedure to effect a reroute.  While changing the
ERO would, in theory, work, it can create some race conditions - where
the new Path is established, and then another switch (which used to be
on the path) times out and sends out tear messages.

>     - SESSION_ATTRIBUTE

Again, I think it will be unlikely for this to change, but it is
possible.

>     - SENDER_TSPEC

This has always been possible (see RFC 2205).  George Swallow has
stated, however, that it is preferable to do a make-before-break reroute
in the situation where the bandwidth for an LSP must be changed.

-- David


From owner-mpls@UU.NET  Wed Aug  2 11:17:23 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18297
	for <mpls-archive@lists.ietf.org>; Wed, 2 Aug 2000 11:17:23 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjand04780;
	Wed, 2 Aug 2000 15:16:29 GMT
Received: by mail-control.mail.uu.net 
	id QQjand03559
	for mpls-outgoing; Wed, 2 Aug 2000 15:15:46 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjand03554
	for <mpls@mail-control.mail.uu.net>; Wed, 2 Aug 2000 15:15:41 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjand29134
	for <mpls@uu.net>; Wed, 2 Aug 2000 11:15:25 -0400 (EDT)
Received: from cain.telindusk.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail.telindus.co.uk [195.172.37.23])
	id QQjand03775
	for <mpls@uu.net>; Wed, 2 Aug 2000 15:15:24 GMT
Received: by CAIN with Internet Mail Service (5.5.2650.21)
	id <PFFVXAD8>; Wed, 2 Aug 2000 16:12:40 +0100
Message-ID: <356D1F13C9C9D311A16800508B715DBD3786BC@CAIN>
From: Guy Davies <Guy.Davies@telindusk.net>
To: "'Ted44tedT@netscape.net'" <Ted44tedT@netscape.net>,
        Guy Davies
	 <Guy.Davies@telindusk.net>
Cc: ebroo@setuidzero.org, mpls@UU.NET
Subject: RE: RSVP LSP
Date: Wed, 2 Aug 2000 16:12:37 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA18297

Hi Ted,

Erm, I'm not really sure because your restatement is a bit confusing.  To
restate what I said...

You can use a statically configured LSP from A to B.  In this case, you
statically configure A, LER1, LSR and LER2 with the details of the LSP.  NO
Signalling is required since all the configuration is static.  This is
entirely separate from the RSVP signalled tunnel from LER1 to LER2.  This is
two totally isolated LSPs.

You can use an LDP signalled LSP from A to B.  This is identical to the one
above except that you use LDP instead of statically configuring all the hops
along the path.

If your LERs support label stacking, you can configure an LSP from A to B
where the RSVP signalled path from LER1 to LER2 is used as a "single hop" so
the path would appear to be A - LER1 - LER2 - B.

Regards,

Guy

> -----Original Message-----
> From: Ted44tedT@netscape.net [mailto:Ted44tedT@netscape.net]
> Sent: Wednesday, August 02, 2000 2:56 PM
> To: Guy.Davies@telindusk.net
> Cc: ebroo@setuidzero.org; mpls@uu.net
> Subject: RSVP LSP
> 
> 
> 
> Hi,
> 
> Thanks for your answer.
> 
> In (1) case, you mean two diffrent LSPs. I understand one is 
> of LDP signaling, the second is of RSVP signaling. Is that right? 
> 
> If the LSP from A to B is LDP signalled, then it should use 
> label stack at case (2), is that right?
> 
> In case (2), is LER1(LIR, Edward says) configured not use 
> RSVP signaling?  
> 
> Is that possible that a whole LSP is composed with two parts, 
> one is LDP signalled, and one is RSVP signalled?
> 
> 
> Thanks in advance
> Ted
> Guy Davies <Guy.Davies@telindusk.net> wrote:
> >
> > Hi,
> > 
> > Let's assume that there is already an RSVP signalled LSP 
> from LER1 to LER2
> > and, as you've stated, A and B don't speak RSVP (at least 
> on the interfaces
> > to LER1 and LER2 respectively).  There are two possibilities.
> > 
> > 1: You statically configure/LDP signal an LSP right from A 
> to B.  This is
> > totally independent of the existing, RSVP signalled LSP 
> from LER1 to LER2
> > and (if you use LDP to signal the path) requires LER1, LSR 
> and LER2 to
> > understand LDP in addition to RSVP.  In this case, you have 
> two LSPs between
> > LER1 and LER2, one of which extends right out to A and B.
> > 
> > 2: You configure an LSP from A to B using the LSP from LER1 
> to LER2 to make
> > that "hop".  In that case, you require label stacking.  
> i.e. you push a
> > label at A and transmit to LER1, you push a second label at LER1 and
> > transmit to LSR, you swap/pop the top label at LSR and 
> transmit to LER2, you
> > pop the top label (if it's still there) and swap/pop the 
> bottom label at
> > LER2 then transmit to B.  At B, you pop the bottom label 
> (if it's still
> > there) and forward the packet using IP.  In this case, you 
> have a single LSP
> > from LER1 to LER2.  It just happens to be "carrying" 
> another LSP.  This is
> > analogous to an ATM VP.
> > 
> > In 2, the swap/pop decision is based on whether penultimate 
> hop popping is
> > configured.
> > 
> > Finally, remember that you'll have to configure a reverse 
> path LSP to carry
> > the return traffic (B to A) since LSPs are unidirectional.
> > 
> > Regards,
> > 
> > Guy
> > ---
> > Guy Davies              Telindus K-NET Ltd
> > IP Architect            Hatchwood Place, Farnham Road, 
> > e: guy.davies@telindusk.net Odiham, Hants, RG29 1AB
> > t: +44 (0)1256 709285  f: +44 (0)1256 709210  m: +44 (0)7879 434214
> > 
> > 
> > > -----Original Message-----
> > > From: Edward Brookhouse [mailto:ebroo@setuidzero.org]
> > > Sent: Tuesday, August 01, 2000 9:38 PM
> > > To: Ted44tedT@netscape.net; mpls@UU.NET
> > > Subject: Re: 
> > > 
> > > 
> > > Just making sure I understand the scenario, do you mean 
> that you are
> > > stitching the two LSP's together across and LSR?
> > > 
> > > If not, would this be more like...
> > > 
> > > A - LIR-TLSR-LER-B
> > > 
> > >     LIR= Label Ingress Router
> > >    TLSR=Transit Label Switch Router
> > >     LER=Label Egress Router
> > > 
> > > Just making sure I caught what you were asking.
> > > 
> > > Edward Brookhouse
> > > Greenwich Technology Partners
> > > ebrookhouse@greenwichtech.com
> > > 
> > > 
> > > ----- Original Message -----
> > > From: <Ted44tedT@netscape.net>
> > > To: <mpls@UU.NET>
> > > Sent: Tuesday, August 01, 2000 2:07 PM
> > > 
> > > 
> > > > Hi,
> > > >
> > > > I have a question about RSVP LSP:
> > > >
> > > > if we have a LSP like below:
> > > >
> > > > A--LER1--LSR--LER2--B
> > > >
> > > > A,B are none rsvp nodes. LER1, LSR and LER2 are RSVP nodes.
> > > > if LSP is setup from A to B, what happened to LER1, LSR 
> and LER2?
> > > >
> > > > Is there a RSVP LSP established from LER1 to LER2? or they 
> > > just forward
> > > sessions without another RSVP LSP setup?
> > > >
> > > >
> > > > Thanks in advance
> > > > John
> > > >
> > > > ----------
> > > > Get your own FREE, personal Netscape Webmail account today at
> > > http://home.netscape.com/webmail/
> > > >
> > > 
> > This e-mail and any attachments may contain privileged, 
> confidential and/or
> > copyright information and is for the sole use of the 
> intended addressee. If
> > you are not the named recipient, please notify the sender 
> immediately and do
> > not disclose the contents to another person, use it for any 
> purpose, or
> > store or copy the information in any medium.This message is 
> subject to and
> > does not create or vary any contractual relationship 
> between Telindus K-NET
> > Ltd and you.
> > 
> 
> ----------
> Get your own FREE, personal Netscape Webmail account today at 
http://webmail.netscape.com/
This e-mail and any attachments may contain privileged, confidential and/or
copyright information and is for the sole use of the intended addressee. If
you are not the named recipient, please notify the sender immediately and do
not disclose the contents to another person, use it for any purpose, or
store or copy the information in any medium.This message is subject to and
does not create or vary any contractual relationship between Telindus K-NET
Ltd and you.


From owner-mpls@UU.NET  Wed Aug  2 11:19:58 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19365
	for <mpls-archive@lists.ietf.org>; Wed, 2 Aug 2000 11:19:58 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjand22611;
	Wed, 2 Aug 2000 15:19:21 GMT
Received: by mail-control.mail.uu.net 
	id QQjand03882
	for mpls-outgoing; Wed, 2 Aug 2000 15:18:54 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjand03869
	for <mpls@mail-control.mail.uu.net>; Wed, 2 Aug 2000 15:18:46 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjand16178
	for <mpls@uu.net>; Wed, 2 Aug 2000 11:18:23 -0400 (EDT)
From: Ted44tedT@netscape.net
Received: from imo-d09.mx.aol.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imo-d09.mx.aol.com [205.188.157.41])
	id QQjand21796
	for <mpls@uu.net>; Wed, 2 Aug 2000 15:18:22 GMT
Received: from Ted44tedT@netscape.net
	by imo-d09.mx.aol.com (mail_out_v27.12.) id q.ed.947b6 (16228);
	Wed, 2 Aug 2000 11:17:33 -0400 (EDT)
Received: from  netscape.com (aimmail10.aim.aol.com [205.188.144.202]) by air-in02.mx.aol.com (v75_b3.11) with ESMTP; Wed, 02 Aug 2000 11:17:33 -0400
Message-ID: <4DC1371B.46E895A0.02882A9A@netscape.net>
Date: Wed, 02 Aug 2000 11:19:03 -0400
To: prasanna@csa.iisc.ernet.in
Cc: mpls@UU.NET
Subject: Re: your mail
References: <Pine.LNX.3.96.1000802191439.14667A-100000@helios.csa.iisc.ernet.in>
X-Mailer: Franklin Webmailer 1.0
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


Hi, Gaitonde

How does the node can signal their requirement for setting up a RSVP LSP to the LER if it is none-RSVP nodes?


Regards,
Ted 


Gaitonde Anandprasanna <prasanna@csa.iisc.ernet.in> wrote:
>
> 
> 
> Well i think even if there are applications running on hosts A and B ,
> though the RSVP deamon is not running on theses machines. these
> applications can signal their requirement for setting up a RSVP LSP to the
> RSVP process running on the LER and thus can use that LSP.
>   But in case the applications are unable to do the above then the data
> flow from tha application will be considered as any other data which has
> not requested for the RSVP LSP. and will recieve normal service.
> 
> 
> 
> 
>                  
>                      _____________________________                  
>                    _ |ANANDPRASANNA GAITONDE     | _ 
>                   / )|COMP. SCIENCE & AUTOMATION |( \
>                  / / |D-7,IISc HOSTEL            | \ \
>                 / /  |INDIAN INSTITUTE OF SCIENCE|  \ \
>               _( (_  |BANGALORE-560012.          |  _) )_
>               (((\ \>|_/->___________________<-\_|</ /)))
>               (\\\\ \_/ /LAB Ph.(080)3092906  \ \_/ ////)
>                \       /HOSTEL Ph.-            \       /  
>                 \    _/     (080)3092452        \_    /     
>                 /   /-----------------------------\   \                  
>                /  Email Id-                            \ 
>               /      prasanna@csa.iisc.ernet.in         \
>          ---------------------------------------------
>             -----------------------------------------------
> 
> --------------------------------------------------------------------------------
>         
> *************************************************************************  
> | | | | __ ___   _____     __ _    _ __ (_) ___ ___     __| | __ _ _   _
> | |_| |/ _` \ \ / / _ \   / _` |  | '_ \| |/ __/ _ \   / _` |/ _` | | | |
> |  _  | (_| |\ V /  __/  | (_| |  | | | | | (_|  __/  | (_| | (_| | |_| |
> |_| |_|\__,_| \_/ \___|   \__,_|  |_| |_|_|\___\___|   \__,_|\__,_|\__, |
> *************************************************************************
> 
> 
> 
> On Tue, 1 Aug 2000 Ted44tedT@netscape.net wrote:
> 
> > Hi, 
> > 
> > I have a question about RSVP LSP:
> > 
> > if we have a LSP like below:
> > 
> > A--LER1--LSR--LER2--B
> > 
> > A,B are none rsvp nodes. LER1, LSR and LER2 are RSVP nodes. 
> > if LSP is setup from A to B, what happened to LER1, LSR and LER2?
> > 
> > Is there a RSVP LSP established from LER1 to LER2? or they just forward sessions without another RSVP LSP setup?
> > 
> > 
> > Thanks in advance
> > John
> > 
> > ----------
> > Get your own FREE, personal Netscape Webmail account today at http://home.netscape.com/webmail/
> > 
> 
> 

----------
Get your own FREE, personal Netscape Webmail account today at http://home.netscape.com/webmail/


From owner-mpls@UU.NET  Wed Aug  2 11:27:39 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22063
	for <mpls-archive@lists.ietf.org>; Wed, 2 Aug 2000 11:27:38 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjand14602;
	Wed, 2 Aug 2000 15:27:15 GMT
Received: by mail-control.mail.uu.net 
	id QQjand05064
	for mpls-outgoing; Wed, 2 Aug 2000 15:26:54 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjand05037
	for <mpls@mail-control.mail.uu.net>; Wed, 2 Aug 2000 15:26:41 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjand01059
	for <mpls@UU.NET>; Wed, 2 Aug 2000 11:25:22 -0400 (EDT)
Received: from coltrane.datcon.co.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtp.datcon.co.uk [192.91.191.4])
	id QQjand12716
	for <mpls@UU.NET>; Wed, 2 Aug 2000 15:25:06 GMT
Received: by smtp.datcon.co.uk with Internet Mail Service (5.5.2650.21)
	id <PDN0XQXB>; Wed, 2 Aug 2000 16:24:56 +0100
Message-ID: <6DEA508A9A0ED31192E80000F6CC176E2C9D98@monk.datcon.co.uk>
From: Adrian Farrel <AF@datcon.co.uk>
To: David Charlap <david.charlap@marconi.com>, mpls@UU.NET,
        philipma@nortelnetworks.com
Subject: RE: Comments on draft-mpls-rsvp-lsp-tunnel-06.txt
Date: Wed, 2 Aug 2000 16:24:55 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

David, Philip,

We saw exactly the behavior that David describes at the last UNH interop.
Of course in that situation the h/w is often a bit rudimentary.

What happened is that the s/w on the downstream box was recycled w/o any
change to h/w so that the light stayed on on the fiber.  The Path refresh
was caught by the downstream node which responded with a Resv with a
different label.

Correct behavior by the upstream node is, of course, either
- reject the Resv and tear the LSP down
- accept the new label and change the switch programming

Adrian
--
Adrian Farrel  mailto:af@datcon.co.uk
Network Convergence Group
Data Connection Ltd., Chester, UK
http://www.datcon.co.uk/
Tel: +44 (0) 1244 313440  Fax: +44 (0) 1244 312422


>-----Original Message-----
>From: David Charlap [mailto:david.charlap@marconi.com]
>Sent: Wednesday, August 02, 2000 3:31 PM
>To: mpls@UU.NET
>Subject: Re: Comments on draft-mpls-rsvp-lsp-tunnel-06.txt
>
>
>I think I can answer one of these....
>
>Philip Matthews wrote:
>> 
>> 4.1.1.1. Downstream
>>   The text says "A node is expected to send a Resv message before its
>>   refresh timers expire if the contents of the LABEL object change."
>>   When could this happen? Once an LSP is set up, is the downstream
>>   node allowed to change the LABEL object in a Resv refresh?
>
>Normally, a downstream node will not change the LABEL object.  
>But there
>are scenarios where it could happen.  For example.  Imagine this
>topology:
>
>	A---B---C---D
>
>A Path and Resv go through and an LSP is established from A to D.
>
>Now, the inbound interface on D goes down, but the outbound 
>interface on
>C remains up.  (Perhaps it was administratively disabled - obviously,
>this wouldn't happen if the fiber was disconnected.)
>
>C thinks the link is still up and continues sending Path refreshes.  D
>thinks the link is down and tears its state.
>
>Now, before C misses enough Resv refreshes to presume link failure and
>generate a PathErr, the inbound interface on D comes up again.
>
>D receives a Path from C (one of the usual refreshes), but it 
>sees it as
>a new Path (since it no longer has the old state in memory).  So it
>allocates a new LABEL (which will almost certainly be 
>different from the
>one it had before) and sends this to C in its Resv messages.
>
>Admittedly, this is a rare (and a bit contrived) sitation, but it can
>happen.


From owner-mpls@UU.NET  Wed Aug  2 11:37:35 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26422
	for <mpls-archive@lists.ietf.org>; Wed, 2 Aug 2000 11:37:34 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjane06022;
	Wed, 2 Aug 2000 15:36:38 GMT
Received: by mail-control.mail.uu.net 
	id QQjane06070
	for mpls-outgoing; Wed, 2 Aug 2000 15:36:07 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjane06050
	for <mpls@mail-control.mail.uu.net>; Wed, 2 Aug 2000 15:36:03 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjane19450
	for <mpls@UU.NET>; Wed, 2 Aug 2000 11:35:52 -0400 (EDT)
Received: from cain.telindusk.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail.telindus.co.uk [195.172.37.23])
	id QQjane21869
	for <mpls@UU.NET>; Wed, 2 Aug 2000 15:35:21 GMT
Received: by CAIN with Internet Mail Service (5.5.2650.21)
	id <PFFVXAHC>; Wed, 2 Aug 2000 16:32:41 +0100
Message-ID: <356D1F13C9C9D311A16800508B715DBD3786C0@CAIN>
From: Guy Davies <Guy.Davies@telindusk.net>
To: "'Ted44tedT@netscape.net'" <Ted44tedT@netscape.net>,
        prasanna@csa.iisc.ernet.in
Cc: mpls@UU.NET
Subject: RE: your mail
Date: Wed, 2 Aug 2000 16:32:33 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA26422

Also, how does A signal to LER1 if LER1 isn't listening to RSVP on it's
non-MPLS interfaces?

Regards,

Guy

> -----Original Message-----
> From: Ted44tedT@netscape.net [mailto:Ted44tedT@netscape.net]
> Sent: Wednesday, August 02, 2000 4:19 PM
> To: prasanna@csa.iisc.ernet.in
> Cc: mpls@UU.NET
> Subject: Re: your mail
> 
> 
> 
> Hi, Gaitonde
> 
> How does the node can signal their requirement for setting up 
> a RSVP LSP to the LER if it is none-RSVP nodes?
> 
> 
> Regards,
> Ted 
> 
> 
> Gaitonde Anandprasanna <prasanna@csa.iisc.ernet.in> wrote:
> >
> > 
> > 
> > Well i think even if there are applications running on 
> hosts A and B ,
> > though the RSVP deamon is not running on theses machines. these
> > applications can signal their requirement for setting up a 
> RSVP LSP to the
> > RSVP process running on the LER and thus can use that LSP.
> >   But in case the applications are unable to do the above 
> then the data
> > flow from tha application will be considered as any other 
> data which has
> > not requested for the RSVP LSP. and will recieve normal service.
> > 
> > 
> > 
> > 
> >                  
> >                      _____________________________                  
> >                    _ |ANANDPRASANNA GAITONDE     | _ 
> >                   / )|COMP. SCIENCE & AUTOMATION |( \
> >                  / / |D-7,IISc HOSTEL            | \ \
> >                 / /  |INDIAN INSTITUTE OF SCIENCE|  \ \
> >               _( (_  |BANGALORE-560012.          |  _) )_
> >               (((\ \>|_/->___________________<-\_|</ /)))
> >               (\\\\ \_/ /LAB Ph.(080)3092906  \ \_/ ////)
> >                \       /HOSTEL Ph.-            \       /  
> >                 \    _/     (080)3092452        \_    /     
> >                 /   /-----------------------------\   \     
>              
> >                /  Email Id-                            \ 
> >               /      prasanna@csa.iisc.ernet.in         \
> >          ---------------------------------------------
> >             -----------------------------------------------
> > 
> > 
> --------------------------------------------------------------
> ------------------
> >         
> > 
> **************************************************************
> ***********  
> > | | | | __ ___   _____     __ _    _ __ (_) ___ ___     __| 
> | __ _ _   _
> > | |_| |/ _` \ \ / / _ \   / _` |  | '_ \| |/ __/ _ \   / _` 
> |/ _` | | | |
> > |  _  | (_| |\ V /  __/  | (_| |  | | | | | (_|  __/  | (_| 
> | (_| | |_| |
> > |_| |_|\__,_| \_/ \___|   \__,_|  |_| |_|_|\___\___|   
> \__,_|\__,_|\__, |
> > 
> **************************************************************
> ***********
> > 
> > 
> > 
> > On Tue, 1 Aug 2000 Ted44tedT@netscape.net wrote:
> > 
> > > Hi, 
> > > 
> > > I have a question about RSVP LSP:
> > > 
> > > if we have a LSP like below:
> > > 
> > > A--LER1--LSR--LER2--B
> > > 
> > > A,B are none rsvp nodes. LER1, LSR and LER2 are RSVP nodes. 
> > > if LSP is setup from A to B, what happened to LER1, LSR and LER2?
> > > 
> > > Is there a RSVP LSP established from LER1 to LER2? or 
> they just forward sessions without another RSVP LSP setup?
> > > 
> > > 
> > > Thanks in advance
> > > John
> > > 
> > > ----------
> > > Get your own FREE, personal Netscape Webmail account 
> today at http://home.netscape.com/webmail/
> > > 
> > 
> > 
> 
> ----------
> Get your own FREE, personal Netscape Webmail account today at 
> http://home.netscape.com/webmail/
> 
This e-mail and any attachments may contain privileged, confidential and/or
copyright information and is for the sole use of the intended addressee. If
you are not the named recipient, please notify the sender immediately and do
not disclose the contents to another person, use it for any purpose, or
store or copy the information in any medium.This message is subject to and
does not create or vary any contractual relationship between Telindus K-NET
Ltd and you.


From owner-mpls@UU.NET  Wed Aug  2 12:26:51 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13633
	for <mpls-archive@lists.ietf.org>; Wed, 2 Aug 2000 12:26:51 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjanh06226;
	Wed, 2 Aug 2000 16:26:12 GMT
Received: by mail-control.mail.uu.net 
	id QQjanh23681
	for mpls-outgoing; Wed, 2 Aug 2000 16:25:26 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjanh23646
	for <mpls@mail-control.mail.uu.net>; Wed, 2 Aug 2000 16:25:11 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjanh28026
	for <mpls@UU.NET>; Wed, 2 Aug 2000 12:25:03 -0400 (EDT)
Received: from hermes.research.kpn.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: hermes.research.kpn.com [139.63.192.8])
	id QQjanh04656
	for <mpls@UU.NET>; Wed, 2 Aug 2000 16:24:32 GMT
Received: from l04.research.kpn.com (l04.research.kpn.com [139.63.192.204])
 by research.kpn.com (PMDF V5.2-31 #42699)
 with ESMTP id <01JSI5TCUR4M0005DW@research.kpn.com> for mpls@UU.NET; Wed,
 2 Aug 2000 18:24:31 +0200
Received: by l04.research.kpn.com with Internet Mail Service (5.5.2650.21)
	id <PQ1D4TGY>; Wed, 02 Aug 2000 18:24:29 +0100
Content-return: allowed
Date: Wed, 02 Aug 2000 18:24:29 +0100
From: "Metz, E.T." <E.T.Metz@kpn.com>
Subject: RE: your mail
To: "'Guy Davies'" <Guy.Davies@telindusk.net>,
        "'Ted44tedT@netscape.net'" <Ted44tedT@netscape.net>,
        prasanna@csa.iisc.ernet.in
Cc: mpls@UU.NET
Message-id: <59063B5B4D98D311BC0D0001FA7E45220316A36F@l04.research.kpn.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain;	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA13633

A LER (label-edge-router) is the point at which your MPLS network
starts/ends. This means there is no MPLS beyond the LER. Therefore, an LSP
between A and B is not a valid option. It is simply not possible (by
definition).

You may be referring to another situation though. For instance the case
where an RSVP session is initiated between A and B? (instead of an LSP). As
far as I know, the host-to-host RSVP session should (must/will) not trigger
an RSVP-signalled LSP between LER1 and LER2. So, the host-to-host session
will be forwarded. (If remember correctly the type of a host-to-host RSVP
session is different from that of an 'MPLS' RSVP session.)

Does this help, or did I make things worse?

cheers,
	Eduard

> -----Original Message-----
> From: Guy Davies [mailto:Guy.Davies@telindusk.net]
> Sent: woensdag 2 augustus 2000 16:33
> To: 'Ted44tedT@netscape.net'; prasanna@csa.iisc.ernet.in
> Cc: mpls@UU.NET
> Subject: RE: your mail
> 
> 
> Also, how does A signal to LER1 if LER1 isn't listening to 
> RSVP on it's
> non-MPLS interfaces?
> 
> Regards,
> 
> Guy
> 
> > -----Original Message-----
> > From: Ted44tedT@netscape.net [mailto:Ted44tedT@netscape.net]
> > Sent: Wednesday, August 02, 2000 4:19 PM
> > To: prasanna@csa.iisc.ernet.in
> > Cc: mpls@UU.NET
> > Subject: Re: your mail
> > 
> > 
> > 
> > Hi, Gaitonde
> > 
> > How does the node can signal their requirement for setting up 
> > a RSVP LSP to the LER if it is none-RSVP nodes?
> > 
> > 
> > Regards,
> > Ted 
> > 
> > 
> > Gaitonde Anandprasanna <prasanna@csa.iisc.ernet.in> wrote:
> > >
> > > 
> > > 
> > > Well i think even if there are applications running on 
> > hosts A and B ,
> > > though the RSVP deamon is not running on theses machines. these
> > > applications can signal their requirement for setting up a 
> > RSVP LSP to the
> > > RSVP process running on the LER and thus can use that LSP.
> > >   But in case the applications are unable to do the above 
> > then the data
> > > flow from tha application will be considered as any other 
> > data which has
> > > not requested for the RSVP LSP. and will recieve normal service.
> > > 
> > > 
> > > 
> > > 
> > >                  
> > >                      _____________________________        
>           
> > >                    _ |ANANDPRASANNA GAITONDE     | _ 
> > >                   / )|COMP. SCIENCE & AUTOMATION |( \
> > >                  / / |D-7,IISc HOSTEL            | \ \
> > >                 / /  |INDIAN INSTITUTE OF SCIENCE|  \ \
> > >               _( (_  |BANGALORE-560012.          |  _) )_
> > >               (((\ \>|_/->___________________<-\_|</ /)))
> > >               (\\\\ \_/ /LAB Ph.(080)3092906  \ \_/ ////)
> > >                \       /HOSTEL Ph.-            \       /  
> > >                 \    _/     (080)3092452        \_    /     
> > >                 /   /-----------------------------\   \     
> >              
> > >                /  Email Id-                            \ 
> > >               /      prasanna@csa.iisc.ernet.in         \
> > >          ---------------------------------------------
> > >             -----------------------------------------------
> > > 
> > > 
> > --------------------------------------------------------------
> > ------------------
> > >         
> > > 
> > **************************************************************
> > ***********  
> > > | | | | __ ___   _____     __ _    _ __ (_) ___ ___     __| 
> > | __ _ _   _
> > > | |_| |/ _` \ \ / / _ \   / _` |  | '_ \| |/ __/ _ \   / _` 
> > |/ _` | | | |
> > > |  _  | (_| |\ V /  __/  | (_| |  | | | | | (_|  __/  | (_| 
> > | (_| | |_| |
> > > |_| |_|\__,_| \_/ \___|   \__,_|  |_| |_|_|\___\___|   
> > \__,_|\__,_|\__, |
> > > 
> > **************************************************************
> > ***********
> > > 
> > > 
> > > 
> > > On Tue, 1 Aug 2000 Ted44tedT@netscape.net wrote:
> > > 
> > > > Hi, 
> > > > 
> > > > I have a question about RSVP LSP:
> > > > 
> > > > if we have a LSP like below:
> > > > 
> > > > A--LER1--LSR--LER2--B
> > > > 
> > > > A,B are none rsvp nodes. LER1, LSR and LER2 are RSVP nodes. 
> > > > if LSP is setup from A to B, what happened to LER1, LSR 
> and LER2?
> > > > 
> > > > Is there a RSVP LSP established from LER1 to LER2? or 
> > they just forward sessions without another RSVP LSP setup?
> > > > 
> > > > 
> > > > Thanks in advance
> > > > John
> > > > 
> > > > ----------
> > > > Get your own FREE, personal Netscape Webmail account 
> > today at http://home.netscape.com/webmail/
> > > > 
> > > 
> > > 
> > 
> > ----------
> > Get your own FREE, personal Netscape Webmail account today at 
> > http://home.netscape.com/webmail/
> > 
> This e-mail and any attachments may contain privileged, 
> confidential and/or
> copyright information and is for the sole use of the intended 
> addressee. If
> you are not the named recipient, please notify the sender 
> immediately and do
> not disclose the contents to another person, use it for any 
> purpose, or
> store or copy the information in any medium.This message is 
> subject to and
> does not create or vary any contractual relationship between 
> Telindus K-NET
> Ltd and you.
> 


From owner-mpls@UU.NET  Wed Aug  2 14:05:49 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16334
	for <mpls-archive@lists.ietf.org>; Wed, 2 Aug 2000 14:05:49 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjano01942;
	Wed, 2 Aug 2000 18:04:58 GMT
Received: by mail-control.mail.uu.net 
	id QQjano22872
	for mpls-outgoing; Wed, 2 Aug 2000 18:04:20 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjano22859
	for <mpls@mail-control.mail.uu.net>; Wed, 2 Aug 2000 18:04:09 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjano16560
	for <mpls@uu.net>; Wed, 2 Aug 2000 14:03:49 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjano26539
	for <mpls@uu.net>; Wed, 2 Aug 2000 18:03:31 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA07448
	for mpls@uu.net; Wed, 2 Aug 2000 14:03:31 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjano22395
	for <mpls@mail-control.mail.uu.net>; Wed, 2 Aug 2000 18:03:06 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjano16001
	for <mpls@UU.NET>; Wed, 2 Aug 2000 14:02:37 -0400 (EDT)
Received: from mailman.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailman.cisco.com [171.68.225.9])
	id QQjano24424
	for <mpls@UU.NET>; Wed, 2 Aug 2000 18:02:18 GMT
Received: from chmetz-pc.cisco.com (ssh.cisco.com [171.69.10.34])
	by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id LAA27367;
	Wed, 2 Aug 2000 11:01:27 -0700 (PDT)
Message-Id: <4.3.1.2.20000802134953.00dab350@localhost>
X-Sender: chmetz@localhost
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Wed, 02 Aug 2000 14:04:54 -0700
To: "Metz, E.T." <E.T.Metz@kpn.com>
From: Chris Metz <chmetz@cisco.com>
Subject: RE: your mail
Cc: "'Guy Davies'" <Guy.Davies@telindusk.net>,
        "'Ted44tedT@netscape.net'" <Ted44tedT@netscape.net>,
        prasanna@csa.iisc.ernet.in, mpls@UU.NET
In-Reply-To: <59063B5B4D98D311BC0D0001FA7E45220316A36F@l04.research.kpn.
 com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

At 06:24 PM 08/02/2000 +0100, Metz, E.T. wrote:
>A LER (label-edge-router) is the point at which your MPLS network
>starts/ends. This means there is no MPLS beyond the LER. Therefore, an LSP
>between A and B is not a valid option. It is simply not possible (by
>definition).

Correct.



>You may be referring to another situation though. For instance the case
>where an RSVP session is initiated between A and B? (instead of an LSP). As
>far as I know, the host-to-host RSVP session should (must/will) not trigger
>an RSVP-signalled LSP between LER1 and LER2.

Aggregated RSVP suggests the use of a single RSVP reservation to establish 
an ingress router-to-egress router, "fat pipe" for carrying multiple 
classic RSVP (rfc2205) flows. I suppose an implementation of aggregated 
RSVP could be to use RSVP-TE (where TE stands for traffic engineering) to 
setup an MPLS LSP across the network. Of course this MPLS LSP must be big 
enough to hold all e2e RSVP flows and should not be expanded (or 
contracted) each time an RSVP flows is setup (or torn down).

See:

http://ietf.org/internet-drafts/draft-ietf-issll-rsvp-aggr-02.txt

for more info.


>So, the host-to-host session
>will be forwarded. (If remember correctly the type of a host-to-host RSVP
>session is different from that of an 'MPLS' RSVP session.)

Correct. Classic RSVP is described in:

ftp://ftp.isi.edu/in-notes/rfc2205.txt

RSVP for MPLS Traffic Engineering (RSVP-TE) is described in:

http://ietf.org/internet-drafts/draft-ietf-mpls-rsvp-lsp-tunnel-06.txt


Thanks ...


>Does this help, or did I make things worse?
>
>cheers,
>         Eduard
>
> > -----Original Message-----
> > From: Guy Davies [mailto:Guy.Davies@telindusk.net]
> > Sent: woensdag 2 augustus 2000 16:33
> > To: 'Ted44tedT@netscape.net'; prasanna@csa.iisc.ernet.in
> > Cc: mpls@UU.NET
> > Subject: RE: your mail
> >
> >
> > Also, how does A signal to LER1 if LER1 isn't listening to
> > RSVP on it's
> > non-MPLS interfaces?
> >
> > Regards,
> >
> > Guy
> >
> > > -----Original Message-----
> > > From: Ted44tedT@netscape.net [mailto:Ted44tedT@netscape.net]
> > > Sent: Wednesday, August 02, 2000 4:19 PM
> > > To: prasanna@csa.iisc.ernet.in
> > > Cc: mpls@UU.NET
> > > Subject: Re: your mail
> > >
> > >
> > >
> > > Hi, Gaitonde
> > >
> > > How does the node can signal their requirement for setting up
> > > a RSVP LSP to the LER if it is none-RSVP nodes?
> > >
> > >
> > > Regards,
> > > Ted
> > >
> > >
> > > Gaitonde Anandprasanna <prasanna@csa.iisc.ernet.in> wrote:
> > > >
> > > >
> > > >
> > > > Well i think even if there are applications running on
> > > hosts A and B ,
> > > > though the RSVP deamon is not running on theses machines. these
> > > > applications can signal their requirement for setting up a
> > > RSVP LSP to the
> > > > RSVP process running on the LER and thus can use that LSP.
> > > >   But in case the applications are unable to do the above
> > > then the data
> > > > flow from tha application will be considered as any other
> > > data which has
> > > > not requested for the RSVP LSP. and will recieve normal service.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >                      _____________________________
> >
> > > >                    _ |ANANDPRASANNA GAITONDE     | _
> > > >                   / )|COMP. SCIENCE & AUTOMATION |( \
> > > >                  / / |D-7,IISc HOSTEL            | \ \
> > > >                 / /  |INDIAN INSTITUTE OF SCIENCE|  \ \
> > > >               _( (_  |BANGALORE-560012.          |  _) )_
> > > >               (((\ \>|_/->___________________<-\_|</ /)))
> > > >               (\\\\ \_/ /LAB Ph.(080)3092906  \ \_/ ////)
> > > >                \       /HOSTEL Ph.-            \       /
> > > >                 \    _/     (080)3092452        \_    /
> > > >                 /   /-----------------------------\   \
> > >
> > > >                /  Email Id-                            \
> > > >               /      prasanna@csa.iisc.ernet.in         \
> > > >          ---------------------------------------------
> > > >             -----------------------------------------------
> > > >
> > > >
> > > --------------------------------------------------------------
> > > ------------------
> > > >
> > > >
> > > **************************************************************
> > > ***********
> > > > | | | | __ ___   _____     __ _    _ __ (_) ___ ___     __|
> > > | __ _ _   _
> > > > | |_| |/ _` \ \ / / _ \   / _` |  | '_ \| |/ __/ _ \   / _`
> > > |/ _` | | | |
> > > > |  _  | (_| |\ V /  __/  | (_| |  | | | | | (_|  __/  | (_|
> > > | (_| | |_| |
> > > > |_| |_|\__,_| \_/ \___|   \__,_|  |_| |_|_|\___\___|
> > > \__,_|\__,_|\__, |
> > > >
> > > **************************************************************
> > > ***********
> > > >
> > > >
> > > >
> > > > On Tue, 1 Aug 2000 Ted44tedT@netscape.net wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > I have a question about RSVP LSP:
> > > > >
> > > > > if we have a LSP like below:
> > > > >
> > > > > A--LER1--LSR--LER2--B
> > > > >
> > > > > A,B are none rsvp nodes. LER1, LSR and LER2 are RSVP nodes.
> > > > > if LSP is setup from A to B, what happened to LER1, LSR
> > and LER2?
> > > > >
> > > > > Is there a RSVP LSP established from LER1 to LER2? or
> > > they just forward sessions without another RSVP LSP setup?
> > > > >
> > > > >
> > > > > Thanks in advance
> > > > > John
> > > > >
> > > > > ----------
> > > > > Get your own FREE, personal Netscape Webmail account
> > > today at http://home.netscape.com/webmail/
> > > > >
> > > >
> > > >
> > >
> > > ----------
> > > Get your own FREE, personal Netscape Webmail account today at
> > > http://home.netscape.com/webmail/
> > >
> > This e-mail and any attachments may contain privileged,
> > confidential and/or
> > copyright information and is for the sole use of the intended
> > addressee. If
> > you are not the named recipient, please notify the sender
> > immediately and do
> > not disclose the contents to another person, use it for any
> > purpose, or
> > store or copy the information in any medium.This message is
> > subject to and
> > does not create or vary any contractual relationship between
> > Telindus K-NET
> > Ltd and you.
> >




From owner-mpls@UU.NET  Wed Aug  2 14:56:39 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02001
	for <mpls-archive@lists.ietf.org>; Wed, 2 Aug 2000 14:56:39 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjanr00324;
	Wed, 2 Aug 2000 18:55:48 GMT
Received: by mail-control.mail.uu.net 
	id QQjanr27605
	for mpls-outgoing; Wed, 2 Aug 2000 18:55:15 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjanr27586
	for <mpls@mail-control.mail.uu.net>; Wed, 2 Aug 2000 18:55:04 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjanr13044
	for <mpls@uu.net>; Wed, 2 Aug 2000 14:54:42 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjanr29433
	for <mpls@uu.net>; Wed, 2 Aug 2000 18:54:42 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA16508
	for mpls@uu.net; Wed, 2 Aug 2000 14:54:41 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjanr27514
	for <mpls@mail-control.mail.uu.net>; Wed, 2 Aug 2000 18:54:19 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjanr00948;
	Wed, 2 Aug 2000 14:54:16 -0400 (EDT)
Received: from sj-msg-core-crit.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-crit.cisco.com [171.71.163.10])
	id QQjanr08126;
	Wed, 2 Aug 2000 18:54:00 GMT
Received: from ORANLT (ssh.cisco.com [171.69.10.34])
	by sj-msg-core-crit.cisco.com (8.9.3/8.9.1) with SMTP id LAA09624;
	Wed, 2 Aug 2000 11:53:26 -0700 (PDT)
From: "David R. Oran" <oran@cisco.com>
To: "Routing Area IETF" <routing-discussion@ietf.org>
Cc: <mpls@UU.NET>, <te-wg@UU.NET>, <ip-optical@lists.bell-labs.com>
Subject: Proposal for structuring control plane work in the Routing area: Take 2
Date: Wed, 2 Aug 2000 14:54:03 -0400
Message-ID: <NDBBKHCGKKIOOIJEGCOEMEGDDMAA.oran@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-SMTP-HELO: wodc7-2.corprelay.mail.uu.net
X-SMTP-MAIL-FROM: owner-mpls@UU.NET
X-SMAP-Received-From: outside
X-SMTP-PEER-INFO: wodc7-2.corprelay.mail.uu.net [192.48.96.69]
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
Importance: Normal
X-MIME-Autoconverted: from 8bit to quoted-printable by wodc7mr2.ffx.ops.us.uu.net id QQjagi07159
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit

			This is a Proposal
		...it is only a proposal
			Do not pass GO
		Do not collect 200 lamdas
			(at least not yet...)

Control Plane work organizational Goals
• Goal: divide the work in a way that
– Clearly maintains independence among the control plane signaling protocols
(e.g. RSVP-TE, CR-LDP), the routing protocols (e.g. ISIS, OSPF, BGP), and
the encapsulation methods (e.g. MPLS, GRE, IPSEC)
– Expeditiously moves new work on restoration, link characterization,
disjoint path computation, forward in a way that is generic across layer 1/2
technologies.
• Goal: provide home for "Foo-over-MPLS" sorts of things
• Goal: ensure IPO is focused on optical-specific issues, such as
– encapsulation,
– MIBS,
– Optical-specific requirements on control plane
Proposal
• We initiate a group in the Routing Area to undertake the generalized parts
of the control plane, with specific milestones for
– restoration,
– link management,
– and diversity routing as a starting point.
• This could be either a Routing-Area WG or one or more new WGs
• Work effort will also consider "Foo-over-MPLS" items where consensus
exists to do so

• This obviously need lots of work and has many un-answered questions, but
that's our proposed starting point.
• Further discussion should occur on the routing-discussion@ietf.org mailing
list




From owner-mpls@UU.NET  Wed Aug  2 15:12:13 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08836
	for <mpls-archive@lists.ietf.org>; Wed, 2 Aug 2000 15:12:12 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjans23757;
	Wed, 2 Aug 2000 19:11:15 GMT
Received: by mail-control.mail.uu.net 
	id QQjans10572
	for mpls-outgoing; Wed, 2 Aug 2000 19:10:40 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjans10565
	for <mpls@mail-control.mail.uu.net>; Wed, 2 Aug 2000 19:10:39 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjans16246
	for <mpls@uu.net>; Wed, 2 Aug 2000 15:10:23 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjans11647
	for <mpls@uu.net>; Wed, 2 Aug 2000 19:10:22 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA19101
	for mpls@uu.net; Wed, 2 Aug 2000 15:09:34 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjans10229
	for <mpls@mail-control.mail.uu.net>; Wed, 2 Aug 2000 19:08:47 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjans03591
	for <mpls@UU.NET>; Wed, 2 Aug 2000 15:08:35 -0400 (EDT)
Received: from ogma.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ogma.cisco.com [144.254.74.39])
	id QQjans10282
	for <mpls@UU.NET>; Wed, 2 Aug 2000 19:08:34 GMT
Received: from europe.cisco.com (europe.cisco.com [144.254.52.73])
	by ogma.cisco.com (Postfix) with ESMTP
	id CDF45AC; Wed,  2 Aug 2000 21:08:33 +0200 (MET DST)
Received: from flefauch-8kcdt.cisco.com (sj-dial-1-243.cisco.com [171.68.179.244])
	by europe.cisco.com (8.8.8+Sun/8.8.8) with SMTP id VAA19297;
	Wed, 2 Aug 2000 21:08:28 +0200 (MET DST)
Message-Id: <200008021908.VAA19297@europe.cisco.com>
X-Sender: flefauch@europe.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 
Date: Wed, 02 Aug 2000 15:03:10 +0200
To: Lou Berger <lberger@labn.net>
From: Francois Le Faucheur <flefauch@cisco.com>
Subject: RE: Two last calls (draft-ietf-mpls-diff-ext-06.txt)
Cc: Francois Le Faucheur <flefauch@cisco.com>,
        Shahram Davari <Shahram_Davari@pmc-sierra.com>, mpls@UU.NET
In-Reply-To: <4.3.2.7.2.20000801225758.00def3d0@mail.labn.net>
References: <4.0.2.20000801113940.02298700@europe.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-mpls@UU.NET
Precedence: bulk

Lou,

At 23:53 01/08/2000 -0400, Lou Berger wrote:
>Francois,
>
>At 11:51 AM 8/1/00 +0200, Francois Le Faucheur wrote:
>>Lou,
>>
>> >>We have agreed on an "escape code" above (the first "SHOULD") which allows
>> >>one to maintain whatever flavor of "standard, non-DS, LSP" he/she liked. I
>> >>think this is all the Diff-Serv spec probably needs to say and would
>> >>prefer to avoid having to mention in any way QoS support which were
>> >>pre-Diff-Ext. So I'd like to leave out the new recommendation.
>> >>
>> >>In any case, if a statement about Override option was to be included, I
>> >>would argue that it should be a MAY and not a MUST.
>> >
>> >I believe I said "SHOULD" not MUST.
>>
>>You did say SHOULD, and I did mean that "it should be a MAY and not a SHOULD".
>>
>> > I'd be fine with a MAY.
>>
>>Then, can we agree on the principles of this "compromise" position?  i.e.:
>>         - The text would say that when there is RSVP signaling without 
>> the Diff-Serv object, the LSR SHOULD (instead of MUST) interpret this as 
>> a request for an "E-LSP using Preconfigured EXP<-->PHB Mapping".
>>         - the text would say that an implementation MAY include an option 
>> that overrides this.  When this "override option" is set, the LSR then 
>> treats LSPs signaled without the DiffServ object as standard, non-DS, LSPs.
>>
>>If yes, I'll propose exact wording to reflect this.
>
>Agreed.  Thank you.
>
>I must also apologize.  In all the discussion I dropped one minor, 
>hopefully non-contentious point.  When the above option is set, it is still 
>desirable to allow the setup of E-LSPs that use default mapping.
>
>To signal this, I suggest using a DiffServ Object with the MAPnb set to 0.
>
>Is this too agreeable?
>

Yes.

Francois

>Thanks,
>Lou
>
>>Thanks
>>
>>FRancois
>>
>>_________________________________________________________________
>>Francois Le Faucheur
>>Development Engineer, IOS Layer 3 Services
>>Cisco Systems
>>Office Phone:           +33 4 92 96 75 64
>>Home Office Phone:     +33 4 92 94 00 78
>>Mobile :               +33 6 89 108 159
>>Vmail:                 +33 1 58 04 62 66
>>Fax:                   +33 4 92 96 79 08
>>Email:                  flefauch@cisco.com
>>_________________________________________________________________
>>Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - France
>>_________________________________________________________________
> 
_________________________________________________________________
Francois Le Faucheur   
Development Engineer, IOS Layer 3 Services 
Cisco Systems 
Office Phone:   	+33 4 92 96 75 64
Home Office Phone:     +33 4 92 94 00 78
Mobile :               +33 6 89 108 159
Vmail:                 +33 1 58 04 62 66
Fax:                   +33 4 92 96 79 08
Email:          	flefauch@cisco.com
_________________________________________________________________
Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - France
_________________________________________________________________ 



From owner-mpls@UU.NET  Wed Aug  2 15:35:42 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18376
	for <mpls-archive@lists.ietf.org>; Wed, 2 Aug 2000 15:35:41 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjanu15630;
	Wed, 2 Aug 2000 19:34:54 GMT
Received: by mail-control.mail.uu.net 
	id QQjanu13265
	for mpls-outgoing; Wed, 2 Aug 2000 19:34:22 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjanu13255
	for <mpls@mail-control.mail.uu.net>; Wed, 2 Aug 2000 19:34:17 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjanu08463
	for <mpls@uu.net>; Wed, 2 Aug 2000 15:34:15 -0400 (EDT)
Received: from web5401.mail.yahoo.com by wodc7mr2.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: web5401.mail.yahoo.com [216.115.106.132])
	id QQjanu29123
	for <mpls@uu.net>; Wed, 2 Aug 2000 19:34:15 GMT
Message-ID: <20000802193414.2513.qmail@web5401.mail.yahoo.com>
Received: from [132.177.119.129] by web5401.mail.yahoo.com; Wed, 02 Aug 2000 12:34:14 PDT
Date: Wed, 2 Aug 2000 12:34:14 -0700 (PDT)
From: John Sparr <johnrdb@yahoo.com>
Subject: Label Request abort and withdraw
To: david.charlap@marconi.com
Cc: mpls@UU.NET
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

hi, David

What's the difference of Label Request Abort and Label
Request Withdraw?

Thanks in advance

John

__________________________________________________
Do You Yahoo!?
Kick off your party with Yahoo! Invites.
http://invites.yahoo.com/


From owner-mpls@UU.NET  Wed Aug  2 15:39:34 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19656
	for <mpls-archive@lists.ietf.org>; Wed, 2 Aug 2000 15:39:34 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjanu19674;
	Wed, 2 Aug 2000 19:38:57 GMT
Received: by mail-control.mail.uu.net 
	id QQjanu13723
	for mpls-outgoing; Wed, 2 Aug 2000 19:38:20 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjanu13717
	for <mpls@mail-control.mail.uu.net>; Wed, 2 Aug 2000 19:38:16 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjanu21438
	for <mpls@UU.NET>; Wed, 2 Aug 2000 15:38:07 -0400 (EDT)
Received: from griffin.host4u.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: griffin.host4u.net [209.150.128.163])
	id QQjanu18256
	for <mpls@UU.NET>; Wed, 2 Aug 2000 19:37:36 GMT
Received: from nfloat.labn.net (labn.net [209.204.240.82])
	by griffin.host4u.net (8.8.5/8.8.5) with ESMTP id OAA03721;
	Wed, 2 Aug 2000 14:37:15 -0500
Message-Id: <4.3.2.7.2.20000802153638.02dff6b0@mail.labn.net>
X-Sender: lberger@mail.labn.net
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 02 Aug 2000 15:37:11 -0400
To: Francois Le Faucheur <flefauch@cisco.com>
From: Lou Berger <lberger@labn.net>
Subject: RE: Two last calls (draft-ietf-mpls-diff-ext-06.txt)
Cc: Lou Berger <lberger@labn.net>, Francois Le Faucheur <flefauch@cisco.com>,
        Shahram Davari <Shahram_Davari@pmc-sierra.com>, mpls@UU.NET
In-Reply-To: <200008021908.VAA19297@europe.cisco.com>
References: <4.3.2.7.2.20000801225758.00def3d0@mail.labn.net>
 <4.0.2.20000801113940.02298700@europe.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

Excellent.  We're done!

Lou

At 03:03 PM 8/2/00 +0200, Francois Le Faucheur wrote:
>Lou,
>
>At 23:53 01/08/2000 -0400, Lou Berger wrote:
> >Francois,
> >
> >At 11:51 AM 8/1/00 +0200, Francois Le Faucheur wrote:
> >>Lou,
> >>
> >> >>We have agreed on an "escape code" above (the first "SHOULD") which 
> allows
> >> >>one to maintain whatever flavor of "standard, non-DS, LSP" he/she 
> liked. I
> >> >>think this is all the Diff-Serv spec probably needs to say and would
> >> >>prefer to avoid having to mention in any way QoS support which were
> >> >>pre-Diff-Ext. So I'd like to leave out the new recommendation.
> >> >>
> >> >>In any case, if a statement about Override option was to be included, I
> >> >>would argue that it should be a MAY and not a MUST.
> >> >
> >> >I believe I said "SHOULD" not MUST.
> >>
> >>You did say SHOULD, and I did mean that "it should be a MAY and not a 
> SHOULD".
> >>
> >> > I'd be fine with a MAY.
> >>
> >>Then, can we agree on the principles of this "compromise" position?  i.e.:
> >>         - The text would say that when there is RSVP signaling without
> >> the Diff-Serv object, the LSR SHOULD (instead of MUST) interpret this as
> >> a request for an "E-LSP using Preconfigured EXP<-->PHB Mapping".
> >>         - the text would say that an implementation MAY include an option
> >> that overrides this.  When this "override option" is set, the LSR then
> >> treats LSPs signaled without the DiffServ object as standard, non-DS, 
> LSPs.
> >>
> >>If yes, I'll propose exact wording to reflect this.
> >
> >Agreed.  Thank you.
> >
> >I must also apologize.  In all the discussion I dropped one minor,
> >hopefully non-contentious point.  When the above option is set, it is still
> >desirable to allow the setup of E-LSPs that use default mapping.
> >
> >To signal this, I suggest using a DiffServ Object with the MAPnb set to 0.
> >
> >Is this too agreeable?
> >
>
>Yes.
>
>Francois
>
> >Thanks,
> >Lou
> >
> >>Thanks
> >>
> >>FRancois
> >>
> >>_________________________________________________________________
> >>Francois Le Faucheur
> >>Development Engineer, IOS Layer 3 Services
> >>Cisco Systems
> >>Office Phone:           +33 4 92 96 75 64
> >>Home Office Phone:     +33 4 92 94 00 78
> >>Mobile :               +33 6 89 108 159
> >>Vmail:                 +33 1 58 04 62 66
> >>Fax:                   +33 4 92 96 79 08
> >>Email:                  flefauch@cisco.com
> >>_________________________________________________________________
> >>Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - France
> >>_________________________________________________________________
> >
>_________________________________________________________________
>Francois Le Faucheur
>Development Engineer, IOS Layer 3 Services
>Cisco Systems
>Office Phone:           +33 4 92 96 75 64
>Home Office Phone:     +33 4 92 94 00 78
>Mobile :               +33 6 89 108 159
>Vmail:                 +33 1 58 04 62 66
>Fax:                   +33 4 92 96 79 08
>Email:                  flefauch@cisco.com
>_________________________________________________________________
>Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - France
>_________________________________________________________________



From owner-mpls@UU.NET  Wed Aug  2 16:39:05 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08676
	for <mpls-archive@lists.ietf.org>; Wed, 2 Aug 2000 16:39:05 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjany15629;
	Wed, 2 Aug 2000 20:38:18 GMT
Received: by mail-control.mail.uu.net 
	id QQjany01886
	for mpls-outgoing; Wed, 2 Aug 2000 20:37:43 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjany01864
	for <mpls@mail-control.mail.uu.net>; Wed, 2 Aug 2000 20:37:30 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjany20731
	for <mpls@UU.NET>; Wed, 2 Aug 2000 16:37:24 -0400 (EDT)
Received: from smtprch2.nortel.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtprch2.nortelnetworks.com [192.135.215.15])
	id QQjany15314
	for <mpls@UU.NET>; Wed, 2 Aug 2000 20:37:24 GMT
Received: from zrchb213.us.nortel.com (actually zrchb213) 
          by smtprch2.nortel.com; Wed, 2 Aug 2000 15:32:30 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <P3N08NFS>; Wed, 2 Aug 2000 15:35:54 -0500
Message-ID: <F033F6FEF3F1D111BD150000F8CD14310366D5E1@zcard007.ca.nortel.com>
From: "Bilel Jamoussi" <jamoussi@nortelnetworks.com>
To: "'Vadlamani rao'" <raovrn@rediffmail.com>, mpls@UU.NET
Subject: RE: CR-LDP drafts
Date: Wed, 2 Aug 2000 15:35:50 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFFCC1.3EFBF2D0"
X-Orig: <jamoussi@americasm01.nt.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

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_01BFFCC1.3EFBF2D0
Content-Type: text/plain;
	charset="iso-8859-1"

cr-ldp-04.txt does not introduce any new functionality. It mainly addresses
the IESG comments on cr-ldp-03.txt and some clarifications requested on the
mailing list.

Bilel.

-----Original Message-----
From: Vadlamani rao [mailto:raovrn@rediffmail.com]
Sent: Monday, July 24, 2000 4:36 PM
To: mpls@UU.NET
Cc: raovrn@rediffmail.com
Subject: CR-LDP drafts


Hello,

I have the following questions on CR-LDP drafts and the MIBs ?

1) What are the differences between cr-ldp-04.txt and the previous one
(03.txt) in terms of functionality ?

2) Further, the TE MIB (draft-ietf-mpls-te-mib-04.txt) refers to
cr-ldp-01.txt in the mplsTeMIB MODULE-IDENTITY description part whereas in
other places of the MIB, reference to cr-ldp-03.txt ? It is not consistent
in the draft.

If there are any changes (as per 1) ), how it impacts the MIB ?

I would appreciate if someone answers these questions.

Thanks in advance,
Regards
Rao (raovrn@rediffmail.com)






_________________________________________________
Get Your Free Email At, http://www.rediffmail.com

Partcipate in crazy Re.1 auctions at http://www.rediff.com/auctions





------_=_NextPart_001_01BFFCC1.3EFBF2D0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: CR-LDP drafts</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>cr-ldp-04.txt does not introduce any new =
functionality. It mainly addresses the IESG comments on cr-ldp-03.txt =
and some clarifications requested on the mailing list.</FONT></P>

<P><FONT SIZE=3D2>Bilel.</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Vadlamani rao [<A =
HREF=3D"mailto:raovrn@rediffmail.com">mailto:raovrn@rediffmail.com</A>]<=
/FONT>
<BR><FONT SIZE=3D2>Sent: Monday, July 24, 2000 4:36 PM</FONT>
<BR><FONT SIZE=3D2>To: mpls@UU.NET</FONT>
<BR><FONT SIZE=3D2>Cc: raovrn@rediffmail.com</FONT>
<BR><FONT SIZE=3D2>Subject: CR-LDP drafts</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Hello,</FONT>
</P>

<P><FONT SIZE=3D2>I have the following questions on CR-LDP drafts and =
the MIBs ?</FONT>
</P>

<P><FONT SIZE=3D2>1) What are the differences between cr-ldp-04.txt and =
the previous one (03.txt) in terms of functionality ?</FONT>
</P>

<P><FONT SIZE=3D2>2) Further, the TE MIB =
(draft-ietf-mpls-te-mib-04.txt) refers to cr-ldp-01.txt in the =
mplsTeMIB MODULE-IDENTITY description part whereas in other places of =
the MIB, reference to cr-ldp-03.txt ? It is not consistent in the =
draft.</FONT></P>

<P><FONT SIZE=3D2>If there are any changes (as per 1) ), how it impacts =
the MIB ?</FONT>
</P>

<P><FONT SIZE=3D2>I would appreciate if someone answers these =
questions.</FONT>
</P>

<P><FONT SIZE=3D2>Thanks in advance,</FONT>
<BR><FONT SIZE=3D2>Regards</FONT>
<BR><FONT SIZE=3D2>Rao (raovrn@rediffmail.com)</FONT>
</P>
<BR>
<BR>
<BR>
<BR>
<BR>

<P><FONT =
SIZE=3D2>_________________________________________________</FONT>
<BR><FONT SIZE=3D2>Get Your Free Email At, <A =
HREF=3D"http://www.rediffmail.com" =
TARGET=3D"_blank">http://www.rediffmail.com</A></FONT>
</P>

<P><FONT SIZE=3D2>Partcipate in crazy Re.1 auctions at <A =
HREF=3D"http://www.rediff.com/auctions" =
TARGET=3D"_blank">http://www.rediff.com/auctions</A></FONT>
</P>
<BR>
<BR>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01BFFCC1.3EFBF2D0--


From owner-mpls@UU.NET  Wed Aug  2 16:51:47 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13980
	for <mpls-archive@lists.ietf.org>; Wed, 2 Aug 2000 16:51:46 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjanz27995;
	Wed, 2 Aug 2000 20:50:40 GMT
Received: by mail-control.mail.uu.net 
	id QQjanz03477
	for mpls-outgoing; Wed, 2 Aug 2000 20:50:05 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjanz03467
	for <mpls@mail-control.mail.uu.net>; Wed, 2 Aug 2000 20:50:01 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjanz05395
	for <mpls@uu.net>; Wed, 2 Aug 2000 16:49:43 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjanz24453
	for <mpls@uu.net>; Wed, 2 Aug 2000 20:49:12 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA04798
	for mpls@uu.net; Wed, 2 Aug 2000 16:49:12 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjanz03336
	for <mpls@mail-control.mail.uu.net>; Wed, 2 Aug 2000 20:48:39 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjanz05191
	for <mpls@UU.NET>; Wed, 2 Aug 2000 16:48:33 -0400 (EDT)
Received: from funnel.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQjanz25651
	for <mpls@UU.NET>; Wed, 2 Aug 2000 20:48:18 GMT
Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.131.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA07731; Wed, 2 Aug 2000 16:48:17 -0400 (EDT)
Received: from tnadeau-pc02.cisco.com (ch-janeiro-p13.cisco.com [171.69.209.217])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AAG43942;
	Wed, 2 Aug 2000 16:56:36 -0400 (EDT)
Message-Id: <4.3.2.7.2.20000802164358.0564e480@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 02 Aug 2000 16:45:11 -0400
To: "Bilel Jamoussi" <jamoussi@nortelnetworks.com>,
        "'Vadlamani rao'" <raovrn@rediffmail.com>, mpls@UU.NET
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Subject: RE: CR-LDP drafts
In-Reply-To: <F033F6FEF3F1D111BD150000F8CD14310366D5E1@zcard007.ca.norte
 l.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_6595661==_.ALT"
Sender: owner-mpls@UU.NET
Precedence: bulk

--=====================_6595661==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed


         Not sure if I replied to this earlier, so I will
do so now.

>I have the following questions on CR-LDP drafts and the MIBs ?
>
>1) What are the differences between cr-ldp-04.txt and the previous one 
>(03.txt) in terms of functionality ?
>
>2) Further, the TE MIB (draft-ietf-mpls-te-mib-04.txt) refers to 
>cr-ldp-01.txt in the mplsTeMIB MODULE-IDENTITY description part whereas in 
>other places of the MIB, reference to cr-ldp-03.txt ? It is not consistent 
>in the draft.

         This is an oversight on our part, and we will update the
MIB to reflect the latest references when we churn the next
version.

>If there are any changes (as per 1) ), how it impacts the MIB ?

         Since Bilel stated that there were no changes,
there should be no impact on the TE MIB.

         --Tom

--=====================_6595661==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Not sure
if I replied to this earlier, so I will<br>
do so now.<br>
<br>
<blockquote type=cite cite><font size=2>I have the following questions on
CR-LDP drafts and the MIBs ?</font> <br>
<br>
<font size=2>1) What are the differences between cr-ldp-04.txt and the
previous one (03.txt) in terms of functionality ?</font> <br>
<br>
<font size=2>2) Further, the TE MIB (draft-ietf-mpls-te-mib-04.txt)
refers to cr-ldp-01.txt in the mplsTeMIB MODULE-IDENTITY description part
whereas in other places of the MIB, reference to cr-ldp-03.txt ? It is
not consistent in the draft.</font></blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>This is an
oversight on our part, and we will update the <br>
MIB to reflect the latest references when we churn the next<br>
version.<br>
<br>
<blockquote type=cite cite><font size=2>If there are any changes (as per
1) ), how it impacts the MIB ?</font> </blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Since
Bilel stated that there were no changes, <br>
there should be no impact on the TE MIB.<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>--Tom<br>
</html>

--=====================_6595661==_.ALT--




From owner-mpls@UU.NET  Wed Aug  2 19:41:18 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06286
	for <mpls-archive@lists.ietf.org>; Wed, 2 Aug 2000 19:41:18 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjaok14440;
	Wed, 2 Aug 2000 23:40:40 GMT
Received: by mail-control.mail.uu.net 
	id QQjaok26708
	for mpls-outgoing; Wed, 2 Aug 2000 23:40:08 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjaok26698
	for <mpls@mail-control.mail.uu.net>; Wed, 2 Aug 2000 23:40:03 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjaok07879
	for <mpls@uu.net>; Wed, 2 Aug 2000 19:39:52 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjaok24283
	for <mpls@uu.net>; Wed, 2 Aug 2000 23:39:51 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id TAA22474
	for mpls@uu.net; Wed, 2 Aug 2000 19:39:51 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjaok26645
	for <mpls@mail-control.mail.uu.net>; Wed, 2 Aug 2000 23:39:23 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjaok07819
	for <mpls@UU.NET>; Wed, 2 Aug 2000 19:39:12 -0400 (EDT)
Received: from ogma.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ogma.cisco.com [144.254.74.39])
	id QQjaok12788
	for <mpls@UU.NET>; Wed, 2 Aug 2000 23:39:11 GMT
Received: from europe.cisco.com (europe.cisco.com [144.254.52.73])
	by ogma.cisco.com (Postfix) with ESMTP
	id 1279EB4; Thu,  3 Aug 2000 01:39:11 +0200 (MET DST)
Received: from flefauch-8kcdt.cisco.com (rtp-dial-1-130.cisco.com [10.83.97.130])
	by europe.cisco.com (8.8.8+Sun/8.8.8) with SMTP id BAA25146;
	Thu, 3 Aug 2000 01:39:04 +0200 (MET DST)
Message-Id: <200008022339.BAA25146@europe.cisco.com>
X-Sender: flefauch@europe.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 
Date: Wed, 02 Aug 2000 19:33:49 +0200
To: Lou Berger <lberger@labn.net>, mpls@UU.NET
From: Francois Le Faucheur <flefauch@cisco.com>
Subject: RE: Two last calls (draft-ietf-mpls-diff-ext-06.txt)
Cc: Francois Le Faucheur <flefauch@cisco.com>
In-Reply-To: <4.3.2.7.2.20000802153638.02dff6b0@mail.labn.net>
References: <200008021908.VAA19297@europe.cisco.com>
 <4.3.2.7.2.20000801225758.00def3d0@mail.labn.net>
 <4.0.2.20000801113940.02298700@europe.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-mpls@UU.NET
Precedence: bulk

Lou and everyone,

At 15:37 02/08/2000 -0400, Lou Berger wrote:
>Excellent.  We're done!
>

Here are proposed detailed text changes for review/comment to reflect this
agreement:


          - in section 5.2.1, under MAPnb.
replace "This can be set to any value from 1 to 8" by "This can be set to any
value from 0 to 8." 



          - after the 2nd paragraph of 5.3, add the following new paragraph:
"To establish with RSVP an E-LSP tunnel which uses the Preconfigured EXP<-->PHB
mapping, the sender MAY alternatively create a Path message:   
- with a session type of LSP_Tunnel_IPv4, 
- with the LABEL_REQUEST object, and  
       - with the DIFFSERV object for an E-LSP containing no MAP entries."



          - after the current 6th paragraph, add the following paragraphs:
"If a DIFFSERV object is not present in the Path message, the LSR SHOULD
interpret this as a request for an E-LSP using the Preconfigured EXP<-->PHB
Mapping. However, for backward compatibility purposes with non-Diff-Serv
Quality of Service options allowed by [RSVP_MPLS_TE] such as Integrated
Services Controlled Load or Guaranteed Services, the LSR MAY support a
configurable "override option". When this "override option" is configured, the
LSR interprets a path message without a Diff-Serv object as a request for an
LSP with such non-Diff-Serv Quality of Service. 

If a DIFFSERV object for an E-LSP containing no MAP entry is present in the
Path message, the LSR MUST interpret this as a request for an E-LSP using the
Preconfigured EXP<-->PHB Mapping. In particular, this allows an LSR with the
"override option" configured to support E-LSPs with Preconfigured EXP<-->PHB
Mapping simultaneously with LSPs with non-Diff-Serv Quality of Service.

If a DIFFSERV object for an E-LSP containing at least one MAP entry is present
in the Path message, the LSR MUST interpret this as a request for an E-LSP with
signaled EXP<-->PHB Mapping.

If a DIFFSERV object for an L-LSP is present in the Path message, the LSR MUST
interpret this as a request for an L-LSP."



- in the 11th paragraph of section 5.3:
replace "- the MAPnb field is not within the range 1 to 8" by "- the MAPnb field
is not within the range 0 to 8"




Francois


PS: Below is what section 5.3 would look like with these changes incorporated:

5.3 Handling DIFFSERV Object

To establish an LSP tunnel with RSVP, the sender creates a Path message with a
session type of LSP_Tunnel_IPv4 and with a LABEL_REQUEST object as per
[RSVP_MPLS_TE]. 

To establish with RSVP an E-LSP tunnel which uses the Preconfigured EXP<-->PHB
mapping, the sender creates a Path message:   
- with a session type of LSP_Tunnel_IPv4, 
- with the LABEL_REQUEST object, and 
- without the DIFFSERV object.

To establish with RSVP an E-LSP tunnel which uses the Preconfigured EXP<-->PHB
mapping, the sender MAY alternatively create a Path message:   
- with a session type of LSP_Tunnel_IPv4, 
- with the LABEL_REQUEST object, and 
- with the DIFFSERV object for an E-LSP containing no MAP entries.

To establish with RSVP an E-LSP tunnel which uses a signaled EXP<-->PHB
mapping, the sender creates a Path message :   
- with a session type of LSP_Tunnel_IPv4, 
- with the LABEL_REQUEST object,  
- with the DIFFSERV object for an E-LSP containing one MAP entry for each EXP
value to be supported on this E-LSP.

To establish with RSVP an L-LSP tunnel, the sender creates a Path message:   
- with a session type of LSP_Tunnel_IPv4, 
- with the LABEL_REQUEST object,  
- with the DIFFSERV object for an L-LSP containing the PHB Scheduling Class
(PSC) supported on this L-LSP.

If a path message contains multiple DIFFSERV objects, only the first one is
meaningful; subsequent DIFFSERV object(s) must be ignored and not forwarded.

Each LSR along the path records the DIFFSERV object, when present, in its path
state block.

If a DIFFSERV object is not present in the Path message, the LSR SHOULD
interpret this as a request for an E-LSP using the Preconfigured EXP<-->PHB
Mapping. However, for backward compatibility purposes with other non-Diff-Serv
Quality of Service options allowed by [RSVP_MPLS_TE] such as Integrated
Services Controlled Load or Guaranteed Services, the LSR MAY support a
configurable "override option". When this "override option" is configured, the
LSR interprets a path message without a Diff-Serv object as a request for an
LSP with such non-Diff-Serv Quality of Service. 

If a DIFFSERV object for an E-LSP containing no MAP entry is present in the
Path message, the LSR MUST interpret this as a request for an E-LSP using the
Preconfigured EXP<-->PHB Mapping. In particular, this allows an LSR with the
"override option" configured to support E-LSPs with Preconfigured EXP<-->PHB
Mapping simultaneously with LSPs with non-Diff-Serv Quality of Service.

If a DIFFSERV object for an E-LSP containing at least one MAP entry is present
in the Path message, the LSR MUST interpret this as a request for an E-LSP with
signaled EXP<-->PHB Mapping.

If a DIFFSERV object for an L-LSP is present in the Path message, the LSR MUST
interpret this as a request for an L-LSP.

The destination LSR of an E-LSP or L-LSP responds to the Path message
containing the LABEL_REQUEST object by sending a Resv message:   
- with the LABEL object 
- without a DIFFSERV object.

Assuming the label request is accepted and a label is allocated, the Diff-Serv
LSRs (sender, destination, intermediate nodes) must:   
- update the Diff-Serv Context associated with the established LSPs in their
ILM/FTN as specified in previous sections (incoming and outgoing label), 
- install the required Diff-Serv forwarding treatment (scheduling and dropping
behavior) for this NHLFE (outgoing label).

An LSR that recognizes the DIFFSERV object and that receives a path message
which contains the DIFFSERV object but which does not contain a LABEL_REQUEST
object or which does not have a session type of LSP_Tunnel_IPv4, sends a
PathErr towards the sender with the error code ‘Diff-Serv Error’ and an error
value of ‘Unexpected DIFFSERV object’. Those are defined below in section 5.5.

An LSR receiving a Path message with the DIFFSERV object for E-LSP, which
recognizes the DIFFSERV object but does not support the particular PHB encoded
in one, or more, of the MAP entries, sends a PathErr towards the sender with
the error code ‘Diff-Serv Error’ and an error value of ‘Unsupported PHB’. Those
are defined below in section 5.5.

An LSR receiving a Path message with the DIFFSERV object for E-LSP, which
recognizes the DIFFSERV object but determines that the signaled EXP<-->PHB
mapping is invalid, sends a PathErr towards the sender with the error code
‘Diff-Serv Error’ and an error value of ‘Invalid EXP<-->PHB mapping’. Those are
defined below in section 5.5. The EXP<-->PHB mapping signaled in the DIFFSERV
Object for an E-LSP is invalid when:   
- the MAPnb field is not within the range 0 to 8 or 
- a given EXP value appears in more than one MAP entry, or 
- the PHBID encoding is invalid.

An LSR receiving a Path message with the DIFFSERV object for L-LSP, which
recognizes the DIFFSERV object but does not support the particular PSC encoded
in the PSC field, sends a PathErr towards the sender with the error code
‘Diff-Serv Error’ and an error value of ‘Unsupported PSC’. Those are defined
below in section 5.5.

An LSR receiving a Path message with the DIFFSERV object, which recognizes the
DIFFSERV object but that is unable to allocate the required per-LSP Diff-Serv
context sends a PathErr with the error code "Diff-Serv Error" and the error
value "Per-LSP context allocation failure". Those are defined below in section
5.5.

A Diff-Serv LSR MUST handle the situations where the label request can not be
accepted for other reasons than those already discussed in this section, in
accordance with [RSVP_MPLS_TE] (e.g. reservation rejected by admission control,
a label can not be associated).



>Lou
>
>At 03:03 PM 8/2/00 +0200, Francois Le Faucheur wrote:
>>Lou,
>>
>>At 23:53 01/08/2000 -0400, Lou Berger wrote:
>> >Francois,
>> >
>> >At 11:51 AM 8/1/00 +0200, Francois Le Faucheur wrote:
>> >>Lou,
>> >>
>> >> >>We have agreed on an "escape code" above (the first "SHOULD") which 
>> allows
>> >> >>one to maintain whatever flavor of "standard, non-DS, LSP" he/she 
>> liked. I
>> >> >>think this is all the Diff-Serv spec probably needs to say and would
>> >> >>prefer to avoid having to mention in any way QoS support which were
>> >> >>pre-Diff-Ext. So I'd like to leave out the new recommendation.
>> >> >>
>> >> >>In any case, if a statement about Override option was to be included, I
>> >> >>would argue that it should be a MAY and not a MUST.
>> >> >
>> >> >I believe I said "SHOULD" not MUST.
>> >>
>> >>You did say SHOULD, and I did mean that "it should be a MAY and not a 
>> SHOULD".
>> >>
>> >> > I'd be fine with a MAY.
>> >>
>> >>Then, can we agree on the principles of this "compromise" position?  i.e.:
>> >>         - The text would say that when there is RSVP signaling without
>> >> the Diff-Serv object, the LSR SHOULD (instead of MUST) interpret this as
>> >> a request for an "E-LSP using Preconfigured EXP<-->PHB Mapping".
>> >>         - the text would say that an implementation MAY include an option
>> >> that overrides this.  When this "override option" is set, the LSR then
>> >> treats LSPs signaled without the DiffServ object as standard, non-DS, 
>> LSPs.
>> >>
>> >>If yes, I'll propose exact wording to reflect this.
>> >
>> >Agreed.  Thank you.
>> >
>> >I must also apologize.  In all the discussion I dropped one minor,
>> >hopefully non-contentious point.  When the above option is set, it is still
>> >desirable to allow the setup of E-LSPs that use default mapping.
>> >
>> >To signal this, I suggest using a DiffServ Object with the MAPnb set to 0.
>> >
>> >Is this too agreeable?
>> >
>>
>>Yes.
>>
>>Francois
>>
>> >Thanks,
>> >Lou
>> >
>> >>Thanks
>> >>
>> >>FRancois
>> >>
>> >>_________________________________________________________________
>> >>Francois Le Faucheur
>> >>Development Engineer, IOS Layer 3 Services
>> >>Cisco Systems
>> >>Office Phone:           +33 4 92 96 75 64
>> >>Home Office Phone:     +33 4 92 94 00 78
>> >>Mobile :               +33 6 89 108 159
>> >>Vmail:                 +33 1 58 04 62 66
>> >>Fax:                   +33 4 92 96 79 08
>> >>Email:                  flefauch@cisco.com
>> >>_________________________________________________________________
>> >>Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - France
>> >>_________________________________________________________________
>> >
>>_________________________________________________________________
>>Francois Le Faucheur
>>Development Engineer, IOS Layer 3 Services
>>Cisco Systems
>>Office Phone:           +33 4 92 96 75 64
>>Home Office Phone:     +33 4 92 94 00 78
>>Mobile :               +33 6 89 108 159
>>Vmail:                 +33 1 58 04 62 66
>>Fax:                   +33 4 92 96 79 08
>>Email:                  flefauch@cisco.com
>>_________________________________________________________________
>>Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - France
>>_________________________________________________________________
>  
_________________________________________________________________
Francois Le Faucheur   
Development Engineer, IOS Layer 3 Services 
Cisco Systems 
Office Phone:   	+33 4 92 96 75 64
Home Office Phone:     +33 4 92 94 00 78
Mobile :               +33 6 89 108 159
Vmail:                 +33 1 58 04 62 66
Fax:                   +33 4 92 96 79 08
Email:          	flefauch@cisco.com
_________________________________________________________________
Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - France
_________________________________________________________________ 



From owner-mpls@UU.NET  Wed Aug  2 21:00:14 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28349
	for <mpls-archive@lists.ietf.org>; Wed, 2 Aug 2000 21:00:13 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjaop00863;
	Thu, 3 Aug 2000 00:59:45 GMT
Received: by mail-control.mail.uu.net 
	id QQjaop16949
	for mpls-outgoing; Thu, 3 Aug 2000 00:59:24 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjaop16928
	for <mpls@mail-control.mail.uu.net>; Thu, 3 Aug 2000 00:59:08 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjaop07013
	for <mpls@uu.net>; Wed, 2 Aug 2000 20:59:02 -0400 (EDT)
Received: from smtprch1.nortel.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtprch1.nortelnetworks.com [192.135.215.14])
	id QQjaop29979
	for <mpls@uu.net>; Thu, 3 Aug 2000 00:59:02 GMT
Received: from zrchh190 by smtprch1.nortel.com; Wed, 2 Aug 2000 19:57:46 -0500
Received: from zcard00p.ca.nortel.com by zrchh190;
          Wed, 2 Aug 2000 20:00:22 -0500
Received: from americasm01.nt.com (PHILIPMA-1 [47.72.241.126]) 
          by zcard00p.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) 
          id QCDZ0NVM; Wed, 2 Aug 2000 20:57:32 -0400
Message-ID: <3988BC9A.F3587F4B@americasm01.nt.com>
Date: Wed, 02 Aug 2000 20:28:10 -0400
X-Sybari-Space: 00000000 00000000 00000000
From: "Philip Matthews" <philipma@nortelnetworks.com>
Organization: Nortel Networks
X-Mailer: Mozilla 4.72 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Adrian Farrel <AF@datcon.co.uk>, David Charlap <david.charlap@marconi.com>
CC: mpls@UU.NET
Subject: Re: Comments on draft-mpls-rsvp-lsp-tunnel-06.txt
References: <6DEA508A9A0ED31192E80000F6CC176E2C9D98@monk.datcon.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Orig: <philipma@americasm01.nt.com>
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Thanks for the information.
I guess the answer is that an implementation
SHOULD make an effort to handle such cases,
and not just reject the change with a PathErr
or ResvErr.
- Philip


Adrian Farrel wrote:
> 
> David, Philip,
> 
> We saw exactly the behavior that David describes at the last UNH interop.
> Of course in that situation the h/w is often a bit rudimentary.
> 
> What happened is that the s/w on the downstream box was recycled w/o any
> change to h/w so that the light stayed on on the fiber.  The Path refresh
> was caught by the downstream node which responded with a Resv with a
> different label.
> 
> Correct behavior by the upstream node is, of course, either
> - reject the Resv and tear the LSP down
> - accept the new label and change the switch programming
> 
> Adrian
> --
> Adrian Farrel  mailto:af@datcon.co.uk
> Network Convergence Group
> Data Connection Ltd., Chester, UK
> http://www.datcon.co.uk/
> Tel: +44 (0) 1244 313440  Fax: +44 (0) 1244 312422
> 
> >-----Original Message-----
> >From: David Charlap [mailto:david.charlap@marconi.com]
> >Sent: Wednesday, August 02, 2000 3:31 PM
> >To: mpls@UU.NET
> >Subject: Re: Comments on draft-mpls-rsvp-lsp-tunnel-06.txt
> >
> >
> >I think I can answer one of these....
> >
> >Philip Matthews wrote:
> >>
> >> 4.1.1.1. Downstream
> >>   The text says "A node is expected to send a Resv message before its
> >>   refresh timers expire if the contents of the LABEL object change."
> >>   When could this happen? Once an LSP is set up, is the downstream
> >>   node allowed to change the LABEL object in a Resv refresh?
> >
> >Normally, a downstream node will not change the LABEL object.
> >But there
> >are scenarios where it could happen.  For example.  Imagine this
> >topology:
> >
> >       A---B---C---D
> >
> >A Path and Resv go through and an LSP is established from A to D.
> >
> >Now, the inbound interface on D goes down, but the outbound
> >interface on
> >C remains up.  (Perhaps it was administratively disabled - obviously,
> >this wouldn't happen if the fiber was disconnected.)
> >
> >C thinks the link is still up and continues sending Path refreshes.  D
> >thinks the link is down and tears its state.
> >
> >Now, before C misses enough Resv refreshes to presume link failure and
> >generate a PathErr, the inbound interface on D comes up again.
> >
> >D receives a Path from C (one of the usual refreshes), but it
> >sees it as
> >a new Path (since it no longer has the old state in memory).  So it
> >allocates a new LABEL (which will almost certainly be
> >different from the
> >one it had before) and sends this to C in its Resv messages.
> >
> >Admittedly, this is a rare (and a bit contrived) sitation, but it can
> >happen.




From owner-mpls@UU.NET  Thu Aug  3 00:35:32 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04305
	for <mpls-archive@lists.ietf.org>; Thu, 3 Aug 2000 00:35:32 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjape01327;
	Thu, 3 Aug 2000 04:34:56 GMT
Received: by mail-control.mail.uu.net 
	id QQjape26197
	for mpls-outgoing; Thu, 3 Aug 2000 04:34:36 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjape26180
	for <mpls@mail-control.mail.uu.net>; Thu, 3 Aug 2000 04:34:25 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjape07248
	for <mpls@UU.net>; Thu, 3 Aug 2000 00:34:14 -0400 (EDT)
Received: from csa.iisc.ernet.in by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: csa.iisc.ernet.in [144.16.67.8])
	id QQjape06616
	for <mpls@UU.net>; Thu, 3 Aug 2000 04:34:09 GMT
Received: from topaz.csa.iisc.ernet.in (IDENT:root@topaz.csa.iisc.ernet.in [144.16.67.33])
	by csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id KAA30614
	for <mpls@UU.net>; Thu, 3 Aug 2000 10:04:17 +0530
Received: from localhost (ytr@localhost)
	by topaz.csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id KAA24733
	for <mpls@UU.net>; Thu, 3 Aug 2000 10:04:05 +0530
X-Authentication-Warning: topaz.csa.iisc.ernet.in: ytr owned process doing -bs
Date: Thu, 3 Aug 2000 10:04:05 +0530 (IST)
From: Ramanjaneyulu Y T <ytr@csa.iisc.ernet.in>
To: mpls@UU.NET
Subject: SHIM header
Message-ID: <Pine.LNX.4.10.10008031001250.24727-100000@topaz.csa.iisc.ernet.in>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,
   
    I want to know about SHIM header format . What is difference between
MPLS and SHIM header format. MPLS header contains the following fields.  
 	Label ( 20)
        EXP (3)
        BOS ( 1)
        TTL (8)
     Please suggest some references for SHIM header format.
   
         ThankQ.
                                         
                                         Regards
                                        Ramanjaneyulu Y.T. 
 
 " A real friend is one who walks in when the rest of the world walks
 out."
 ------------------------------------------------------------------------------ 
Y.T.RAMANJANEYULU                        |   My other mail Ids:
E-70,INDIAN INSTITUTE OF SCIENCE         |         ytr@rediffmail.com
BANGALORE - 560012                       |         kingytr@excite.com
PH: 0091 - 080 - 3092622 ( HOSTEL )      |
    0091 - 080 - 3092906 ( LAB )         |
                   visit my home page:www2.csa.iisc.ernet.in/~ytr
--------------------------------------------------------------------------------



From owner-mpls@UU.NET  Thu Aug  3 01:31:35 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27911
	for <mpls-archive@lists.ietf.org>; Thu, 3 Aug 2000 01:31:35 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjapi16781;
	Thu, 3 Aug 2000 05:30:57 GMT
Received: by mail-control.mail.uu.net 
	id QQjapi13542
	for mpls-outgoing; Thu, 3 Aug 2000 05:30:37 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjapi13523
	for <mpls@mail-control.mail.uu.net>; Thu, 3 Aug 2000 05:30:27 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjapi24494
	for <mpls@UU.NET>; Thu, 3 Aug 2000 01:30:21 -0400 (EDT)
Received: from hd1.vsnl.net.in by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: hd1.vsnl.net.in [202.54.30.1])
	id QQjapi07635
	for <mpls@UU.NET>; Thu, 3 Aug 2000 05:30:19 GMT
Received: from hyd.chiplogic.com ([203.197.21.11])
	by hd1.vsnl.net.in (8.8.8/8.8.8) with ESMTP id KAA27617;
	Thu, 3 Aug 2000 10:47:26 +0530 (IST)
Received: from hyd.chiplogic.com (hyd.chiplogic.com [192.168.2.1])
	by hyd.chiplogic.com (8.8.7/8.8.7) with ESMTP id KAA02749;
	Thu, 3 Aug 2000 10:48:41 +0530
Date: Thu, 3 Aug 2000 10:48:41 +0530 (IST)
From: Alok Singh <alok@chiplogic.com>
To: Abhijit <gabhijit@ee.iitb.ernet.in>
cc: mpls@UU.NET
Subject: Re: doubt in LDP Label Mapping procedure.
In-Reply-To: <Pine.GSO.3.96.1000802161439.19966A-100000@bhairav.ee.iitb.ernet.in>
Message-ID: <Pine.LNX.4.04.10008031038300.2548-100000@hyd.chiplogic.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk


Hi abhijeet,
           
regarding your question :
How an LSR can know beforehand that it is ingress for a particular FEC? A
particular LSR can be egress for a particular FEC, but whether it is
ingress or not is dependent upon the source from where packet is entering
MPLS domain.                                    
..................
I think we have to do an explicit configuration. It seems that is the only
way.. As far as your doubt that " an LSR acting as router depends upon the
source from where packet is entering the MPLS domain" i can say something.
An ingress router will have some interfaces related to MPLS domain. And
some other interfaces which will talk to the outside world. Whereas a
general LSR will have all interfaces talking to other nodes in the MPLS
domain only. This is one criterion from which we can differentiate b/w the
two. So i think somebody has to decide which interfaces belongs to a
particular MPLS domain and which to the outside world..
 
WOULD ANYBODY OUT THERE LIKE TO PUT MORE LIGHT ON THIS ISSUE ?

***************************************************************************
 Alok Singh                    Phone No: Office - 3750251/52(extn. no 20)
 Member Technical Staff                  Residence - (040) 6580331 
 Embedded Systems Grp.         Email id: alok@chiplogic.com            
 Chiplogic India Pvt. Ltd.                aloksin_123@yahoo.com  
 Srinagar colony
 Hyberabad - 73
***************************************************************************




From owner-mpls@UU.NET  Thu Aug  3 02:20:07 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28748
	for <mpls-archive@lists.ietf.org>; Thu, 3 Aug 2000 02:20:07 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjapl14167;
	Thu, 3 Aug 2000 06:19:27 GMT
Received: by mail-control.mail.uu.net 
	id QQjapl00024
	for mpls-outgoing; Thu, 3 Aug 2000 06:18:56 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjapl00007
	for <mpls@mail-control.mail.uu.net>; Thu, 3 Aug 2000 06:18:45 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjapl19351
	for <mpls@uu.net>; Thu, 3 Aug 2000 02:18:42 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjapl13269
	for <mpls@uu.net>; Thu, 3 Aug 2000 06:18:26 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id CAA17966
	for mpls@uu.net; Thu, 3 Aug 2000 02:18:26 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjapl29949
	for <mpls@mail-control.mail.uu.net>; Thu, 3 Aug 2000 06:18:08 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjapl29393
	for <mpls@UU.NET>; Thu, 3 Aug 2000 02:17:59 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11])
	id QQjapl12932
	for <mpls@UU.NET>; Thu, 3 Aug 2000 06:17:58 GMT
Received: from bulkrate.cisco.com (bulkrate.cisco.com [171.71.160.24])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id XAA14332;
	Wed, 2 Aug 2000 23:18:13 -0700 (PDT)
Received: from jlawrenc-pc.cisco.com ([144.254.139.2])
	by bulkrate.cisco.com (Mirapoint)
	with ESMTP id AAX18855;
	Wed, 2 Aug 2000 23:18:02 -0700 (PDT)
Message-Id: <4.3.2.7.2.20000803161057.00aecef0@bulkrate.cisco.com>
X-Sender: jlawrenc@bulkrate.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 03 Aug 2000 16:17:26 +1000
To: Ramanjaneyulu Y T <ytr@csa.iisc.ernet.in>
From: Jeremy Lawrence <jlawrenc@cisco.com>
Subject: Re: SHIM header
Cc: mpls@UU.NET
In-Reply-To: <Pine.LNX.4.10.10008031001250.24727-100000@topaz.csa.iisc.e
 rnet.in>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-mpls@UU.NET
Precedence: bulk

The "shim" header and generic MPLS header are the same thing.
"Shim" is colloquial name, describing the MPLS header as
small extra piece (in this case, inserted between the layer 3
header and layer 2 header). See
http://www.dictionary.com/cgi-bin/dict.pl?term=shim

Regards,

Jeremy Lawrence

At 10:04 08/03/2000 +0530, Ramanjaneyulu Y T wrote:
>Hi,
>   
>    I want to know about SHIM header format . What is difference between
>MPLS and SHIM header format. MPLS header contains the following fields.  
>        Label ( 20)
>        EXP (3)
>        BOS ( 1)
>        TTL (8)
>     Please suggest some references for SHIM header format.
>   
>         ThankQ.
>                                         
>                                         Regards
>                                        Ramanjaneyulu Y.T. 
> 
> " A real friend is one who walks in when the rest of the world walks
> out."
> ------------------------------------------------------------------------------ 
>Y.T.RAMANJANEYULU                        |   My other mail Ids:
>E-70,INDIAN INSTITUTE OF SCIENCE         |         ytr@rediffmail.com
>BANGALORE - 560012                       |         kingytr@excite.com
>PH: 0091 - 080 - 3092622 ( HOSTEL )      |
>    0091 - 080 - 3092906 ( LAB )         |
>                   visit my home page:www2.csa.iisc.ernet.in/~ytr
>--------------------------------------------------------------------------------




From owner-mpls@UU.NET  Thu Aug  3 04:43:20 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20611
	for <mpls-archive@lists.ietf.org>; Thu, 3 Aug 2000 04:43:12 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjapu22830;
	Thu, 3 Aug 2000 08:38:26 GMT
Received: by mail-control.mail.uu.net 
	id QQjapu07231
	for mpls-outgoing; Thu, 3 Aug 2000 08:36:38 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjapu07214
	for <mpls@mail-control.mail.uu.net>; Thu, 3 Aug 2000 08:36:28 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjapu13563
	for <mpls@uu.net>; Thu, 3 Aug 2000 04:35:59 -0400 (EDT)
From: seenu@samsung.co.kr
Received: from omail01.samsung.co.kr by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: omail01.samsung.co.kr [203.254.197.73])
	id QQjapu00908
	for <mpls@uu.net>; Thu, 3 Aug 2000 08:35:43 GMT
Received: from localhost (root@localhost)
	by gp_xman. (8.8.8H1/8.8.8) with ESMTP id RAA05096
	for <mpls@uu.net>; Thu, 3 Aug 2000 17:36:31 +0900 (KST)
X-OpenMail-Hops: 3
Date: Thu, 3 Aug 2000 17:37:40 +0900
Message-Id: <H0000e65019b03a1.0965291717.secsw0@MHS>
Subject: MPLS-LDP TEST CASES
MIME-Version: 1.0
TO: mpls@UU.NET
Content-Type: multipart/mixed; boundary="openmail-part-1a2daa78-00000001"
Sender: owner-mpls@UU.NET
Precedence: bulk


--openmail-part-1a2daa78-00000001
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline; filename="mail.txt"
	;Creation-Date="Thu, 3 Aug 2000 17:35:23 +0900"
	;Modification-Date="Thu, 3 Aug 2000 17:37:35 +0900"
Content-Transfer-Encoding: 7bit

Hi,

MPLS-LDP Test cases are available on the net.
Whoever wants, can access it at :

MS word doc :     www.geocities.com/smilybits/mpls-ldp-test-cases.doc

PDF format    :   www.geocities.com/smilybits/mpls-ldp-test-cases.pdf

OR  find the attached .pdf file.


DISCLAIMER
---------------------

Use information present in this document at your own risk.

SAMSUNG INDIA SOFTWARE OPERATIONS, is not responsible for any misinterpretation of drafts or any such matter.
 We do not claim that this document is complete and exhaustive. This is just an attempt to help someone who wants to
 start defining LDP test cases. 

Information in this document is based on draft-ietf-mpls-ldp-06.txt. While we have tried to keep this document accurate
and up-to-date, we cannot guarantee that it is. If you see something in this document that should be corrected or updated,
send mail to this address seenu@samsung.co.kr. We'll see if the information can be corrected.

Unless otherwise noted, the web information does not represent official statements or views of Samsung Electronics India Software Operations.



Author's Address

MPLS Team
Samsung Electronics Co. Ltd.
India Software Operations (SISO)
Level - 6 & 7 , Prestige Meridian - II
No. 30, M.G. Road, Bangalore -560 001

Tel 	: 91-80-5550555
Fax 	: 91-80-5581301
--openmail-part-1a2daa78-00000001
Content-Type: application/octet-stream
Content-Disposition: attachment; filename="Y.pdf"
	;Creation-Date="Thu, 3 Aug 2000 17:37:27 +0900"
Content-Transfer-Encoding: base64

JVBERi0xLjINJeLjz9MNCjE0MyAwIG9iag08PCANL0xpbmVhcml6ZWQgMSANL08gMTQ1IA0v
SCBbIDc2OCA1NTQgXSANL0wgMzIxNzE1IA0vRSA3ODE0OSANL04gNDIgDS9UIDMxODczNiAN
Pj4gDWVuZG9iag0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICB4cmVmDTE0MyAxOCANMDAwMDAwMDAxNiAwMDAwMCBuDQowMDAwMDAwNzEx
IDAwMDAwIG4NCjAwMDAwMDEzMjIgMDAwMDAgbg0KMDAwMDAwMTQ4MCAwMDAwMCBuDQowMDAw
MDAxNjQ1IDAwMDAwIG4NCjAwMDAwMjMyMDIgMDAwMDAgbg0KMDAwMDAyMzQxNSAwMDAwMCBu
DQowMDAwMDIzOTY1IDAwMDAwIG4NCjAwMDAwNTU1NzEgMDAwMDAgbg0KMDAwMDA1NTc5MiAw
MDAwMCBuDQowMDAwMDU2MjU0IDAwMDAwIG4NCjAwMDAwNTY0MzUgMDAwMDAgbg0KMDAwMDA1
Njg3OCAwMDAwMCBuDQowMDAwMDc1ODIwIDAwMDAwIG4NCjAwMDAwNzYwMjYgMDAwMDAgbg0K
MDAwMDA3NzkxOCAwMDAwMCBuDQowMDAwMDAwNzY4IDAwMDAwIG4NCjAwMDAwMDEzMDAgMDAw
MDAgbg0KdHJhaWxlcg08PA0vU2l6ZSAxNjENL0luZm8gMTM2IDAgUiANL1Jvb3QgMTQ0IDAg
UiANL1ByZXYgMzE4NzI1IA0vSURbPGI1MTRlNDE5Mzc2NzAwZmYxNDY1MGJlNjNlYWRhMDg2
PjxiNTE0ZTQxOTM3NjcwMGZmMTQ2NTBiZTYzZWFkYTA4Nj5dDT4+DXN0YXJ0eHJlZg0wDSUl
RU9GDSAgICANMTQ0IDAgb2JqDTw8IA0vVHlwZSAvQ2F0YWxvZyANL1BhZ2VzIDEzOCAwIFIg
DT4+IA1lbmRvYmoNMTU5IDAgb2JqDTw8IC9TIDc1MCAvRmlsdGVyIC9GbGF0ZURlY29kZSAv
TGVuZ3RoIDE2MCAwIFIgPj4gDXN0cmVhbQ0KSIliYGBgBiMWICpkEGRAAEEGViBkYeDYwIAF
TO5kuuzqc+CZge8N/gD2DubdLApNzo1HFeo3NGqYdggpsN9h2dScyXBPUVGh1cFyCT8TXwrr
C+YCxsaE1wL5GlY3uBI4JdlcmCscTjIcM0iVkMyRsOHZCTR3SUOUxta12UV32hW5o661AIkL
LYrZUQJbF2Y7HYDaHSTJN+XWo0duKhe53d6f1VKcu3kiV7qS6OJ0JZFzLtpu51w053SE9c7p
CLYUWCttKbCsSDHKzG+mj9dBkd51N0+0Gk/kurip5FRSGMeS3LIJR2fJqp28rNkZsehK6y1n
sYySWSBiNlRbkaLPE6ctOU+cZp5ozYDqXWKY1u6JRmB1gWK3iZUvGjGx02jhKa/bKMZn8kQu
vAQmsFiEajLYuStTNCe1+/mCw6KBgVGwARouTEpgFgdUAhszLQMhwuLSAGNCqAac2hqwYHRV
6JgtDYcBaEJo3LQM2iUtIFHDwLw5GEjzAbEU2GJfBgGGQIaI4BcMHYw3qzUZJjA2MmQw5nlu
ZGhkF2dgYnzFoMJ4jNGAobN9D8PkpGyGmXqWQF03QFoBAgwAIILWvA1lbmRzdHJlYW0NZW5k
b2JqDTE2MCAwIG9iag00NDUgDWVuZG9iag0xNDUgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0v
UGFyZW50IDEzNyAwIFIgDS9SZXNvdXJjZXMgMTQ2IDAgUiANL0NvbnRlbnRzIDE1NyAwIFIg
DS9NZWRpYUJveCBbIDAgMCA1OTUgODQyIF0gDS9Dcm9wQm94IFsgMCAwIDU5NSA4NDIgXSAN
L1JvdGF0ZSAwIA0+PiANZW5kb2JqDTE0NiAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9U
ZXh0IF0gDS9Gb250IDw8IC9UVDIgMTQ5IDAgUiAvVFQ0IDE1MiAwIFIgL1RUNiAxNTQgMCBS
ID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgMTU4IDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0Nz
NSAxNTMgMCBSID4+IA0+PiANZW5kb2JqDTE0NyAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURl
Y29kZSAvTGVuZ3RoIDIxNDY1IC9MZW5ndGgxIDM2NDIwID4+IA1zdHJlYW0NCkiJfFULdI1X
Fv72Oee/N/IShDyZP7mEkYQmUxIEkdyEFBGJauLRuVcSTUhIKzUYbSqYzFzRUmraoaaiSj06
f8jUm9DRh6GaRY2ibZZSpdJlPIZRuf/se6lh1pqes/5kn3322fvbzwsCEICXIJEzKq93Yu6Z
MR8Bi/cwN7uw3FnxRvf9JwFXI0C1hTMr9R9OLT/Cd2cBa/LkimfK6+QPwYAPf9rQZ8pmT+77
N8dOILEHYB9TUuws+mjV5ALgZX9+07eEGe0/aLeFDU7gc9eS8spZNw7mnuHzS0Bw/7LphU4a
HrAVmDmXz/Zy56wKvxtUw3hWsbw+zVle/MTusiSgtozx9K6YPqOScfOqHeG5r3iuuGJtp+qO
QBTjDyrTdiHS+61HpIpBJGCe/+lzl5rnPXee/+Iya+t877u/tmIz/kE9SMc2uoMQ3KYwSkAW
FG6xxb+gFa8hGGOwgtqjKzrhSWSRYplY1NJKc6Z5CQPxKurM7VRtbuT7V/AhbjOCrxQhCdks
/ySKcUleQIH5J/igBn4YgFzqBCdO8r7JGJZhOfbRXPM2Ww1GNetLwRAMMQ+Yd9ETtWqJdqrN
X7EUu8liFpql6IJouESsedL8GjEowFpsZkyx1KiGIQpTsRCvU5j8kKnX8Dbc5C8mynRtP1vK
wlhMw2/gwkYcpvaUo53Srpq/NS/Cgg7owZhKcYn60EixTvmbg8zTGI+d+Jj99exGNV6t18a7
B5tvmgfREdvJl/bQAS1Re7l1nrnGfA/+jCeBI5LNdiZhPg7gE/wT10SVWYVhyGPLh6gz6RTD
ET8pwsSL4kV5HL3Y24mM9nn8GQZnZBd2Yy/H5gyacYGCKYKeoEm0lK4Jf1EkjsmVskGeUKTe
5Xjb0I1jVIl1eB9HcBTHSGP9j1EOTaHp9Ed6k5qFIa6IW8pHzVc/qlYtxt3s/tHMNm8iFOEY
gTmo4tiuxTY04FN8jmu4jn9RECVTCa0hg5rpimgjosUoUSFWiHVii8yWS+UB1UelqanqqDqt
/U5bZHVa3XffcS9zb3E3mdvNJq6dQNYfg0yO6DyuinXYj+Os/Qt8iXOe+mH9A2gcPc1WZtDv
aTltoUPURJfZS3h3tBgg7Gx1uniO41QtlonlbP0Y78/EafGl+F7clJqMln3ls3KNNOQO+Zn8
VgWpGNVLJahRapwyOTOJ2lAtT9ugbdIOalctKZYiS4XlO2u1dYHPkdaerV+54S5xG+5tXLs+
XElzOBKrUcd138A5OMwR/ZQRN+MGZyGcoqg74+5HmTScRtJTNIGKqZpq6FV6nVZSHb3HHrAP
wsrYY8UQkSecolgsEDVisWjgvUt8Ik6KU6KFkYdIm4yVCTJLjpPj5TT2oVK+KBdwZJfKjfKY
PC4vyu9kC2ctRHVRz6s56g21XjWoJm2EVs67TtuvNWpN2l3trkVYwi2Rlt6WKZYNlnNWi7Wv
Ncf6B+sJ63WfCoqknoxcx0NLhHEPdhEbRbCqohZmdCaFtux5LOchj7viOgZLN+cl0HPP2DqK
MNXB89KSqgx+X0m70YcOocoiJE9V1YytdFY0qw/EQHxODgpT6+U07bCIwiaeRkvEHrGb0tAg
UsRYsUqCLtAGXOB6n4XlNJVmYBO1UH96gZKoCidEJ5lHC5Bi1glFbSiLroIRYJ4qwtP42UX9
eFpfcq9WAWouz6cdWMEZ3Yyv6V3cIc28wtNN8jRy8pSp5XpfCM/Um8h9VsX9GMYTpMxyDA1k
4YmfZBmk5uAq/o1L2i6uqDSepBfdpWq1+sZMMuO5w7jLsIH7rgRDuWMucJXs5bPnNIE73Zdn
SSJ3dQ7GoQgv8NRbahrmKnO+Oducjr/z2zsUR3foLe6IHfwiBR/zfgVf0CLuw6E/7+f/W+4i
NOIyhVI3SuR+aNFmaku0jVqDtk87akngaC/ASq7oc1zNvuxBIZpwGbfIh3MThjg8zniTGXs+
ykSB3It0CkcF92wPnuNp9z2ZwVqqOXqruJ/3cm9c5TkxAftwigSFsEeFbN+H9QznOP+apd/h
DM6nbcwp4qndE9+z34GULCrZXiprWsFTq5ExncW3HG3TiyuO54KdxrKuW3gKRWyhL3KoHpnm
+zypsmGXRzjeXSkIaRRNb/M7B3doIDqjn/YNCcS5s81kUSr38m+Myfy3+NcrAgPpWUbRlv1o
RUcahT7uXMSlpqYOHjQwZUD/fslJfR7/VWLCY717xcfF9vxlj+4x3braoqP0X3TpHBkRHhYa
0qljcIf27YLaBgb4+/m28bFaNCUFIS7DlunQjRiHoWJsw4bFe842JzOcDzEchs6szEdlDN3h
FdMflUxlycn/I5l6TzL1gSQF6SlIiY/TM2y6cdRu03fQuNH5TC+22wp0o8VLj/TSS7x0ANNR
UfxAzwgtsesGOfQMI3NmiSvDYWd19X6+6bb0Yt/4ONT7+jHpx5QRYquop5BB5CVESEb/egGf
AAZlhNvsGUaYze5BYMhuGc4iI2d0foY9IiqqID7OoPRC2yQDtjSjbaxXBOleM4Yl3bB6zeil
Hm+wSK+Pa3TV7gjCJEesf5GtyDkh35DOAo+NdrFs126EzDkf+t8jK2+fnl/z8G2EdGWEluqe
o8tVoxuNo/Mfvo3y/C0oYB38VnTLdLgy2XQtB3F4ns7WxMKCfIMWsknd44nHq3v+FdsyPBzH
FN1oY0uzlbimODg14S4DubOjtoaHp+40mxGeobvG5NuijMERtgKnPbI+GK7c2dvCUvWwR2/i
4+qD2t0LbH1g2/uEf8DDRPGDOy/lFfdQw3MfRJY8iGxZXBCGXqgzknwb+5T8H+7LP6rK+o7j
n+f3lSzvZjDFk17iwFRwKPkTm17H4ebGIlBAQFdIaIlrujhycueIzNOSLrJERRHRuVpZYOv6
449b2HZdOzNtrHaK1nGdTtOxqei2TroKlGfvz/d5nuvlUcP2458BLz7f3z8+3/f3x8P/ls2k
4IMzUQw/pRJqhSqxIitCw7LLg94sTuf6IS3Fm+wLXiIoIPnC+cEpS+0UPcV7iTjIOolKDflO
OJSWFpo4kSViZGNNMcY5Ij5tUnpNWJ6evNrrg4H7KB++XVqalQH3JyXxAjeE/VSBSKiuoMSK
+6hizEHyZ6SVhuRyzok4OfFFnFPn5ESrlydDyYeJ3/PxIU9q9G+EN2FkzsNZISnhc7KXWfm5
C5NzC8pKfDnBctu3uYWDYlb+zGieHQqNzC5Rxsh2SB6jiFyIckm0MEdKhofUFPzpQtSVIQWi
FAmSLxDyls+3/pfGJSXdsE7Y8MRUCpv/4FrCXK1mjzKUlTY4PntQfNDohgcVjFdNlXMLy4LB
uEF5ARxAwWAg2RcIlgeXhs26imSfNzn4srxP3hdcnVPuLGjYfKVhTCiwqRSTeFjKmkTsbGPO
QB5le6mvb6DAmyPcH/Oj3arbSfIsm3YKK2/QarWavgwCxh1Uqh2jMumvtAR5K0G2cge+Z/ZT
EcqvQbwadqs8y7yC8sXgaXAXuBekgsVgkc1CMA91joN2tPEAtyPsaaoyuujr6IvAdrAUbNOK
qRl5O/RZVMHp6GsT2khGeCfSd+vt1IRwC/JLuaywXL+YvoX8dIS3asWmaTSSgTRC+ArSE9D/
Fh4zbCr6r1arzQsIT0Tb30T+Rtgi2EJ7vKNE+DTXEXPlOT7JYfinFulNYAFoAIvhH64/GfXG
Id6I8C0Y1zDY4eA2lehOlLkb77IQ7CT0n23Pm8S8MY/onDB+Mabrwz6dFwvGxPM6C7rAWzFj
c9M4iGrc4HeJ9eM53wpmy130DfhlgOel9ZifMB6i9zCvTqDh7TfFQ2Y7xjlXO0wtiGeCuwXV
JKlttEq5iDU4TD/Qt9NPkU7yFPBPSpHPU6KeQjPgvxK0vwgsQ5uvCT1U8hjM87Dj1B5KRFvl
oAp9H3f8xL5BfD7WtQRlLyOMByQ9DlbABy3gUR4f+s9gn2PdP5GKB15A2Q/RTy6DPscJMHdr
XWkN6n8fbUmiH2sdLAuQXwWf/hz8EhzlMTgIndmIttpJkdvNj2FHgkTQBZpYb6Ac7OUy6D8O
5eOEXqEZ1ibrg7WhHRNaXchjt+Yg9kKDvWceQf3FYDQYr++nJTbjUZb9U8Ga5f3itM3aYl07
Vmh6JeteOsfzZE3F2G1ahAp4DKJfaMuxvO/Q7lq2+AbgMbUq3bSZNct6cyz7hbXG+5H3hG3z
Y+aabu+RdNQfK7QOLTrW8UXUvkmtaLNYb4JOeylPPUl5eHXmaWtht2B+LyMN81HxelfS6D5P
hCZgLe9D3Z0u28IY3VIV+npK7YAvumm38Gu3fKfaLWlah3lWI+m41iHXivA11o0UsfLYMrF5
XzT930F+V+ug5Qif07pNE/PZwnvC6JUmA59jkX4Q1IGJnjSpxbNSChtF5MXn1UWwSvVTluan
GWqE5qrx5IefUpBepN8jzt3NaP+Y1EuNWK8njHhKVs7ibERf8ru4HwC3D3tvjI4Gac6tJcc6
enVb1gyfu7Aa7Gjsu1dAJzhp8ydwCnr8nti/uBv4fBb3A85o0Gjp1bwQ1edxaoP9saNPl04n
uvRpuHXptny38Pku7hbsU4yj0Zk/n498xvEZyecc331OebeNqd+Ms+MP4hzuojJ7X08Ak0EG
2jhinyOdSti8iD16Rn/b7DTmmp3KCbNT32k+Z6w0X9cPm22Y94TonRqxzjLeT85dyn7ie9G5
R7VUWm6fZ62iLPoX92ixOAdIX4v9V0UVaPe3fK/yPlTasO/gT7S3QX2evqueos0Y+wjlJStd
XUh5fCaqNQgjHWc659+ibBb5C9SPqUadgPDzsLvoS7pBNfqvuI7ZJdJOW3mcppXRDuguQ32S
fqYdoBJeK56HPM08wWuPPZ/oqaPdBkHDp6hV7cOcI5jjMWF3CT1x3UNmH8/PmE1f0RTMj8sA
rqPtJp/tj+3CFxHho2ahYfiC29TfEe8N0t5D+Z/QOk8ctXq+ivPpEiUaOEtEXwdokccv/K6K
+/oj7I9eaKyI6rXbzc+E/vebptKHPdSL/cVIyIun0Vov7cJeqhf+sWwD7x+ll+JZI5hfoXhP
9ELjz9Kjegdt0iPQXTfugm6sWy/mspJmItykdpj9KJuDNoj7RnqBeJ/wPeU33+L9YkRolOFH
/yjDYxDvP/Sr9GC8W6keZ8k8Ty89o/v4XSNJ0N5YMMVCxNeDWrDJQqR5LSsloY11In0ZvS63
KzL0zfnH1Rew93bRPGUfxanL8X44RxvkDNqo5EF3F3BnKKiHuJpO45ULlKt8Ku6fjVoczRDl
EnCPn6F8tRT1I1SpHqRKxUR4FGiGHlFPC1OZ9iDeWfejHRt5OuoMo3y9AeEMcz+XE318aiYw
6lrKFPViEGN14DE/HTPmZvj2h9ADjxfh2PHyWKPjtMd4vfGJeXK7qCfK/JHmEZnvgxTLDhTI
jdQB9son8Q6PUK20HY+VNgpIPaDN5kWaL+wBUEABtVaqB/lAVWtpD+wk2HOgG7SBI+Bv6jT6
Edo+CnuIvwsY+Rc4u2CR/yx4FXzg5MXCfV0vPRb1LzQormXSekZOx5swna4tv4emqo/hHJ4M
fwKlhvIZ/TZaZXholXwK6XwmueLaeNqhrqKxQ41nKKQ3abLwoYU/do7OesAm3ATvx1gfW+yv
SXw//6dj/KJgfdeDh4T/99LXhIbOwP8GDZOO0P3Sh9BfG32bsePlwp97sO/tdUJ6vUh3rR+0
Ml1ZQH53OsIbGCfuXteh4mj3pVgcHTgYmXiLAPUDlAfuOO6DJxidNZYu4usYJx7t90YU0lT4
KQBLQmOuuO6lNYy8GvEWYp0/wkTjhXhXFVr6ZODbFQx8SAzSHmLgO2JQ9nEmxq8l7Ff0yXXJ
WR9H5+714XGpv0a5P+PNXEiJbhvVt31eDNJ8gaX3aJzPkh5Xmat74urewF65UZv/T2DvnADH
wG/+133xKcNnhJfPibfx3gjhrfoMvjHfoEaiK/VE/UeJLj+Ac2gK7ItIK0I4FfYjMAppK2Bx
G/VDZZehxoF3QBfYq46hx+x35WjEc6y6V56z20ux6nO9Prx2+qdb9fs3gl0I/w5AZf2vwW6D
vYTyIdQrha1F2gbYqYjngwDiv0d8DpARzgJnAcZ5Gc+YyxmovwfU8HvkOt+h/117g++Pm7UY
YxX4jnhzYrzub4ibts56DmHd3xrO+g9lnW+Ja6ztB7z5TjAx3z6f+43jWKznZ/i9OPB3oleV
VhohSTTOjCgth7y3Z/rDys5/kV6GsU0dBxy/u2f8nBDHJoTgEsI9MLYTpy6OG2YQKH4vOFSr
NcWFtLIHVQ00UqdJxVKTskGbBCYkEkSabeqkqdLiVlqExto8nwe1myDcZZWqTR3WpmnppGn+
wD6Nin6Y9m3K/nf2oJP4Ui3R//7nd//f3b2787Nd8myNmZZXexvP5rcJI7b2LVKFGDmr/ZBM
QwzxlIgMxCqyUmptj3mRv0oMaAbSSAElVa9NSOavlrZ2ye5/IDxbFHdBRAcblZLXF0tbndr3
CNXGtVeJn3BtCr4LfgbeAz+tvUzcap5myeONzWC8BOIJbRvpQ7OFb2cxeFLbQbpVbFK0N8aZ
FL3hmNWqHdF8KuLR3GQQ7tJ0EePGimZipqZ2pdSyWc7vivBui93WLms66URqBqnt3HNbayX7
IHknY6UWd2zBatPGcJtjWBaOOVKyqEpTe1WgI4w3ou0kXWj7Ln6QboMf1XaJbby6gu/RMvYj
2QvGGxKup6WV3O2xqtWiDaHV1uax4vNqtIVS8ECMWEGtl0QhhkWdRm0aNa82h9octmkOWzOH
rZnDLObw5CHaLFpmkdmnnSd57RxZgBZRd6DLbQIrWFGVvb2xivaE5sNKeFewdhRXd5Ra2uXM
fKJjq4r5Sm3tscRt7TUyCjFMfqK03Rc7u6KF1a08WfJ1SyAvWtqwdNsbewGwS+7BbW2ntkut
RI9aAdvieE3x45ITyn7LanJ12B/Zn+T+srt4Lf13Tf+s6b9v+EaV1UoYxSyzP0ivWzvZ39HZ
S+yvZBE1xlbYGokC+Asry1mwz1mFJODreP0yvAJ/Gv6R2P0pL7NyCYa5vyPcXfJm2Zro39es
8ECzsr27WenoilkB9mv2MdmJLv4M3wv/mFXJHvgduA9eZRPkU/hNtp8cgv+q6b9hq/JMsw/Z
LXIAXhLtcgq20KUtC6e0DwRpvErv46vsA3aD7ED0fRHcgavXS8G93LOC/ij7OZsQPbzDamXv
0gz9J0IFsi6ddLD3RFx2siBWDV5hC2zB9MXNgBkxl7RoIBqJLmlGwIgYcWPJsLxsnmzC4uEN
y66ijBOD4fRAJrTAZoUjblv/xj3J+2JkBmVB1XIo86pGUHoftn6pagl2mYxCDH1MQdPQDHSR
OFCehy5Ab0BvqisT0CR0Do+PPIg8iDyIvCLyIPIg8iDyisir0SchSeRA5EDkQOQUkQORA5ED
kVOEnG8ORE4RaRBpEGkQaUWkQaRBpEGkFZEGkQaRVoQJwgRhgjAVYYIwQZggTEWYIEwQpiKi
IKIgoiCiioiCiIKIgogqIgoiCiKqCAOEAcIAYSjCAGGAMEAYijBAGCAMRXhBeEF4QXgV4QXh
BeEF4VWEV+3PJCSJOog6iDqIuiLqIOog6iDqiqiDqIOos3NFrWZ9AqQGpAakppAakBqQGpCa
QmpAakBqzVufUIvBcGymoGloBpJsFWwVbBVsVbFVdbwmIcnaIGwQNghbETYIG4QNwlaEDcIG
YSuiAKIAogCioIgCiAKIAoiCIgrq4E5Ckvj6h/Jrbw27SDMufLiyGdqnfJrcVz5F1pW/SYrK
3yBLyi+QS8rPk7jycySoHP0pnyDcRQWPe6wuPAJGoZegs9AitAzdgXRVuwv9Ddpg+809Do8+
qi/qy/odfdOyXteZxznqXHQuO+84Ny07605mWN3MrZ6jeLSQt1Q5jfIBhA8RlAlVS7BBjDuI
5+x+/A+yQXPLF8aDML0bpnfCdDlM3wpTq4U9Qx3qSWeQOMPEacZsCw7xdSgeDA3hyTR/6/52
LoLf4GW62rA+sx9+HypCS9AlKA7FoAgUgLi6FkY+Y+5pdrkKhaDdkCGHIF1d+L7dscVlVpib
LpU+cZMWOU6oF9yKCEVhZREahX0oQqe51UJvkZD8GkRvYuduwJcFv4fm9xv2S8FXYNcFH4S9
KEJPwU6I0GfcctPnCXdIdKzpx3Hf0o8J/gJizwneB+sXoaBMhzFQAK19NEPuwQNNam9jJL/g
h2B7BD8o0y4SkhtPnSSiprcJkq6VMKEHFZpxUHMz/4L/mN8H/g8sLI7H50bZAbsbKNMXzFa+
GvkZwhYXVqvM4/Oh2HRb+k2+FJjl76AvGrjFf8qf4vORsguXr2Hes2oIwS8ZZXbD3MpneJRP
RO7x1/iz/BQ/xl8M4LrgJ/mqnCbJ0gy7cYun0eE3cRcBwZ8JlNUUj/Lvc5OH+EFjVa4vOdDo
Nx5ZlStAYo3Rn8T6hgNlecafj5fpFjOsf6kv6Cf0Yf2Q7tf36Lv0Hr3T1eHyutpdba5Wl8vl
dDlczEVcneWNutlPcGw7nV5pTocsHaruZbJEIX+QMepi5Flib9VSLHV8mKbs6hmSOm3Y/zru
L9PW575tb/IPU7sjRVJjw/aB/lRZ3zhmx/tTtp4+kSlSOp/FVZtdKVMylinTDXnpcrfdcQSN
5PK17gqh9InL17JZ4ut6PeFLdAxtOXg0+Zgi1yz7H/35vlrtsX+SOp6xf9GTtWOystGTTdkX
jxsnMxXmYe6RZIW1S8tmKo4884wck9cd+WQWsXsqhtPcjhgJSUPMNUwMGcPzZFjGsEeNXBA4
crulIdfqJkGVC7a6Vc5BZa64bowki4ahMviBua4y6wHylQxODNhkMRhUKb9BMzJFM35DTaxP
dcQ5IhGuIhTf61RHnKrB7H2PIoFmZP/DyH41lkYfZXgj09n730xnLzL9/+ff+HA/LQ1MTq2N
jPtHcv6RcShnX339FZ89c9owilOTssGwtWDu9JlXpJ8atyf940l7yp80igNrj2lek80D/mSR
rI2MZYpr5nhSDJgDI/5TyWwpcThj/c9Ysw/Hyhx+TGeHZWcZOVbCekyzJZsTcixLjmXJsRJm
Qo018h157tOZoosMZ4+cbHiJbW7FGc51784Od3nzQ/JAVw7t9k11f+Qg9DrZ3J+12/zDthuS
TRErYskmvM/+w3bVBzdxXPHdvQ/pZMm6s+yzTtYhyZJlQIDkL8miTnzGOJgYBVzAYFIFSALm
K2mMbUxDCP9AICQEdyDQxrQRnSKDJ9MaGxxDAzFp2oS0M4USqEkmUzJDIOlUpFM8lAn43Ley
zaRT7m7f7u3e3nv3e1/36FImTFvHl+wv/8CTdxofHV8SYVryzkIT0CL6UF1PWX1dj2fhsqXU
VHq0lQ/XWQs90st2VLN2Nlxw35pucH7/SdTy0KP1YUdbW1sLJW2BFoTqeqYurOsJ14MkBgOw
WjG7EeZmTMwxTHruuCDUDIwOwmIAhMCtlB0dBXAAENRMUHUZSIJPGAgtFVr7HGrxj89ABt8G
Deo40t4bLEpXEe19+QW0fmntC5aN9VCf0r7X4SkGDn0R2Er7grFek6bDoKOgY3pHJFGQmJ6I
8DDbn4RJV5Km0t5gkkGtgZYJIGDY2ghgg1iU3+Fep5pmnKCDQKAx0ILTeP0/2HgC9AfAtoy/
tSX9+tYJhYzNt6Cxh8cWA20Tm9rGt6QX29JbKD/IiggqDQ6qU/hHmXWCYJ03DJBKzYY4VmeQ
ycDqGClGntMJ8x72IwH3YDuyB8Q7FSMVT4jDFbGRClQJY/E+kKKQR/JIBUAgzKP7bmbwvsah
e8jNDlIOy0Y/45LcJSjMZkCx9YW2OUMyBR2SEoy4IqFf+JKZx5Qj7mO+5AyzwPJehc31FjBT
Vb+nPLTfm2JuODKcToeqWhTF7vW6g8FQebnFUhz0Ksy0cqeDYf1uFTNQ1TJ8edDrVp0OxSKU
TVlpw2Vz+AycgRwz/Z2iHJSJPIC3axbTtE6r6BI7xITIigN4kmYt7rSaXKaQiTEp0dhL9gB8
Xzw2MhJPidCeEG+gyspYqjIl5UazolEsZUGfG03f7RSNFQZotC8KoTiOFxj8hTzvdRf6y0rD
ET+lJcVyTjZvsIUjuTxvkGUcCZeV+r35fE52LsMDlUuKwxEu2b21pfHj3fqt3euPdtXNu/yH
s1fWHf6zz6H7y93BN0f88xbV11TP06asXNH+7KwXa/uuPrJ+wby32jv3fLmw8XDtjlMfvN6Y
WKXf1ppm7tw6ddpaxjyzSgvPq55W+ri+rWh37ZMtpRWQc3/EHMdvcKdB9Y9q8ivcfzjCc6u5
TRyDOAZjbpggZgAbtQw3DmGCv+Rj1RN4IACBfn00WhTCG5ttTJknh/lpGS6eAa+U7t7Vv6U5
fb1eT9aArkX0mJY52drFEKOAkSCiLOMZnI8ESMj5kPj3aybhtrnTzYZYwg6QA33SkfXUuuKp
keGUmALExQoRIMVx7PWTMhHAKyEkJzsrVyarzv088UzD9sFXmx4p8+r1N/G/v8EeTK6d0S/q
S279Wj/auZpKUg2SaGlJ5mr2QlJoaiJNpoOkixzNNAhGEcGVJVKZEFh3WqYTxttcp5lKk7Wu
mkqTGrn+v8LYHmXKSglTImflZBsIU7Nw9kzn6lffP9g1q+4dvb737N2/t93Cx3Dwb/qkuxe/
1Yf1e1SSNv0UPoIVlIEqTwrGDN5koGaXxx/C5Rkm00bsN/is8OflRiHwHsXctGkc8usjKQr6
8AiWokiiuNs8YEm8oTAcjnhfx8rUtmWRxbVkF1bOv7jnBXer8+nFlF8V3knWkgR4XrHmCWEN
FBkBPxQZNxNiWGY2J6Z5MUhhj2ygvK7HY+KNOAqm4sACPLmKTMY7saLfpG/bB+QdkJ5BPi2H
lCMT8X9PWvaBtGkDKQqVwP59WBnbTVDD6E02kxtEmbBhn1a32bTL1IW7Dd1CV+a7wseCsUFq
lBsdDa4maY28xtHkMkZJlA8LYctcMpevER6zdAl/Iuf5D4UPLVfJ5/ynwqcWSbS77cRO43FB
llxqTxotLmvQSqwa3FmTiFOH5rOYdeRnD2UonksfpOWLgSPfaY4BoKlAM21UnSgex8W5siQa
eG8+ksRIODefN/CSKKddMiyJfj8pvrx5b0f75Sv6d0BLFshq6fySsY4b/NkJfbm+ov8AnouT
+Jf9B76pWvScDsc5rWrRBoCdnKsCBH8F4PsBAwE1aMJ6soW8RhiwejylbzmHuQHy1LtGgcPI
LKDfwR8bQZjENQuHWBfrZntYllVMp3EXTqAxoCtiNAZD8K2sGI6nojTseDwSbygL+yIljF+/
+dbF5zEJXWe9HTWjvvOvUB2WIMSaQQIVe7XlJ+39jlN5n7Af2S/YLygXHMbqvGpntdqgdLJv
2rvZpNPIO9xoMh9x1LLV9mql2mH02X2Kz8HIfraB3WU/lHfIeUjtdnarxiykiqpbLVI3qdvV
DvWKalSpXuTsnFKViGarSk2NUFvRwIBoKgUdoQFyuI9gs5VWRV6XOWgmZqo7c9LGCUMQIOeD
yA6XdUhsJ8qkCQUOpzVYURGjHjkSaL4O6ScQb66AiISlkkCc5likjg72SlEqQ6813WmZYpQ1
ilHOKEEvRcfSYiPVfl390jMob/QackJTR6+Vl5c34uY42ITkCWdFwhNh2lAQ9o3HcJ7lDaz5
fqGY+OfZwMxVjUvXGPWvFWz849W7c2Il+p05Mub0e/ux8PnxyiWLn1q1bovz60/+8Ztn+p6u
Gl7gp5qIgT/kgSamoItacI+8J/d8DrPF+ZqTJJljXFd2P3Oa68/+zP6FYpSzsQd+/lmca5M9
LotoNg1gnyZolr0WYrFgSGZEs7psQRuxUfBsyTwOA6AnRbAasC749GKYZpOFlh7zICBslsWh
ba69rrddv3W97+Jc1wxD833Y5wjIQ7nteAgpUx+4yvC4s4B9SdFgfBxuSuhtiiYBGpGApi8A
E2BDcVtB2m/SqBki8gP4HiUl4GUQMWUgyJvvi2HRsrF+SfvGH4brXBs3L51buzpDH8l77vc/
+cvWpksvH9Rv/PUj/Tu8w7Pm+e0vrHsp5ytm7ZLHlz67YtqOt5/cvmHXuZa893ac0//1FfgK
gMr+l+1qgW3qPKP3/+/L92Xfl2PHedhOSGJisAM1JIxsvutgZQRwIBkhUCehlPKoVsjUEAhQ
smkkY60AaRoBqRtBQ8nCo4HySgItDFEYtAg6EIROG6yisElLyTTKiohv9l07Qek2W77/f+1r
W/d853znfDMAT56QiMvGNNEnTePEdDEoVoivi5+LzICEGCqNyqMC0ixpidQpnZIuShyCOVVk
JJbmBYklRFGSetB7BmQJnYQGiUVKIiVM8QRrSOek63ByGgUIG8Sm4ycJioIvED1o0XF6B494
qwyqzO5lz7Ik63FE8RaMcbq9D81Bs5KKvV8PtjYXdGuJNgrRKREvtRAEIyWSSysdClKb5QsO
h8OiJQAZhCQ1Bb2gvODMVZCC8FuJ3+FN/zh50hw0u1HBE/K3QzX/Nu/gbPSVKQCnlgCnptAd
oG7ZGG+z+8Ridab6g/Q90m/sbepndk5VNNWv5KpbVWgqSOLhflVF6cHtRppd0u12SeV1y+8N
RJajndC2vkGjU0kWZUhgjIsNycuHecxbhOM7dItkgp4W8elFuqGTeg86aOiK4pXDMg7LUTkm
k7J1qWz9l+Zw2CmHDLS77kKGC7k8XnsP8huq1IjOXCeQQewlui1Tyr7Ri14aaXYWCe8DGZMb
q+nJSc3DG8HnnIzXKykQ7QAiek7MJCu/QckCDXBlIY8RwEXo+OOWILe4bu6ipg1LN9Td34kf
Jr6cUPPKaUSt2mF+PEygDVm1a3bsbG193Y+fmU+fhs3BOye2n/8MWFcFiBcC61xELtFrTF8t
NNhabW3pnXSnrct+QOu1n1Q+0M4p1zTJSU9VZshNaSfwH+XrOnuauAZfpxDrVuUMXwbOsCDM
AIgyOhyS1x/2Y78FmL/D4K5zwxzJ9aDYsW6EkIVUjpcKQ02MZEGcNGi2Mbs/JiLRk+fuV9PH
/ZfVPU71ycdxSFUpz7NoZ6ETT5kfovOTAgVE1KQwwQIJ6HRIf44ZQznMQb7ye9Ub5VXvHnlm
fn3tL+bnqPDLzj8l9r01f97KtZXz11IV2ZXl7YlN5uObfzUHUTXahn6JXj099Pdtv2p6e8fW
LcDQKlCpGxgqEC29BDV8z5jkUCK84BG+RZXws+iFwgHhQ+GqcEfg/ZDYSZbwCmEBh4WoEBNI
wbphoc8KNOjQKYwRxdpEGwjwWJhFMLXUGXYcIxHpkWBkEUdAKLW8AlSXSBqlPJCkDRq99yCk
HCeDscuvqsVV5O8bn/wEmf9kBy5S+xD9SYM529TOoyK8/inwsWL4AeWCWruJcUQR8p8osmV5
I/k9w18bjbC5pFzSbtO3WcopuOxO2ak3yOv0n8lsPlEoTiWmi98n5ohvUMtskG+cjQWtBW3S
bvd+qcvd5enI7izomNBV1Os5le1q1Fq0Fr21gGqDcrYBYpmh3bALctY+j/SGUMhCIRqKhXCo
D28HzzpnaGnuyNrM5kzcnokyMxlVDqCAxScOriwKGAEcgJHUkFXJm4OiObEcnGP9Ro71poeh
vf1cY7A/5kAOz+T0frIxrz8tfdL/WkAyMcXro4l4sF622n99cCCeolLceiX5lES1Pk7Ux2Fy
HTv0WB2fys1JTkPaGFqRY/Zo1o+WfXHj04er65q2mInbf9j663W9tbHyutp58+s8jdVVP36z
esVy0hXaV7f/1q39r+0tnHRm48fmqk39jZfQ/Mqa2spYbV3i22/+dPO6FZu3W5nzu1AxfUSd
nxiLpitlynKhybbN1kV32TrsHdoJopc8Ye9RjmsfEVeUc5oS0RYK1VKtskCr05h0ujFtj+vP
8l2dXqmhlFi9GWEQq5ESKi37fSBUC2opKdYYd5cbHBFre0qsY2w4I6VXyd0fU5HqyUvpVhyj
18fPw+n/1+souCPdrBh6F54SAalags3NyUcj46T1YRzJfOXMqiZl9d7DzxB39S7KNm89OnQT
12xeMG8F6HUNqsiuKG8f2oiEW3eRYnaaDeYb5runyMyf79r4zvatzYDgZYgqn1P5wH6WCBkZ
ZAlimBKK57pJjJl85KOLaEx3264eTM5s4Gxy6RPgSXQgNT9AgFIuWxMASiclax361+g8AA/6
LMyfLMGjyb0EO9xvcMXTIkwADmySvIEpEcaAA5z1G+X+AvgMDuOJQui4AT4slhDFdFRcTazG
y8nX6JW2FfzfSMdsBlmDJslzHMVyCPkIVicIluEoykczOk0zNt7wZH2HT1qWJyvC52GSZCgo
2RnDzrCYpihE2ESXywPpdKkheOE3wBKbEYl6MMQuL4eKuGYOc314HEHBFZwPsnu6ULNsdPxJ
B5MCw3In5s1cPuMBtB0AJVo6dwDqF4akGiy1LKp184XWkNtaWLm0tPXCBSht2RGhouxI9vzF
kF/JYfN9G8X3DZsAzdBRhiopGYmlqeDq95PwRH6NJOmz5ofNiZMbzIt4OppWeOUimmseo/uG
foF9iXtQuV2A9CuAtAYJfALRb0QbC9FK+/rCB9QTiuL8To4JTPDnpaleZ8yJi5zdTux06rk5
eapm8+l5iMAZBWuZZgYzZYGCbuhFVnjnhAjEgHdgqgwZofJQXWhtqDm0M9QesvlCRdCZ9Bwf
4dOKIJL24LePTZxUMTqyJCC2x+ufBFOhEsBJlFqvZD9JBnfncPP7WdOcVnD3WEvzUc3K6tVw
0RgVpKByAFRHeR/AYoVO/+RsPNpqGIjotB/GgcnFU63uUpCfSyr+kZP83F149nsHWxevqW3Z
Gd+3brb5hSmhwPnDhXOqymZP+PQAUtuDL1YYG67QfVkv76ldcShYcGbLqx/USzZMXTQP01zV
SzN+yNGJXnM9J8bnvfhyoZXolw4/pGvoG4SHuGnMbeG26dvS9hK7mUvcTfKm8BXJ5XEBMSCN
18enNdANXAttYzXW5dJcrvG4kMyj2QAdRTG0h27jLpMfCSxaIBPoHjEIWrEQV9yR5MpLsKLF
hss9kbLZDbsasZfVOpDVvg2nOwKjVMDIUSfypOORfSHx6D9sVw1sE+cZvu/77ue7O/t8dvyT
2DE+44VEhATHcYCQ0FwHC2ERP2oYvwtklL9FVcHRCGk3Qlb+gsQ0OkHDqrFYLWxTyhpoBoQA
KrCuW1dtrUYLpYwtElAogwlNCCiQY+93NgG2OvKdfbK+vD/P87zPy8GRGAXjMBh8hWkJuaSI
FAeDCs3rC7U3DJurGTqoTdYq3AKZv1TM7uwD2ysRW4YEkY8ZTGiiRsAfyFgGt86khq9BkW9a
f7lu/d3qRC+jJHL+ZmnCOh/c2/rmh39Kt/bg0MKbX6KfogXoRbSze9H+2paN16x71rXrrzEl
2AH4/B7gU+ci3HqzvAjIPTWwjF/mEEYHKgN1/vn+lX6hMjAutCX0c+E1VYi4GShzPAUuneYV
9rLRn0EkS8rM6YgiIxoHWXZ7AIN6XMc6w6DxtRgcBiDLMoUYiAJ+v4fZQvYXy0DoGcxQAxja
gcOHm37c31Qyfvn0DUv2DJ1GRRd+NL5ucXX1Cw3PHBQG8kedsq789eCG9PP1oyP8qQcVmmfO
H3p6Di33aAwhO8H93IRMVW67OYkKYF8KRE9EQHGhF2RUkAlfgBFW5AKVo5JYT3CdwoENChrO
uNOE5YOXDRC0OEMEZOR4MiO7f+Bzqm1z/L+kEoBN4UoB2ASkEp4iFRFAf8ri5eCDotn3Tr7m
wZd4cMgg5cLAXevoHSt1B6Lvgug3QvQy12LWQPSiUCAZNE7fpf+k/Fi6nWJKuUwKMsRfI84E
zXiOwLKEg4YaV7H6dPzK18XfWG37tKFqDwv+6+LrIjeGqvDSoV+w2PbeHXqVVXYJcO84cM8A
faudMKJ+xByplbY6NtGNjk2BjSFZDIghT8ATKnIX5RYFi0bQOnUhP1teoDbzP+Rfzv1B8JB2
SP+j8339rH5F10i+aDCymZFgZYT5LoyQP79ElD2Mb576mTkoh5Eth5FttL/ERTiYEnmL4XGh
Zw6OGAaBlEfGwWjlFaYV5FIiSlwhCiNdtL37KdKx5PVbN1L2dMiQD7h3w81mRaq42pY7m4Co
IuoGBo78BoDRM35cucFnOejTPcwLVJAa3N5odR/8wurZd+LIT/4GC2P5GOvzyFsdpy5fPdZ4
dDIO3RnqX7D1JFpx+jJaunja5T+Pf2Hd7f9Y963705IDkOc2KOXvoMOEW2Vjpi+RTAqMXLEC
+27WeANJTjCFWUKHMCgIEaFJWC3cFPgOAUQGE45icg5x3H4O5s4JJl2s2x/DN557kS97lHgL
y9luM7PgqRZAIrTXvQ0VCQP3aiGO3YC0vcLbnMBNMoOzJHY2DwrJUV4ISpg8CSKx7MiTILLY
udOHskezU6O+3agIDwpv3592hyEF4ALGboBzoH2mqpJRdJRKeFgagBSmnD8xqRgTq5Jy/8PB
vuzd3JNfCk/hIspUuShfV2BqKkoOzud1OaLE8BjekMcqK/BKfpncrKzFbfweuUc5KA8ot+V7
ir+b3y53K+/LHyhn8Wf8GfmccgVf5S/L1xTnWrlN2YC38Rvkbcp2LM1Tl+FmfoW8UmnFL/HS
FFzPT5Hrlbl0rjxPkXKVsVoST+STcpVSo0kEO3hRlhUfDvIBGSSwyiwB12PwVJYThPcSwmNV
URIEw0esUkIcPMYOBYyRRCMa0vqRsw+GJD+AJ9i9XtiY6XGgYXZSSEimtJ4ienw9lOa4aqgO
3I8nmB5orgk/5Ez4EZeIMDcAxzjL1oD/u5W6UVysV/9brw7m6UOpoVR1MFcHvwMP9Esp6Itu
GyFPoPJpA1Rsz/OcBtAp+nDwgGown9Nov2xsFHPFKdZKhKLMUoIkv4qOIgVJ6Jh1w7pgXbT+
AW4nl1y9V8u/cr+dvaHPu2CqxJhaoV+ZmkxEmkcClPcAQqHVXJ9HrSH9mazZ3RwNCZGERL2S
RAnFWCIylAtKRXiWMM8S5hPiR+D1AHZmnqnOUptUslrtUHFaPaHijMJROXsou5taQ0NSTtho
PQGkyojemmG8ghWEQQRJ3s5+sznBXE4lB+8tpSx5KFBZfLLtCDsOqRW0Q62wA54ULE3SBrgI
xE8SxCR8LdkEIpym79BLRHyPfEQ/p8QgY2mSVNGZ9Gekm6ZJL91P3qVqxmCXVySxWW4b7EHT
OTaRxAa7SN4KeNJlytHSJJ4NF/vXtSMM+AYXiiUpF5OANAYXSlW4XJqBTem7eI4ke3FImo6/
Jb0uvSV9iM/hq/iK9BVWC3GR9G2pTeqU9mGR8b2l+NGLe9Ti+ZzdYcZX5N6FDDwP5Vhnhw5A
Y0vI6Xu15NiDKcwrzAedvwI67+JC3Bvmd7qELrrLsUvjKZI06pJyC3Pb5LUeaa27zbeZ30q3
OjZrmzxbvZ2+zkBn7uagQ/JAh4M+T9AbzPUFpZwSp5xXIhF/Ya+COEVXjIxKm0Y8bIabwqvD
HeF0WDTCN8M4rBemOeQCkxK3e7mtL7/998NSbjuKRttR2NsPADgFnjQJjpNpdcY2ccjrGd52
509O/HbF1j40BW2y2q3j1hGrHZV9ceDAxQuHDw/iTwZ3rX6neCIsZK9bu61VYJ5WfmU9fPjw
wd37rA7MSdwFdLM6rDULROGI90gumSqgFcIZAXvcBU5N40I6m8Uujvr/zyX5I+F4Nj8hrLue
VNT8p43SsE/KDuXHXgkaBkYwa7ZjsTwMqWW99k50HmnPtfcs6ZrR/MHJN3pbJy+qq0gLA/7o
hd4t/d93+4bO8qesptIlz85a6VTgH7Md5Rjk4+Oi3F3zlUrXNNdcqVltdvTIv9bSsUPaZ7Ii
UlEJUL8yTqvVal0S1WW3V/O6vPo4bZxrqmuN9pJ+WlHb5La81nCn3Jm3OSzKfq/scGkN2hpt
o7ZDe1MTNMPp8DqdDpfD5wz4C3J0L2rypr3Y6+WMKCsXFM7HUY2tg4WcU3di5yehwrS4Xzwh
fizy4pbVMWTE4jEci/qerNrIsucfV83GQna/sTXvsZ2x2Q3MbtTW6e8hd3afgQGfamQFTdj1
hBUmkBMlpTgWc7sfVxXWllX/+rTj1Mmmdc191i/PtMxetLz6/KfN1TPr/kt1mcdGcV9xfH6z
c+xce18zs2v28sUabOwxtsHA0HDZxpcCjhe6BJTa4EYpdkRFiQoYmtiQo0CgEAIRpJwNFQJT
wCZ1Q6gKSaSKCFUQaBAi5YhJHaIIgRHsuO83awj1en9vf7+dP3befN/3fV78L7fpU/VfrN13
KVjedcj4Bk05lIykd1rq4s0/q54v0rjzVQ/fon6E2ilAR/RJfc7e0Im8swUUDCFeGEK8gUQL
3ZK3jPmNtCzvsngxJib5uba50WRsidjqWhxpy1tcsDzUFdoaEV0x3B2zRmk46i2yojVGG2Of
Rj+NUR3Rjtia6JrY9ej1GJPgR0vxaDxWIWmxGr5GmhZ9LvZLqSW2Qnotul56M7qfPyAdjLo5
npOYKBOTeVnyRdlojJco5G8K6HJYWxpASwO7AmTgFNlCqOBCIgCZitQxHgsxC2FbqlLCWhHS
UQNaiDai3egIOo2s6HtKVyocFKLGjOYCd4f9yK+7/Zq/hs3NUcaOyt3tOAJTQQ2668w8QHnM
hRHN1zzffJTQy5PmdFrnuA8x8SqeiToS91KJG5n4auIGNLGMdZl4HYV8qKHJkI8vR+J/etwV
UUgPBNh93uPCuy91u6tCCrsqePNtx2ff6jYRzqQKPoDfJpb/9Jd8MpZk+3wZ48g1X6Xa+J8A
kGW8Hr+PMpWDJ7RqFFZ2dW/YNGm21vf9wu7Vd/+EPMjPGl+5V65cU1VYUI6OnP/128PEJ8Yd
4yK6Gty0bkWjVqW6xk5sWnG4/e+tP34hdbxUGq3QsgtbX+l/a9XXLyOE9VMAntMHNcoC/8cK
uSKqiG7g2rlObiPHMogmsykLyRJWzu9XqNW4T6IxOs+wYVRErMZVAlunxdZAtpOd5EaSImVr
+s8jWW9sPkpC1k3+T1fCMr1l2o0Rz6k0UQ4aQymmf3TNqKXeMeqoM0NDjybDr9oMHSEOv0om
3tTLWSvLsQ4wCW6mdSbHvsA1ObY6tjnf8+7wHXCc9F3y3mTuM4IkijBAstluThTC0nnMQtDS
o7raoC5ULe1qp0qG1SJ1t3papVQEDBuWi+TTskXGha4808DNOTLTvSux7+NiN5HWHXHCI/GZ
pQs9zWEjY1E8QJZuRnmCe8NvV3UqKK9ozVeHL1xe5QlBk7vVXz7vlcVbD1sSjw1j6MrW5KId
c1fdx1lnCYJ9y+TVPborYUkwYaFEoAgGCboyQWMAW49BtDwTe+RSoI/bOqeENF6GRXyyI/CO
xlW7wBfSqDAsLCAkIyqEl8snsjl2gL8tPuAe8g9E+hz9OX9OvEL8C4j1oniHuMlxh6g99CF+
n/gxdYz+mD8ufkZxY6koXciHxR3UZnoH/wfRekag6HDvcNExBmC0d7hY/7mFEMOEhSTDiPCA
kniGposF3iMIPMewMEFyHquVowRRHMFWgQFWhamREi00L7CclbGyLE1TwGMoA7DgzyCyQuDT
XlSk82GmX+jXCzHEw1YMg+JgZJClBSOWrMi16ZQSSKcVOZ0K1IG2bj2lUcfIy/Rl+HeaK+HE
kFr7LKX+f4DaNHs8mMAIyeClIxVBETcQqhsiQqjF+CMqvIpE8CZ0HY02dhpnja+Nq/C8nZa7
j2EoAmKd9agXiqNq+FtqLDWZiBHFqE5fwirWIB3yKdXqrGBV9r8d15zceHmG/EJOq7w4pyvn
XXmzsl/pU88pn6kiw0heHyP7cpl8b1JeTnaR+5njzFlG/ES77CBD8eJxzgIprifGanE9mgeL
HNKWxh/HyfiMEHbQIptdmxRCRMgROhJ6GKJCoQJUQuhwilmHJOZG9KBzSkRXHbAEFC3SSy47
TrGixBdgooDvzAhfmxGuKIArdN0jZI3LseZzeVJylLhLJGFYGIZ5Qbf5NFGp15C2ENT9+yJI
U0l+5EU/uuZH9f4X/Uv9Fr9c0jb1yawIDtwxmKpzpO4nMrsbZq1BtsEeAJpNXza7a2IwBVt4
jhabI+MaHSnsnrnglbivWjw+fwTbJ8NANWILLRtflmExhBHG64GChaPxpahlOHHh/F97ayxq
tnFHcLCWWXtTe/ubdrz7j9kNS2vmoAXj78TLmqfNnl7iEMhvxr6/Jbn+pNH79huzg2WydcaM
nnXz3qkJZoeDjdMnGhdcxYHcyolNxTll8RbMbt3wrLeY7BYkPugjXMND+jihokydqZKuJqaJ
b/I1BZLBByxTSk2UJrpL1elUjVTjnq5uYbdzvGgDbRMKpLiHZj04025BsBO8P2JV2rNQliOf
tOTYe1G+LqJ2ohN3t9CUTDY7KmsH05W36oDpMkQ3iD0LWkxHCqWea9aFVqaVb/W1BtqCdAqI
PAFA4oTcuQBeIWO5XjeY2lN+7Uby2p4zhpHum39Ud2lVK1K/e31xSxd9Kv3DFuO28dD4wbgy
P7mTHL2vvn3XoRMffoDdbC7c+xTQuUxc1xub7UlX0rfE3uZq860MrJC3kdvEs46zgUuOi4EB
ZsA64B7wDjHucne5t9pV7ZsRSIptIjvBVeYrC1iW08vt3XSXfb180HXA1+c64eNspv5UDcfj
Lo9mK5HwiZylmdHu1KRTiCJ4yJnLKRA6XErocB1RshFUeAq8iYKvwn4W4VMUIQol/EGK1EOL
UFQ24pGV5kwqazEcpGoHE/cGE0AH91I3QI/pe4nEDWwMWHWQU7M7Z2Q1vozGqsNjAGiRGmd8
Z3upvm3l6pcbWr3Ik7j3zwHjO+QbPHOT/G/x83M2fdS/c/7Swr+dQTmIgjk3+wDWzRzI3aIR
3WzUx7iSTJJPujJqeQ+kMcRx7VmdWeQEiyZO8GpytWWaWO2dJm/nOI8pFwGrRrcJrM0Oj4L3
59ukHISVYrcTygasnYhVDjVXPr3DjvsZxZidODPXmKQKWpHamDa+zZVRC5NKRiKlIzcIE44f
prhnpUItMh5NPTrvpPHIONOzFslpV+G01xate33xL7p3zk+iXCA2G5K3kI7H7R/N/tW+vSc/
3AX3OxXuNxe04iGCaE8f4YA6mSFUbOfel7Y6DtIH+P/RXTXAUZxleL9v//9ud+9u9/YuySXX
JLe5HDSEuwCRwC0kTUGmkEAbvQwhwRloUrX8VFq0AplCKYiFYqeFhrSkjBY74oChxATswIxV
OoMzxXboOFWkKho6yhAd/izJxffbS0DsmMzee7v77e37vd/zPe/znBJPqYMRQQiiBfhhrlFa
Ev2xOsANRM5K7ysfS79TbvO3VLVQKzTdgqK06fqMtGaeNj8wadNDQzTjRV8IIn7RBZvgb/J1
+LDP9hNlORAuSKOUnyJjikrSXnwgkY/JqfloF3rR1YAswRtSlA5pt/v9UObjjOy3SbnLZJ6K
oSozD6KqaHt0TfRglIlqMcFVtTQUfILrkqTibQRU14mJBGHpBm23Ipix3agGH0CwNmFiTxdm
xjzh6YckYISfJAOD/BNETGL/5NDrEy3Ke4CCG/5aknR/iIRjx0Vprnc6L5bxmlj2MqHQNu/1
Pheq5CMv9ZHX+1woltfosmADk0mQv9A3U57iAbZABOIlIHIIxik65umfQF6hhvDnyJ7x2dHc
35/vQsGPriI/N+bSz62c3+rQG1uW19UhtLSq580Tey8CFpK5s7l3N+1agL7xnS319U8R3rBh
A/wNvItFDbrTZzCokinRS4ws022zAnPaxqZl4KDfMnwBjdJ9AUTpOCgKmoza5XEZy2QhJA4Z
moXGLWSR06gOvzsCP80FgpKYyghLhCaBFir0KqPdwMYgYlzVF4jjYDvVZ52xsEUwISppKxza
OIS7qPyaAaWOgkYdbQPRGr5M2bBNiM2DIwMftdM1+JtoRIGUp9qnh3iPFcyUWQr0Wmr31r62
YeNT8fq5c2o+/DA33MvEm7ZvW1b2nl7bvOji6M/phd7ezzUzHZ4+qELT3Y5nil4own5FXVu9
Xe2uZkoQ+FF6GkrhFO2ielxPZ7VsMFvekmiBpbpt3A4Ys9WUNbsiNQVsmLWoomHKiDIWknZD
P5YVVa5UVMdnhcypqgJGwi4j+D/h4d+Duc/wIHJcVvKxojIP/9LyfKxO57eBaBZ4Tb2dJXRT
rDkk+KSppNyyydthrjIhxyM2oRwxHI5E9lSjaiCgQVeiUmUxf3jaXe65PsE++lV97PJkqxq7
vj4vti4nQa4BfolmIwcv6JNtbJ3HTVpXsKv88cTqZFcVRzpZiLVCk829BmhqAqShGtDpoM1L
QA0Egvf46ttonlBU0fLkzPKAuvnMx5u+htDpX3Ujfu7aU3ty//rz6NaOx3fv6Fy1tdGZZUZj
VnXpigNHTuy5gGQU+ekrow//4uQTdUO7fXjr26+/+caP+l6HkvwAvFMWuNui+t2khopRLVks
fT6ab/wR/RuJPGuxZfirRqfBIoQDQcMfoIMYaaR0RTQvSlLQlCyKkqW4ILolZemjIhoXkQjF
hMJbD5SlX7L7bLzWHrHxNRvZVDBumR41wdg+E42YyAyHMvnygm8ljmUxMS/JmxNnHscTSXwV
ahryNJTgmRlgfCICotgEuKa9lsaRr+gnO95d2bukKDdc0jyn8clUbhha/18PLli7Y8/YXlx9
uLWmYef2sX/ApAG/L8NmOwJfafAzzwxRImSWMaSMKzaJuFs8Jp4Rz4vXRLZY7BC3iH1wgaU5
nmIZGjqVS52nPoUn20D3cCzHMxLmoS96iIuVpZmwMDGve/PIeFuQZnUyo7wSXJ8MkKTheBmF
c8MozAwgJjd658tM/M4nFB4/lGtGb3kZmtQu9xGLj/MloRn8gMB2hxDNsJQZVHVFF/83I8bk
2nWk7xY1FIxjHXxvZA9RsiikpnTYX2HLCp3EX6di+ImfQZqeqg0/ctkm1b/rHNsmUwY0G6n7
8iZZm0bQ06zOzElP+SIK1+zbULlyVnWwVEvO9Ocn89KdO+cOr9C0EYYtTz9H3yDMuROQ1w7z
kqk/DVH0+MXjqpGhSe02haemeVqnA5wjruaOSqel98Vz0ieStIzuoLHK22Ij9xXhaY4dEC8x
V5lR5gbHLuYXC6u5Tcz3mQNML9vD9fA9glTM+Lkkk2QruUq+UqhSFzGLWAkEtSiJgsRKIs0x
MstwUCtKlgVeoiVJZgbxN90IWyXUFvOIX6ViOY66KVQMCYeVzLMT4p9UJ6zfXGcDHxCTRuUR
Cv+w+18QNunv5SEKLoxaD+Kf6FVivGKIN3aiMFqIWnOvoOdzv83d2Aqm6yZ6OvfdsRXo4s7c
EXjRPUwuG6JYqEiCIJJtYnE3e4w9w55nr7FsMdvBbmH74AILE6BBPNJxRE1ijwozX8DeBNpS
eaSxJz9vhHdtpihuP/C3g2YPUQl4ug3eBf1SMTlLSdNpIW2nSxvwQ8JDdkOpUkJXJZaJHYnu
xMHED7nD/FvKCe6EcixxPvFpwkclqhJNcON04lKCS7iRwnQGzru9mywfY/hIEWlw/RIf8/oc
w+uG4RQUFsYdCTaQpsf9htta02GgNbAdBnGjq0UK4kWFcG1NIeooRIVw7Z3yeNwh2rCfohxP
LokZEt0ZkLcDQx13Hhx1cJQ5acf90px0lfOBc8mhNafY6XZoyilxpjnjDuOEK/5SN2nm8vSd
zPN63U1QJtA8b65rI2GSgHSPhDJXgeI9hod6rk+SBoqSgZhJrFzIM3QhyyMk5y4h3eOmzYje
dWb1q9MaDy3fcKgCGKrIaZ7d+WBuOJqZMa9zam6Yie99+9HHHnu0fXnD/rEsbn/jwboFu17N
Ydx4oHVK47bXxkZhzfYSzoY1s6iDrs0HQoFWoVNgBhkEq6U3CA3aZzrLeQRt8D6VU2QZRDVG
cYvyCJpC4/Aj/4+gJTmu+Eh9VVW5y9MKGiGMcR9Pe5X6AlXnt8GkHo/dR8xekYCumWxuuKy5
duG3kkB37K6P2nqWFOPokVWzmrb154qZeO879Z3bniXsvBSUdg/MVAVfts9dcAUNC7cCt0zm
LL7CYn+YDYs4q7cEWqysvQ/v5/YL+5RB8QL+PfsH8YIyzA5zV1T9sHAO/4b7pfBrhd0g7OS2
CbThoVAOkRIFGT5Yy0c6CtYW4AJfjLrPSOXtaN5eTPZwsUtfDe6iy2YQaeCoLZD2w7SAhcGK
lsXL/6tbL/3eWO8/Ufo/fFcNbBPXHX/v7t2d792dP88++xKIPxLHsRMSiE1wyOqjhBAIEAqE
Jt0yIsrHNkZKNjGyqlvTDxEGXdmqBlLUlmiaRAbTGggbSbdJbEWirJpWrUUqqNqiKewDlTWd
WBo04uz/zgmrJm0n+z3/48sl/4/3+8hf++il/KdHcfhEd/fAQHf3CS76AhaP5q9+/En+refn
hl8fHh56dXiY5Xss/1VyEvJ1g5M6ZS1Z4Wv2cd40n9WyvnRRI79OW+drLLpXJG8Xtz9wWNPS
vSIHnB/TtlISc1RWQFHcLqcRcZgHwD15KpxOV9ztti2VcgD1wV8KLcoV8uzZeKcBGumeXEi3
IGkWGJaplj3ins86KlCM0EmWM5hGBv7MVP0n62NYrP3JV8Yxl78/3n68FVoceHHPzmcPP773
CLR28678H/Kz+en8jaa22b/x46PnXhs984PTMJD9CPF1du7DVuKkgGUn3irsEQ4KfLW33fkl
5wEvobJLLVG54+qcyuXUVpVTx7hDVoUkwXzznEgTSHbLNfIBmcjm097TXm6H92nvG953vcTr
RnHM2/lzXB8ewhwOeXLjuLggl3s+M87TjAVtwQyVgOnOLiuUoge1jBhbW0YyjzzWfp4uWwF1
iNgz/UA6ix48xCZ69b7Gro5H135u5ZZqEj+5rzHzzyWrzuY/gRxrYJ7dkGOS67ZeFz1izFFu
eIzYoHdQP1k+kJQlvUnnvD/Xxp1XI7diM9p0VKzQ2rTd2oBy0nsmOq5Kq2JWaWN8b3RXvN/b
rx+OPlcq18XXiE3Keq3V1RR5OCpFS8vjdWomkolmYplSSaSCR44EtXI1Go3GpNKoVfl1tVf/
pv8bFQeTR/zPJ0/5B5IXoxdjWh8+brwQfCX5o+RIpRgdm3uH6enI/A7xxOjiUhZPjJaUFuKQ
acdWEXzYp+Hl0abooPZy9Er0/agYiaoaISaaV+yolmn3UaMqh+fNnR1Hy9JstxYBWyBcgy28
GZMu3IenMI+wG6IuTOw7fQG4E2PrACJ4B5kiHGlKKAELHh2oNSx4rmHBQw0rU5c2rNQSWMoq
YIHnuowSY4fxhEGMNtMCvHOZeLM5Z3Jmk08yIgErEksHrOKSdEkA/xE8WK0jsrnseBlXZgUX
pcvMSvbvGUAumytxTSWursSViyM1IKxqcQTNE5C9wy0F+pU1oN9U7xibrPtAKmAaeu7MA2Wq
h0VAN3DQQFal7nYuGAcW3k3NUxGzukYWvrevgk/rgauzc/UX2sdR6dw1S1a8OVcCFujARz/T
sqquZtnHC2oWenP7vJJF7HdxKtUB2OUrC9g2IwO0VA4DAo6PMZXAwFkS/Tq4K6AtnWm5Gmx6
ux/fX1em+9flf/z5b9+8dfP9RP5Tz472J2rCxXH8q472ux/fmMXVqS1tieLqsF/3tDy0/ZWj
v3jx2NKHHi4JxBb7i/esbzn80u9HYOJL5v7KfV94DfD7t1ZFGIEhpBWueud6Z4dLCvlRkA/4
keH16djwcjoO8rJEJTXIGu1CxpAxYvBdsF02eAOM7wU/ZvA2ivyixGDOqSpyNa1G4D13wImG
O6xEkI8b3jZ/Tj+tv6HzXXqf/j39XX1KF5Du1sN6jU70kNk7tED8LSN1cKZXwpkeR/rc5RUd
DRvvA+ff7Wxw3w0xGAAoBHSEWydtCeyCi+EB9sc8ul1TgxUtDiX1xDK1mTIP9+Rlpby4fH1w
51Mbnswq8jPPYJPEJ/Lbnk0VF91M1j6yZukA/t3Eez/Mfwfq811AhK0kDlz+qmU86tnrOSHw
shgSG7gGTwvX4vkLJ9ley0OUAKJ+Xaey6NPjfj9iYOYM2IwewHMwuP+H0WXHAyp34CkHdvxv
y1Wgg/9i8s5Ixtb5kGSkkDbT+hEPv6n+l1/ed3YDDpVsyTV/LYlDp9t2fvHsCW4oH5zYvbL1
4CS+DCYG8lRAszwGeSro75ZfSJjVaYktIlscbAHp/8Eo7LZ9Cpv16VMEi7zicFBVAY/IeXlT
NmkUVSlXFRUO2pSVWBROUyQoOgopZSippFG90o9kBVGiUFnmOCzCZzmrsScGixNpRSvRajRL
I5phmG6ao60g+ce4GkshXFYhOdJKePImVwMCqc9yqRmEwwBIPA6pV2BeQmxgUsGNdzqBKTpD
m9bsbvyzHdv6kIlDbxZ7s0wW9qSAL9jRgyuCIz5jed3yOh/o/0v5bbj87XpDdLp/gyN5KMjs
n366JlBVxS2GMmEkgxpfAVVS8S1rKVIwRSJHJUEuQgFuMfEIpqTLi6lHVb0pPiXGlCyfFZv5
ZnGQHxRlJ8uzt3ItFEUhRCCyQolahEwSEHQ5RP2qGkMJUi5UyQlari5FdcJDchNay60VmqV1
8iHUSw4JvXIvPaT2oyOkXzgiH6H96g10g1wXrss36HX1NrpNJoVJ+TadVO+he2RamJGm5Xt0
Wq0Sxubes+Si+jSJwyKPzd20I8oideE7xCKRgWWoPm17PQ0+KBYsv1aIEB6b2zgqUhn2DdYy
HqlhReR5FXGYqLxAFUl2iA5JEgRCWHNVCl1GtNqZc3JO6KhjlYydKAwl248UeFuIx86LYRzS
roxjs0D0ZmjjrBmcnTVDs8FCB1Ghd7l5ge9uYPI+Cy+PvSKPkbUhGBXA1MZUAGbEkPiiYmlZ
yGfmgpaFdGYAhhVLZT+ZAhjmCxtEExcUFk0sgDK7OpimYMPhYy8c4XnckR/BnquXsOv8O9if
P5f/x6WLMCDN3Bh7/+smd262DWZEhZPUxU4S7rOOJaS3CTcojeMP8XVpShMckkmCYkKsQysc
zbgDP4UPSjSOU9JyXC814fXSoDIjzkhyGYlLSZom9XQ12UTfIo4NdBvpoLvIftqLv0VfJiek
N+l18iG9TzWeSJJMAyRMkrSW5GgTkf0kROvpJrqPniGXyDU6TWQJsh31Btn5/WDUb7B9wvKr
/2a/3ELjqMI4/j9zy2z3NnvtbkzTsLln02za3Vwat81muzUmadokGtOo0SY20UK0ZkVIHySg
2NA3BR/EF8UHC32oGqRW8cGHUnwogiBSJGixIiIohxKlhGbX78yMtUhlfRBBmDP8vvOdy5yZ
+b75ziWQYcq2KkX4kDIdLl0WlrjQuitTlplQc/5oQ0ZuklxhSXKpmtttN3M3E2puOzW7m6CG
AVVTVdrn6S4KcvWi9PSalnZRlnPr80e8b3qveWWvLKqltFtUBzmZi/aTdeiEgvk/o3iJonbj
5/ioMfObqSFlzXYkVtWOZHIpufrCpdWOmK0xsRhDCOs3mFlaKjIh0sz0HxPe87CV0qts6pPL
bLj0OjtTOnv1a6lekkvrrKHk2vqCDZU+FPOgrzSuTJD3QizzQbBFZSHxiTGPP6NHvf5MlRCa
EGqU6iQRIjtpLlQ1TfG6fZohIaQpIUmhv4W2/KFjtA+5yN7NBd1+b8rXgrpIZ+RYROY0YZq7
q6aMyHPBmtpMhCJE2SvnYvHMijA8a865JLMkMUmUgmwvcjXdGWEtOh+EL9lrZHJ0K05SzH1b
ZsiQVYqjxsb3dDKaSVlxQ/NeQFjIipsqn5EVlrLCZWbkPYOW2D5aYtcUAx+XyStl/r5ssF5K
0+aGRi3/mPN5A/0hIxQnEYz1q+J3ooLI16hsjTVtBUuVT65PNDeLZajHx5Klm6y+dOZA44Gp
lbHxw/F819xjcQocn3TjlvTRzNy+RGDd+9w07LRYGXaTDmNHie/oTLJ4B+sUe23EUxYq1am/
AFXLgP4Z4LoCuPcDnmcAL/XzUX+jllj+ewL0jNAwEH4RiNB4UbovehmIeWxeuwMOVF8Fas4D
Oy4Atactdv4EJOi+xKdA/VsWjaf/Gc1FoIXet/Uc0PYG0P4OsItILQCdxG6duAbs2QTSVO6q
BroVYgPo4Ra9XwL30jtnfwD2fQ7sp7aBGJD/Cig86ODg4ODg4ODg4ODg4ODg4ODg8P8BEhhE
CkMWGasmNFRMZme4trk9gN8IIBSORLfH4tX31OywOjQ0NjW3tLahHUh17t6TRld3Ty/6bg9Q
OHjf4P1DwyOHRg8fGRufeACTD00dnX74kUcrP/s/SQqWScZg0KfqvI638g7exwf5EB/jk3yK
P8tPlcsAtTTxdt7JB6jlEJ+gllleLJf91+922ba+e5IrvpOOBXsEGQGSzH7TAF2WrpGWECMp
LqpJIG3rEnyYtHWZ6p+wdYX0l21dI/1sfqxQKAwmB4onZhfb8ycXj1euQB5jKJjXIJIYQBEn
MItFcn0eJyk/jgnM40k8T/ostVbu/2/0EBZRDdxAlr5WJQsYSFFHaKPkN5nK9PHsFWrRFdJE
6Y8cC1LQA3Y7/dUN/ZSQI8+f0sUwV/Q5RbK9QfnyS/WTj/uzv+px3ez99vWsGRJrI99+s7l5
a8s4qM9RUfjHHPn3AQBhExTdCmVuZHN0cmVhbQ1lbmRvYmoNMTQ4IDAgb2JqDTw8IA0vVHlw
ZSAvRm9udERlc2NyaXB0b3IgDS9Bc2NlbnQgOTA1IA0vQ2FwSGVpZ2h0IDAgDS9EZXNjZW50
IC0yMTEgDS9GbGFncyA0IA0vRm9udEJCb3ggWyAtNjI4IC0zNzYgMjAzNCAxMDQ4IF0gDS9G
b250TmFtZSAvQlBERERHK0FyaWFsLEJvbGQgDS9JdGFsaWNBbmdsZSAwIA0vU3RlbVYgMTMz
IA0vRm9udEZpbGUyIDE0NyAwIFIgDT4+IA1lbmRvYmoNMTQ5IDAgb2JqDTw8IA0vVHlwZSAv
Rm9udCANL1N1YnR5cGUgL1RydWVUeXBlIA0vRmlyc3RDaGFyIDMyIA0vTGFzdENoYXIgMTUw
IA0vV2lkdGhzIFsgMjUwIDAgMCAwIDAgMCA4MzMgMCAwIDAgMCAwIDAgMzMzIDI1MCAyNzgg
NTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgDTUwMCA1MDAgNTAwIDUwMCAwIDAgMCAwIDAgMCA5
MzAgNzIyIDY2NyA3MjIgNzIyIDY2NyA2MTEgNzc4IDc3OCANMzg5IDUwMCA3NzggNjY3IDk0
NCA3MjIgNzc4IDYxMSA3NzggNzIyIDU1NiA2NjcgNzIyIDcyMiAxMDAwIDcyMiANNzIyIDY2
NyAzMzMgMCAzMzMgMCAwIDAgNTAwIDU1NiA0NDQgNTU2IDQ0NCAzMzMgNTAwIDU1NiAyNzgg
MzMzIA01NTYgMjc4IDgzMyA1NTYgNTAwIDU1NiA1NTYgNDQ0IDM4OSAzMzMgNTU2IDUwMCA3
MjIgNTAwIDUwMCA0NDQgDTAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg
MCAwIDAgMCAwIDAgMCAwIDUwMCBdIA0vQmFzZUZvbnQgL0JQRERBRitUaW1lc05ld1JvbWFu
LEJvbGQgDS9Gb250RGVzY3JpcHRvciAxNTEgMCBSIA0+PiANZW5kb2JqDTE1MCAwIG9iag08
PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDMxNTE0IC9MZW5ndGgxIDQ5NzU2ID4+
IA1zdHJlYW0NCkiJXFULUJTXFf7Ovf/dRRTEIILvhQVEgeADFV9hkV1ERFhTExVxBAHFB4Yo
g88aRU0iakOiIRpNqxFtKpmyVsRXVUQbbYKvGK2jjqISi1Gi7cTEGNnbw9ppkv5n/pn7OPfc
77y+CwLgg+WQcKb/Jqb/y6nj9wPHv+LVtJyC7MLUmvQs4Og2gObkFBdZsn2bGnnvOuDlNb1w
RsG//J8U8ZjXVPKMOYum3/FZ/h4QaweKg/LzsnNPR/64C6gL5TOD8nnBf3SHnYBvFM9D8wuK
FlYa0TN57gQ6Dp3zWk62GJprA3Zn8txekL2w0KcfrWc81axvmZtdkJeSHvkQqOXz9Fbha/OL
GDd/te1a9wvn5RWOf1LXAoSsAzrsU79DT5Xq+bvJjegK6Fv8M1bd5E7Rz9RsWN2zdIP0Z2uh
z///fmFYhVA0oRzHMAVfCAkHvYiJMCgInSFoCMaQHwKhyBsRsGIMnAhACr4mH1ShH76hJKyg
MKRjK0KQhk5IwLvYRqP0PazARZqJSj79CdnQC6mUrG9iHJx6P98BDMMH+JB80ZN3vMmqb7CF
+XgLh3AZGhnYpLaxFSdexly9H5m4QBk0WXfDaMzFMmzCdhxBI71NtYbSWRiIaZhHZvKnCFmi
P0GcutJmnz6pz8OP9bez1Qci0kjS38KGJoN0PkfUHwNY5uJj1OA6BdFAmQhfxPJdU7AUVTKC
MSZjDft2iJZQlfTVFezNYOTgDTTQQqoVweqKeqQX4wX2L5aRlqICx3EC99laEo2XBe54nQaC
FyLh4JtW4U38mSNXx3KS2lMwjWbLx+kG3ZJz5V22/Ec043s8oQiaSctEvChR/VtW6H0IZw9t
bGM0JmAOPqVwstFkPrtVLBDLxBuyRl43IoyHOk6fgAkxrFuC3ezXWVzEPzhfSTSWLotlcq96
Uy9hvDHIZy9WYScO4jEpakPtqCNZaAANZs+WUC3dEt2FVUyU02SVWqcX6fUI5lqZgjw+OQsr
sRr7cQ63cR/N1IVPxvDJeHLSenqHTopzcoLMlOWGzSg3Ko0645nqoOrcF9wNHPVWO30xlmUK
pmMxx/oAywlcJUldqQdbGkEpbGkqTaelVEbv0w7aRTV0is7TPXpIP4ogsU5sFIfF38Q5cV52
l32kXf5B1hvBxlXjJ3N2S3f3MfdD3VZH6gG6TG/V13SzJwvduOLjkcjVNZu5YBXK8D4+4phX
4wwucd3d9EgjHnEOfiITV1NnRhRCVupFUezdBJpIC6iUNlAFfUa3qJGeCYh2IoSljxgkUkSm
KBEPxDPpLa0yQS6UH8gv5VNjkerPUqn2qUemRnOYV/2zLS033HDPdJe7t+iBXIsmrjx/7rlY
jOSaS+Es5+J1lnkoxgKO0WKO+FaunCr8BYdxGvUc+3O4xgzVirdV7nEmvkML3CQ4n4q8WJ5j
78uZSeRqyaI8zu1zWUIltIY2sWyh39N2ju8F+pIu0k26Q4/ZJ4hokSBGsUdOMVlMYZkqcsQK
sVZUs5wVl8U1cVs8lX6yg+wpe0mHnCHflqXSJavlV/KSEW4kGMnGbOOUcYE9T1aj1VSVo9aq
7WqHqlOfq0alTRtMH5sOmJrM3uZBZqd5vHmN+U/mw+brZu3Vi+tpLKPvjZ+/DTTZiBFlpMUB
9vuoKJJfiI1U+QsNqFJGkIup4oA8Ij5aWiZvy09FCWDYPdsjmMXq8VfUq4tGgGrCKdEF3zIf
bpTZ4qjYLIJokBxmrDbqmXUWMc4d4qYwiyrWuM/ZmIpXqDP+bbyKhxz/c6qUY5okblCl+Eyk
cCVfQYU4jM3YhjwazOhysQ9P8S4dlBaq4bp7A+fxAA0/ozViWkaKeFOQKDYN5QwdpHH6lOit
73PX36LVuCafcu2/SmkUg124w1m/RLHU03AbXXGBma8HtnDV/hN7uQc/N0K5gx7joIxFhtHA
OY9p+bvbrorkSvpeJHA6Az3Mnd7KxszBm5irWnnUF1VcCcwino6+jzMUwlG8aLqKD/EODskA
hMmdYrnQ8rRhwXtokKl862+Zn7pRLFsqAL9qhkXfdVewhVmIQxxNowzYeScZPXQBI9/FXGTT
mXqzmqQicZZSKQDHmL2COIrlqo27mTWruQ+vIZnWYq87F7X8rgRRGPXnampWxapM7VbV6qg6
Y+qHhdy1WziLt/EdvxoWyuFYfIMfuNZHcvdEcf8kMIpkfsPmiEnyCBKpCwqZAyOYt0dyDDI4
k/PZSgnWcT/t5DfkLB6RH2XiKK5w5wRyn+fw/V5sZwxe4azPxy5mx5W0l1dy0QN9OE5PyZfi
RBHf18qz5cyztYzpOu4yc2gPrigaRnbOXg5+aO1lvmEQnLQHSbqGKyENdlmPrxHKr+tI7tEK
PpfFteGL7hii7pBAlDtNx4mZ8gh14tfQl6tqPL/sI+h1RtGe/WhBAKVjoHsUhvAbuxxOtdNm
s8W/NGL4sKFD4gYPjB3Qv1/fmBejoyL79I7oFR4Wag0JtvTs0b1b1y6dgwI7BXT0f6GDX3tf
n3Ztvdt4mU3KkIIQ5bAmZVlc4VkuI9yanBzdOrdm80L2LxayXBZeSvq1jsuS5VGz/FrTxprT
/0/T9lzT9j9N8rMMx/DoKIvDanGdsVstByhj3EQer7dbJ1lczZ7xWM+4zDP24XFwMB+wOILy
7RYXZVkcrqTi/FJHlp3N7WnrnWhNzPOOjsIe77Y8bMsjV6C1cA8FvkSegQh0DN0j4OXDoFxd
rHaHq7PV3orAJcMc2bku57iJjv+wXu3BUZ1V/NznbnAhm9DwSii7XJKQ7AYoj+YlEkiykIRX
QqC7EXXzgAIZBMyAIkLTCgUuwVo6tlQzlOlYH4mWC+20qYNMOnVa/YPxDydMbS3pWOpAC7R1
WsfRaa6/8+29y2aJgo6Z/HK+853vcb7z/b5zbmpyg8FYSdiSqtuNNouMZVZmSAyharGNpVdb
HrFNYCufho4FzoYHzZ4BP7XFQ74Oo6N1Y9RSWmO8R1YI+9ZYk799ZcotFYtnV0cPp1pzFbN2
ytYAq6Z5OGCdboymWoP8NxbDGpgr50fiZgRb9yCIDesC2E0+FIta0iFsGeCT8KkS59tk1HJP
fFvAyjCWGVvMbXFczTTToqa9wXPTplW9Yr9L02oDZnPUCFpLco1Ya03e2XvIbNr7wtSqwNTR
lpLwWX9WIrBnJ2Q6Dd/41MampE20xHBuNTQlIyuxR0YdCGEF2gPwJGrgTGX8Z1MZme1lGIaf
mIRZVgduZKuVUR03/RXcz/MtLd9vBMzPCAwwblwf3dPq9Oj5/s+Im8yTJNVgd9tWKGQVFzNF
PNW4U/j4JaEvKgnvGZCfMXb6AxAIH61FbFtjFXMR/mCQL/jYQBW1QbG6G6MJPUBtueeoam4o
Zslxtgy6lpz1bOl2LcnpcQNMfpH4/5Mcy1uQ/M30T5pYu6XCkib9B/OmhL1hndHQ2BIN1Jpx
J7YNzaO0hL0saXNa1sTqqJIrOy05VxFWkHJjcjArUZ+l5uNXF6TuGPB4wUrRIwUilj++IvE3
Ni4YvMtJA/bHPEuIW9McN62K0Gi9cpQ+yj2fqcBhtUBuaG4xzXGjbBFkINOMGIGIGTdbB+zu
NiPgN8xX8LVSaO6sjbs3OmD/6liuFemJ4RBbpIoSDrYnOFJLD/jpn0dHmvy1Ivyp3xnj9XIp
j1uyiz46o+4iSyWaDazxEn1P76MmuZx6ZJZ9NBX931Afo9kYvwz6fMgW2GX01wOHgflAEFgA
1AIrHbkCWMJ7ACexRhGvIyTRfs8u2qi9QX5tA4UgG4FctIvU92iOXk7rgJAyXYydhPYc2Ao8
x6kI46ZDX4txC1lCL1C7aBvs9WjP4zVxjmzICUA2+oPY/xL7DFmt/oSeUMm+gXYB1t6IuSHl
OK2GXAO5Bv3L0L8KegRziuU++w20a9AOITYruV+cvYsKgdWY0wA/G8V6XbQEtonYNwtyLpAF
e45SSM9Jr9EzkF9Wi8gnzo0x4twbbp0JcrnwaQywj+xfKtgnudz+BHgHeM/xre42sF+pIGpX
FlAlZDdg8PryRZy5iSTYK7R/UCXDS/bnONcVYJLaQZnQr8HPRu1FWsQ6MEGAvwt74dOntBq2
kP4kzUH/Qvk+cGwzzZF/TGV6PmXgfC0YWwN0Ce4xFzqoGfdhQ45X36dpsM0CCnCHZ5w4+Tk2
0Pl+cT77I/hxHWMagXXMLcGvDvJjf445332WtGEE3LSvwfYV4Gs4VyVwP+xfB4djYg7mY91K
h4dFSQkw91Iwm31wwffkIsERygHucVAIvAYcBB4HdgKbeQzWLcZ45kkn1qyFPpP5wdzAWnwP
9Q53ssDvIsGxxJv5IeJYD0wBMnW8LQfjMTaH3wtzVrwXvAXmI3OLOeNK5rfgfb/0Mp+T7zxF
5mqXaR37IM4ObqXIAuYZS2WQioUsptnMWeabK8WbTPhfwG/ClUl/8D75jbBUQ5TPb5W5mJR4
pxyLpJxMRVhzlf4sfP8mPaAWUr3SSUvVFqpTLOSfEd7PvqEO0fPybynkGRScwRnp6TTJ93zS
MyRt0wbpJcQyX71IT0Ma6pA8Ux2SNK3fvqb1ywcScNupMh3SYMLGkpFq+2/7/xfIl7R+2oz2
B9oQ3s4QncBZyfOhNA8IuBL954BuoNgbkk56O6UBz3q8J6JPgR1qFd56FZWqg8gJOVSFOOWj
f73+A3Cukwqx9udyFb2O9pvIfaUK4X1iL/kS8gXA60OuSuHRKM6NwSUhXb6OIUMOl4RkPiOv
veXItx15EzIMThZybeD8zPWBczSwIslXl5eFFIZscPmZzlOHn6sdft7Oy1tyAWS1U1s4d2fz
O8VeHufNbuT8yDmOcyTnOc5x7vh0mZzfR0/hDG+KPHwRcxPvegYQAsKw73XyCPKwfVDkww57
tydi71ZL7N16uX1E/xByi71H3mdvT9ZUle5zclnQraWijp6nDLeOap3U5eQ0rrsLtUrUpkQd
FfVTXww/toj6FoY+id+heIPHKFveh7gW0ji1lDYrF0hRVqNuol8tQU5m2y6apdykPPUoct0T
9nXlcVos6uYK2qTEqZznKucoU3uYgtofUcv22R+L9bheQXIf+69vpqWcC7TtovZuc/JxmO/e
q5PPq1KhGHMRuWmYsvksIgb1NFPEgec+jK8frOW5RjPUchGHAEPM+Rv5OB4co1GxSNTmerHm
sMhnE8Taw9jzd7SBoc+ges/byJm813aKZ8icF+2rTs2uQz2tU57Fd5CPSPD/IvmUUspFrYw4
WK7uR8y7MLbX+a5gibwv6v1N5CpwRDtKTeJ7gm3fxXfPq7ScofbRLH0J8mMlcv9uytOnI0bN
ZAher0zsjf468X3CdYq/E/i9LCafHsd8vAvhA9cbXrtIxLYOHF3qHYfa0kaZcp8kgXt54tuv
D/feJ/F31GMp+L7Tl5eQUlC+Kuor227KF+Qz8gW7U9T7Ugorv0B9/Ag5/mXwYSotltupTDap
TM3At9kX0f4OlSk/B04gBvvsYXUycngN+n8EHMa8PyCembB9gjE/Aw8OYu69aL9D1cpLVKY9
Aj0fXH0dchj4O+Z9gXqU56lH99Mhud0+IdZn7Bv5K4PX43nAXFeyry7G9Pmn5BvT35pbfiZ9
HMM/XoPXFfN4TKk9TGT/CchPyJFG+Tj1A6fltzB3kA5ITxJJuCfpfaDXwS9phZBngUbc4QHp
CLAWUNUDdAqyBPIDYAjoBc4DN9VFiMVxehXyBR3/KjDkCxRlCftzwK+By64tFbzXWP2pUP9C
o3RtPj3EkMP4JgzT7eNP0UL1W8i18/AtCSh7aC1Dn0A7PF7aIf8Z/RswL03XZtNT6g66907+
3AnS72meiGECVXdzxrsFf6Nxff5/rXe3wP0+BDwo4n+a5ggOXUX8PZQhnaevSu/SUqWXVjIc
PS7ieYrmufeE/iOiP+3+wJX7lSaqSu9H+xGGq6ff6510rHsmFS4PXHjm06MM9TLGA+m6t5se
ZejMsbDQ9zNcPbnvv0MzLUScIpAkOJamI4fsZsg7oZ8k5vl2RlJvxndVc4KfDMR2KwMxJAb6
HmQgdsTA2IOMlLhGOa7Yk+eSez8uz9Pvh/1Sf4NxV2jmv7iv9timrjt8HsaJ49zYSXgmwHFt
k5oLwe5NeDRanWseLetqCBPatJWRrKo89SGSttImGK1Np6mbNBVrTKJJNZKWbrBSleTcDkzT
FEvT6EtVsmpSwmOEDVBbSpuMrWU8Evad40BXBOombf9M1vd9v3PO7/zO75x7ru85sKuu12v7
e+L/4gt7fk1hv18rq/+S09f5fP5OfP5u4F25Wcz/J+DdeRt4Azj0vx6L4v9B/Uf41f+EOqNu
wFl1Pd6Ld0kjIWNpQi4dJOQydsXYZegAtAvfiCrob4Eo6vB1GFsGnQ78AW3n8R3BkX085aoi
2yfOlWgbXw2/p4FcIc74VNi1iP8RsBP4KepPAykgACi/uyfwKNqPFfqO/wD6E5QvQr8PvIM6
7OjLj8N+CVgH+xPgH8AOIFqIdwl+l/ar88gN7qH/Xb3J/ePf1cJ9g5hX9fo7xH+kG75cr79z
XH3+X6ZX7xI3UL0OE/emD/7l7nOzO84XFPvHU/gRcuBK3sWdFSssOwedt0CrjMy1dIOsmmn1
uThrJ7cSgQoqp1brFiKXLp0wFi0pGI5Zaw0n1EF/BGAu4qIkUujlRBZYowdRpnyc+ChVtfyy
45+M0fiY46u07ISfX8CX4AJhpJv3kDzASCv/lKQBBve9svY2NRDf65SUWX74j5AAkAE46QJT
XbYB5T/iVE5V4d+XvnLdb1jG6guG459uNSUm82PI5y3+HgkRwf8CnQ19AzoLeoi/SQyd5wuO
z29lMN5OuO/kG8lcNP+KbyIWdDd/glRrt8OyrDDOYRkxrUQJ38U3a5fH+COkHvowf0haItDL
X0CmNj/reLwqv7PSP8Xq4x/iAjYZXqfgNU34+vgGEgXUTHKOx7CyiVKewzRzWBaBHCnp1Gzz
9yQCYbzf8AyZirZ+voVMgb7In5RTRL6Xn9dun6koGO95WVynxDHKrHzCg7sExYqfw4qf06P9
3alZYpFEDf8ZiQEMi3oS1klYflxcYkAT0AqkgU4A/z/8Y7R8DJ8oP07a+FGSBTphuxByo8QK
HtBGOGId4I/zzVgJfy/WjqL2CcdTpjLbLCsqtdtmp7TMauzjg3hVBxHT5kPOtOlWay9/Wk8l
60yvVh3+KD2lWLofFp4FOm5Sz6CPZ/iTeiW26BXofh1FSnz8R7rzFae03Erj6a9FsRW8FRgA
RgAX3NZiDmtJM8Dh3uSU+SxfL/+27vxVWVYn+vhKTH2lXq2VckpQ53yXA2NNL/8aNslqvkre
L5DgGonOqnWVs6TBivXyVXrCq6QIFapl5Qxt3Ck9hc2zzCkpV8Mt147zZHGZrp438d5x05k8
zRLYjA16SnXq+4KrZwCIARnUqBW3HH8Ftvj93NJpW6QF6AK6ARcepAV3Cw/SIid0jY8vwpwW
4cOyCNNuA48CDPW3kUZgK3AQOAFM0rUtAEN9DCO0gLMAQ8Qoyn6wDbQAGaALyAOjQBHp57UY
pxbeMXAG6AaGARceyHzkMR9tFTxAxvDlFDiDttsNNE3SNM3SPO1KT0r70+XF9sI58y37QUUL
FEVAi1s8bZ6Mh8c8tqfJw/2egIflruRlUUMdxK5wN9QdSZ5JXkzyisVZd7aI9SdKaTkZBkYA
TvqpHyU/Sn77Kd4fH46PxHl/cjg5kuT9x4ePjxzn/bXDtSO13E5WN1iLm2krTdOt1CVolDbS
1dTVzFt5mm/lLsGjvBF7wdXibfNmvDzmtb1NXu73Brws6+3ydnvz3gHvpG533j3gPuEedU9q
cre429wZd9bd5XaLomhRY5Htdo0mlrGjWNQucDfASAac1ZZft+TBA7qc1eUWcJsu2+AmbYXA
MWUBIX31pIhzBD2OaD9VDoFjqgyE8Bd+GHVt4CzA2GF7ZjAWtsPMHw6EGQnT0TAdCJ8Is+5w
PszyiQY2pLMcQpZDOssh9BzSYw8hLiwghGwHtd8g/Aa13yD8lHWjuhZwm7ZscJO2QuCYstig
DC32JWawZxGxGdwJDAOcRMGNQKsu+cACYOxZsM06nFvnW5kc65A1+DOEBAsyuyAztTgzqqzm
hI91IGwHwnboQB0I1IHQKF3Js3a5XPm2yzsK0lA3nLgdn0uVTjtuOu1IdzW4U1tRcKO29mof
37VyN/iEttrAXdf6NWtL+Qngan8X68CvHZaPbULtJtvLyFSc90hFeXFFjr0qH6gQOfaKjPgh
TkGkkkQl43gGBv1E88uaOzX/QvM3Nftsb8i4EDJ+HzJ2hYxECbubhFE9qvlDzQ/aZWHjg7Bx
KGzsDBvPh41eepIE0XCLXRU0TgeNPwWN/UHjxaCxLWisCxprgsY9QRUqQgLEYLMU0/WaZ9rT
AsblgPHngPFOwHgzYDwXML4VMBoCcKfn8PE0cBtRvF3zwv31hqg3ZtUbrzKsDb1X+oinlzF6
LzF4iTTjIsc9WtgtMjkHMlMmE5Bqmfw6pEomH4VUyuQ2kfAwH+3ByUSwMtpTrLRUmlvQ7C1I
sTTXQyZJ83aRo+PSDEEuydQsyEWZmg35TKbqIZ8qeY3+jaQYwtC/ytQOhKdnSESFpe+TGrYH
mpPJRnjvL4xOXyFxOgfVktgqC/qSNJEc3S3NCGSXNMOQXxdkpzQF5DmZWgDZIVPbIL+UqVOQ
Dhl5WMVrJxEd5xlSo/UxmaxG8yMyqSK0yWQU0iqTCyEPyfi7kAdk/JTq+j3aQ7G7aYqYOtPv
ypSJ5uaJiXyHRHTzOrJQR75LJtWS3KmCJAy6YmIiy+kydcCjS2mPjmJLMwa3uDRrIHcUVu4r
MjUPskRGsMZ0sYzswMotmhhgrno+r9Ew0lCBQtLcAychU3Mhs2VqBaRa9URSlROjVpC4Tqpc
msrLL82AeJ16SUpHLCE1tGOfGEPcS/Ec/YYUF+1cMZXifASyT5xN3ic+SuZwvBVn8Brv2SeG
4Xo8DtP2imPmKXE0FRRvm/Cwq8Vb5gLxu5qNIhfpFU5ytuhBYt2p+8TelI7wcg26SbE7kmMU
vbtS94hnzHlie01O5fBzOD+lxkCgH5sbxT+Jr97Ypq4rfu999ntO4tiO49hO0uB/2E58kzh/
nMTBif3wn9DEcgiBMZvGkJgmDYURgpNUaANBJ0QpCpNWDYlNqkAdG9uEsAlsDmUlArZ9WNki
Td2HqWNBYuyTNVUDqpaE7NznFFqJT/uy+3zPue+c37nn3ut7zzv3bccx0zRshanYSVPaVWM6
ULvT9GYtc2Qw7XENmsZhIm+AzejYG6YR13um4TZpxDtdd01b26Q5RMekGfX6JcWrY4OmHhgB
KAJMASPwwb5sAdPGtg/ZGqEGHJq7a/pWxw0CX2N8FOpBsVH4rXBESAnbhCB8d5yCXbAI6wSd
QqvQKFQKpaJYoVDwCpmCKOA2S3S51SWRIohgOl7DGC9jVCa1NYRRICw3IVhBUB/KlHNREt0a
zHTQaE5YHcx4aTQjDLwWz2J8OoGjmYXdKJoyZ55steVw8ZYdGbktiDPaKIpuCxoBnCHv5DDa
Fs/hVWZxvDqjDcXnEcb1x2erGe85PptIIP1MwBjQ+ss6e8IvIcNrNBKmL4qR0m+81WTORLfG
M7+sSWRaWGO1JhHN1G01D8XnyT7yZiQ8T/YylojP43GyLzLI5Hg8nACYT4IhP9kLMBRjDGBk
CPkZDORDX4PhLIjDWb+/ANqMswwEh2azBNpRAIW+DuJO4ZAECnGnJND7BYcuGAc4FBkDmHwf
ckkOXfJ9EszIYFmHA3oaczBItsUBgKyjRVJveaGuLagvFdSXmDqH8Qt9m6Mw2lrkkDw4SC1g
6P+xjAb/ByM81z2zPx4ZtUWGbZFRqMOZUzPjxszRlNmc3T/DFOYM5xhO7R5nfGQ0M2MbDWf2
28LmbHf8Jeo4U3fbwlkUj2yLZ+PiaPhKt9gdsY2EE3P9x7yT3/B18rkv77GXdHaMdeZlvvon
X6KeZOp+5muS+ZpkvvrFfslXdDCIowPxrAIFE6GhAp8jJcVwWoarLYmgXnPALx0dn8V4pPq6
DOGLqIQmMkpbMFMKlakaNjZsZCo40kylArF6TWU84rNUX8cX11QaEJfZgmjKGNkThl8aytTU
NBRY43S6sNbGgmKKRiQ9AKagNSUVQEKb1bQkXdNPoekXhdICFqVpKJ6NxSLGPeFqSObnWP5N
E2lEacEhpQh8wqylhF8vJfwlvL71k9g/Y49j3IKU6S9CXZIy/QXI8hehLkGmv45b8C/6l/zc
QmwxtgTYe4v3lu5xCw2LDUsNXMfaCJirBIYRvnimaXqaiSmWZivNG16naJqyKX+1BvBGmZSt
CpSCXLKj0At9bktfNNIF5bRkUpCmn+9fiK0QWYHI4YG5CCh4leDbvJDjFGI5kstuc6hYkN3G
qFLBy28T7gbeiIqwHW9HRqp50rXS1a951BVb6UIBaGuWgTQ3WcosZXYgEMfRsplbWBbl6Cky
yxaYh8HV+/wW+V7UhLpRH94gfvcs/6PqM+ELoZ+Gr4bvtAi1youvkGvhW+HfRbhD5W+HiZcf
Vc+ouQAOkA0yzu12Nzl7uVqlu8HdCJdAN3YTjtY1880879fV6HS6muY6ysuUvhp/r05GzTwo
Zd4iXa+/RmbrIbdw0y2Yb5n3og335MjyFUNJcY6siEVlJU270AR8bXKcRdQpCbuPEVyvvKUu
NZWS0ptVjuvkC+SBrVCk1XkCns0e4snhm2KJ2xfwbfZxJh/25ciXYqnGfM5MzFfUQVOQBHPk
6bWq7dGJk2y18slHyXwSCM1rVpIrj5JdGqgokGePttPdldfky7SGTlbxV40TqkaqOqy5c0J1
505zE04WCkomsaVCRQS9Qd/a0mHgBd5mdTh5Rts87R0ORltb9BU6HiDtbR6H094OzOmwWfkK
nZ4DA2BgC1jZaXyuZ+Do1JjYQPu66gaTm17rnx09/OlbHy399eOqqvuXZy/84jeTf3tvg/fZ
wT2v+pyd7pD56oDF/Z0fxxy7vJ9x1FkceHh6aH3liP58uDU0tC36p1Nn7m3Z+L0N5z6Z3Tl5
PvSHhxdmXD5+tzMROBBr7Qs0H3j2F6vDG9l5fcxi+Zx93lvwBDlE/LA/qkQlXCxRlRxXyi7N
Gmm/5oHmIXLH8jB5S5uFHFqZJ5vwxJ+Z1Y7Vf+GfYw8qQdarqJcv4XK4XCwxFzUVkaJKJVv0
fs1yMpaHJQZraTUK64NRz0gqEhkZwR6JRSIpKdVYvU8CsDc51C7WQC4QIJyOwDWHw5iUcJfZ
oC6TetmNCPybj/L9mies665A1wl5I4W/CHxgGyaBZ6Gj+KZ875cz8nfhdKG+1QfcNfk40iOK
+8TKomrexNuL6gyCsbrCXGE31hUJCvyWogbylStauRPYHF+qNeS4YtGOxPUODxJpI5DWdiC+
bo+IBtA5tlINWrXVZCVWhlT9oBSXiuUVntLK+sefsYk/oQdj+WQoLhqs4nqnx8o6sbJOrKyT
CSueZAEgAUCpEcuzPMgA4RDABhYWAS9xMGH8GlgNG9aspE3b3BQ6JKawy2wxWQivVmlUhF9v
s9sIX6IsVhYpFUoZX6HX6QlfaawyVhs5nmAOyzDHu2gdJfy6MmsKOQQgr5QbUrhWDsSiqklh
m9KZQkY9tCiGlvShZcS1Vo6hSTyJdYKKsE0PT5uno51td4NermHvNqvA82UaA9vgHe0d3LVO
a/qH21Pvd9dbqL91cWrmblPo2ceyYkell1baq3Rqb2NLpYsnP/tjZt+7W15PhifPfvD3+bMf
nH/nw0/x675TzWajLbvy72dLqU1NZu802ysnIJjthn/VgL5/A6nwJdyGFPjCr627hAmBYLjG
MImAv0A2pMcX4HL5OaoAiZ4QUaVWILlCUILQBDEG7piiRqUaUE+oL6s5jRqrK42qjyDtVZDf
IyMx4H9IsfYBRNpksisGoYNF24C283F+GT+mOElh45Wxw9xaYWmDE93eVuZxsDVw2slP9D0x
00r7+m/3VWmbza29Wvwf+fjTXx2O1NvttT1Hyc2d/+W6WoObuM7o/e7uSqvVrrRaSZa1ki1r
rYdtgWxs81DjojU2HUxhwpQSIEHUmKaB0IY6DAUChOZBzKMNpIEGTGjoDK9SymQAG8VMBwqZ
FpICZcK0M437SOOEPsaTPwrNdPDS764MTToa3Stp7t7RPfec75yvMV6TGLE1iCd6HU8UJX83
E9voKXqS49LyXo5KbskNRIhohyrOVtCKKMX/JLnFaBG6B7XG0JshGiqCcRo0kdHFrbSKRS5x
1iOAjIIsmREiqAIVhrX3vFG4EIWoXu0FuAAA4aohWAS7ia3yQq96p9A7tzRWGCH5/CjzX9Mv
mhVKXjRDHhzCXhyUnM0/BKFjyThfcYXNU1xkzxHVnk9HfXl77Ygvh5WUVdRcwZfTcvhVvcpK
KSnE45OJhsWRYWUTCEuE0wFxxHBqCzfv7t9g9cHnl/YvSE4Z3v3Eie7Zj1snIfnt9gYjUQED
kN29cme/crHYfaxr6/a3rAEtM5PhGL/3IbcDccyQG2bM6Q15V2Q2ZLYGt1Yc8O+t+Jl2tGLI
754YzUdpQIQi7DVdhKisy4m7sQ3txq4oTn+Lefg60YmIx1F8rTauWhBnen3Q9Ai6QgJF6j9b
AyBIQ7CXuEEfrC7DjMXgnO89Uq/W03pWGHzeEIT0id5qqGbloTo84XOYZxDzXqwSpdGCWhrz
5RrD+mgbqczn9dFMRh0bUUfQlgroTWW4YPJ0+nm0bHfBkcSNdNlwbMUxu4HGpxeZGx79QU9y
1gc7fnhuwWNrN1rXLOvkw7kZmXiVennB7Ccv0uO18dzatvnr9ijHjp9c89Wdk3PHnr1l/SFX
l8+2e8Q31j66/TYC04K8/AXiKRGF7Dcr8wq0AHCEp06XJIiKTHhRUdzuIiwxVQIBvAI3Aafo
VoAn5+EuBhuJqqYsgiDKCsE2lIrnORdu7IRus7KRz/PUy8d4yutewiAiYU+5go6g6gqFuaU2
W3F5DDp32pA8jEhari+b4bHme73eMjZ+aPG1BGsx+sSnxn0t9MVnNm2yRq3gMtgB97iVd1+7
Yf0Omm7QEDJkJjrCGWEOMWCemfU4wCWFpTpSx/EBKRgJRrlpji7HOYFzC6BHpChfpeJYxYPO
c1z5lAae0sDqD8RQbQNwndUID3wRPhnUargLHMWFxhkMYHoR+k3J64/5qX9YVmiRXjkDN0Vy
njqIQargU1M3xXniIZET9YR6c5cBBsPACNeWMSihi4wgSUbRhksozNHCKCY9Jj4zwJkoMc5E
vXFMoRzTqq04q9cWJ4+sxRX8uCj5cZHaMy5l8+mAbD+SWTxaYA+Z1Qbb1GCbGmxTg21qYCDD
QXOX12YWjxsueZCUJjWR3gI8XeiFOBd38iFGTb72PivRF0JlXibihhOm0Y2Pj/2zBRYP7X/Z
svqPLp7enknPW/blCbH019ZYh6xSZIowx7L6lDdeuLz5k+emT5iWmVHT2aDK67/+5jCmBDIH
7++SXfvTqHFXgINvVXyvgkrFe5+ZQUyHDVwi+JsglxcFo7IyJrhSwV/SdzBP7MWg7YL+gVRK
JUIMjf6sqhjDchE+OEP0+soivTrg1WM61Zlw3QF2EYFw3f2LQJ3ameMOyzNY/hsxLo7YXGSM
tM04G0lK/kQqGqmKUIeW9KSSktED1T69h9R48VOtO9UDEX+sh8QVHMh9Y800ZJ57jhTQSwrA
UuWUqePyZnkJJa8lAOOiVgZRZf7KXRp4f0vthKr2GfvefeqdNZtvrXsfXrWuipOz8YnZWR2Z
rjphRTT7yo391a7Any689NdntoN4YAS2/2PsqR3mDstqTa46DIGVneNquIFqkMiPTTdxhQXq
EFHaUhF+YnrLgpaAcC4niE7mJ7JWQy9QSqhKKUWaD7pcIk9kR5G+a0ouXd7tBOcd96dvwSvM
Nz8uMMyYpbShaZSJSxnHKOMYZRyjD4g7opXp1GfTC1DsTNwCIGsczlp/HGAV9Fq3j8z/UirV
w9VZuSj/jUz1fDjyn32st5mFJykKy5EXCUy0krmQk3m/Tw74Z8orUhtSziRMDT3SvI5/gb4Y
7lcOJE4oJxJFcTAgZ0ietMrcfHlecrm8Rn6BCElZUZorEwkieyuTkwwSjCQrsdI5tGZIJFhi
CCrNAVwCCc5oViZ5lQQ0845YOUNm2eRQIuN2HClyxKwKNk0aNrl53CGO4/TWcnIc9jY1mC6l
tYGt8OxygYtxzhVuYZxjCXI0w6wB5V8ay9iZryw421Dt1qTPs/mBDO0ftZzTo7b1edS330bD
KKAwcYSK/2XvL/Qm/9+T3G9KJrfSoV2r/33r6vCWPT997PbVSzd7LycT0xpmdyxdOTGmBGqa
Fjd2fZNaKwfWHv7w17u+c7hz4+tPbLtx7vvdr4rNm2Y/P3PyslldB60r0VDtS11Lt0xbVbiE
us3j/Zyzk3gduWhGJE7nGjhun+u4q+i6IvOdohCqFcRQLA3nba2K0H8mnSYMVVP2CkQJ3SRh
NUzDTJ+aX2+oHXbfBAYZhOsfyLTcGYzHmLJMv6jSZj3l0uJJJeVLRvSoXqVzjmSqxlPbQ6rV
cA+kXPjJkGM9oGs4JKT055TagG8mVSiE0Iyn3m/4GJ5aMEB5sAEtJ+CgygSbP3q7LzJ9YVP/
tdXXV6+79ew160molxoqG8N1zdH0jExXOhpN7fnjyzXhP//qpb9s3GZZR35vrR+l2767YPDg
wvqKzENHrX+hUBG/JdZXnJ3YH3WQR+A18yEBVK8aUKtUY2Hk5xPPTxRjqurXQppuTN8ZccyO
rIg8E+FOih1NTaQpSzrmg5uvDKebOjrnkiHOR4DTzIDp6a6Fzm7TGW1TgxDc4uzOILpVpnfu
j6ZMieGZpRmX5q/PwhAcxzqw3Izw+9QsZLMLF9Wdkk6l28P6opb2hz+bvTV3WivC1IFYeOHq
5ZVFmLCVXcZc5O3HI+w6SmPsEjDLlEbV0kckX8Bq8JE6VkI7wxdaG+PuOIcZvXN9que/TFcJ
bBTnFZ5/Zndmd7zHzB6zx+zYc+zM2p69vIu92Kzt5TC2IQu4BIGpF5LQcDawJsTElCSGECNo
FXMpHIFQtQHcVApQFzBEBIqQUEslkJqUnmlQmrRIWG0aSkiph/7/rmkykt+b99terf7vfd/7
XraEVmPbE5lWc6yjs71zZidBTmnKNjU3tTSZyBrNqjKqpKlqW+usl7EnMrMkjIyaJMxSW3ER
eAT4fQZGMI6H32bgHAgGfH6njM7gamkPw7/obJrxMpg9OS9h5hglYXQ1dRFzV3pL/+ULljMr
OmA+A2ya4yLA9IkHdgKTZbL61w/ciVBXIKplCEQiyCFXPQONmQn3wiRimTSOEsu4wlLKVOqV
UutkIOuochfBfioNywhSu/KHZJDhi2imN++dq0rIbX8cMo4Yn9w31t4F58ECEADvF5pfNOqN
m8Yrhu0BuAyYP4PZx0eMfx9attI/P97aUp1uf3pqcW9PomFyp/0FTU01Llc5dzi9YVbQTRyh
x3+wcpKYOAoiJ4AHLPub0fFf47jRDuJfGX8wroHPwUuABJf+ddq4/LMbxjs/fibfsHBnfbvk
7X2ueOviG3XBmQsX1Da+9o/d0WQocuGTp9rCPOpSBsPMpyDLJSwMkrm9MlPhal3O9DEble3M
oPKO/RxDvWEfseMgrOCYrCgS7agQaJ/kF3wVUAFxi2DlWK/AQeZhMve84mREBZMYCZcUXIqx
jIdlGQVXJLza4fQ4HE68zwEc9CYWSCzjNHGKxDogD32KUw5Xw54F4K9MjnES0BrTtNXi5AB3
AWzFFBDPKSIdSGpFbUD7oXZT+1gjVUYTtZw2D57s0k5p1NBzUFN6mcK9QDA/PlaAzjyLgG/N
BtEWOA7d6P8dUAFuNyVFtsDJBbMfvRSu6mj5aWz0Y8wYYC6XY+GbBcVks1Q2O6HTOpAQ8tAv
wVUSLkHQanPlAvZCWVoicH48aUiNoTi/2mjuXNIGPnWDOzNjcst4kZ8rciQeWv2rm2Drtml6
I89YVLVi2ZumpofDb9VUmVWVYypdbuu0L8BvjBicmDrEygFnPw8nZh1YkNt9wAdcz/J9eF/y
hP+n0QuVF6K/pv4U+ypBV4PJoAN08gvwbv5ZfBDflhwG16IfRD+r/Lt8v/KB/CDJdlg0NRQO
RxyiYJVlpyh4ZCWpVhJhLC4m62oxtTIcggbME4qrqtUTjnshCWrjFovVgomMiIsfBY64TMF0
uM4ZqYrgkZjTEUilR4FpRGpe5Nf1OfeySNWRmkxfdBaLM3E8nr9T4E/H82PdcExiEJwx9IOE
ZiyAYklMJnZPiBH8EArKSrYsLCk9Jimc30z5VFnzqaQWVRVOTAAZBZ2KJ4DkD6OgwDMlZq5N
wDGAWA8es37LlvIoQKbGtSl5J4ZrUT3ZKHdHB6O/pUj0q24YOF9prYXLLtxr69lJmqbUS6Vd
lzSjE3hAsSxVEo1SRQz9Yk7xe/uNj8fnLpnO8zMK+M47V4qvj99+fXtH+7Y9INMwb3vHokP4
jVju27sPfqdfVSavJYprG2V1/rHCMwdduQ2LFz+fBeOHjXyqIdO+ff7S/VnIBKzr0W3zQjg/
wkA4j3GPBkas9KTQaDmTE9kOc64bvtiCVr7BnQ8Oct8PDvE7QpY17BpXP9vv2sGeIIftx3zX
fNd5muQwbTo3NTTAveYb5LeFzpneq6QT2sqqjWSfvY8fdF9wUhkH6woL2GJcAGAUeKD+LpZ+
wroc5tUC4VjttYKlCRawwaIGNJe69jxIYWiST1+UszrpKhqn84HAPQT0SPltrHsOU7hfQJ4S
jg5Irrv3IJHgYMGYX9YlZ8/vP52yQHjDXIi02yCwFitlxUles3O0ipEhGCr8DhWzBs0qKINZ
i6AEhV4M7i8lfWcVDZkiREUXQiXjRYM+XHLi6VTJhmfMCyPRfx545YO61p6rhwc+7Fv/5bHf
GyfPXQfdV4aO9gTEBGVeY9SOXt3Tt//8WePDg8UdL2xc8y6YOXoF9FxuCSfSSCuhYJp7S/zT
QUWuJzgAL15BgUFBR2GFe6V/hXqoZrTavIJdBYv97AHubTe5zEGJAibLFlFwyEoo7nTgcj3P
YxZXLOQUqgRcaLEkKTAPuvGXos1nSuao0IsolM2jy2UwjdFwLY95GE/SQ3ga4JXCSz6r5ZMe
UKrGuicoNabr5Ytdgi52lqIzQZebdeNkdaQmUhshyK8rnOS8Pq/fG/CayLCqM5oKalFQgjBE
3CEUdHimq15Z/QadatFTZhMq0/XoiifIgtjiQ/YKbkakQrCe0jaZaWAZ5LT42JRWp5Wb3hjD
l36x78x7PXsu7Wx+dTHj5tMnFr34ranLO1RV9K4iNq+cFFGndRmjN4Y+P7I0aDM9evjRkxrt
XH8IzADmw5uiVZAhNRhm+g/Eow7MyY1xpoAVF9PJdDG9Kz3su+W55fvM96XP2k9v8G6O7yD2
eMw76APEAXqvd5gYpknR0+bNpeel+wkzTdA0ns55bK37TIetb5vetR73mG0Ao7pstusWgRJF
wS/Leldd3e2ooJNdAFw3C6QkCjWyAkjMRtkxL+PFvZzu8XKEj/JxI664v666BsRtNn8N7reQ
lJOaS+GtMAxRJ6kb1F8o0kmto3AqlT6pX9LxhN6qz9WX6uv0V/Qh/ahu0V9luCK3iyO4YC4N
0pjTXmXH7S2SGEhNtEepOSbIVeiFmlnoXZ/IQhtddtHM2Fj28apRKFs1HRLvLsaMT6THJcGY
J0aa3luAD9YLWARomlXiuMKiHaNUEuW5VgK65Joh1Ih78A2P81s2MJpmyy9/2j2pqev9T1Nq
88PvxqaEg44KM81r02KmdZqw6qnJh0zG+O9+9NZ404Z9aWNrMSWe+rnRpXodsn85sbnHq8Cm
M9btHah0QXzjEN/jEN8okHJ5ymT9H9/VGuPGVYXvvX6NZ3Y8Y69fu/Z47BnP+LVrb/fh9Xut
3Tgoj2Y3SkpQWJO2Is2jSdkElK2IUqIqzaZRSyP4EVqButCqD+VHQkPJRgqwVZI20FIKKT9A
oG7/LBJSKn4soaKxl3PH3mQJCZIf53rGV3PPOd/jsD0mhVvPWawWKwtgMOlmndU5vWPctJYd
5x5jD7HHWce3E6fSb5vfZt81v8sumhfZm5abLOsw5E0KSx5F0Tf39MyReHVvTNIFBjO0yHaJ
QQC9zYS8b5VsobAUVVTGZtNJxzhPxrH+Kw1r3efASiPMCw7ZQRwVSUAycEIlFJK6et2enniU
xHEcBtGo2yHl6Q8aimtR4mF605cw2ElUxjbgSpgMAaNQn9JSiape6YaxwEZFRZgfoaqlVl1h
vSguGje1a/XP+l3fFOuUC1slM2pGMdgqmmdVwfT/KtdAbPvB8Q5V7Xzz8ZgPwNgotkpFgWl+
MuH45v7ST6BQ17NH9ze2vXO4+QiF40qVaNw8/OyxgAA12rK8YI1a9qEBvK/qZUVL1KQ5Ek/K
J+Rj0WPa84kTSVZta1XHXdqVpNo1BsFu225umpuOXjT90jxnvRC9oF9IsmvUtYlqciZxPGl5
UT+dfN36iu0N7qr2fsK23uGvBsSRKT8OXZP8k4pvbnm+6oZfvuPDzmuST1EHVsmXgrb3vZkK
yViUeZ/fr1iGUiZ+SLGDt3cSZwWHuofo/+0d4uCQK941OHQJb4FaPYEXkOFiqHsR7LKd2A33
YjcELXWz9CC1MDeMkbVEhyF4I3FF21KUF+ENoKJEXKNE3B9OWgUO0q/FokDCNq1DtWvIERFH
cVgWRGsSVmyM15AQ5kcRkzD0Dui2PbskW4PsAYNwablVPQqiR1Y0b6XCoH0ghE4rnVeg1HSq
ATpuaeAz2lhz6eUf/Gbr5G+ff2BX1lt7QCXf31AU7U83/3b6neXLw2sxSN7OzT1XXcE+Nwii
cuWDM80Pf3y5+eeTHjfunsjA+GaRo53rm4uF4p4zj588g/vxayKzIZGnjgX8qdUNeB3DI1XX
mAJzADhFiVEUf9XFjfhpnh3DwRHkF/2zfhNl1TnypwtKf1hKKkqBXu6E+wpVuEcoyIWzBdNo
WCrAPT9XbHQH2+0dbKJt1mbCYclGd1CdYVr2xMoOCWOHhJw4mzCpwNJwT/Vr6kBYyiuqEomP
IQrdETDUtmQi4ff7SCGfZxgbo6JRcZSMVvqFAQyvHcC7R1Dt4Rqp1iZqs7VzNXMtLGAZE1xx
IhHDa0LE4pE15UNtvT7YFuz6gZsrC7QyhNBPVx4YulEyeiPV/lwVGkQsUi7G9wOwR22Nm87I
//xy9z9I393IJldpLHD4E++afA+50lNSYUXjRqkVk+eak3dDvRU3j+Kjd1a3jt2J8auopcXk
M6i9jE5WeyO0AGxYIorSHZZcihIIS+DKubDkVFSXkxDMdAsBOUACFY6lVfOvVUcWWNzHVtkp
dp4174APwnaFI/RiICANLkTwVGQ+Qvoi1ciOyNHIOVhYjbxDolNG7lMr+R6heKG8CLbl/gmk
6SKf3Ss9kDbtHhkwzgwn9S5/alqCkybRtirbOqQOx5sjH1f9qscjEEwiQ4JdR5qoEa3Cvsxh
bg4/er5Hgn7Hj513jadeuGjQi3jzRj4jAs8bzw3WDcjEePDVj0m9rD40mB3oN+YSY94cuD2a
YJX8vqcU7RK4Te89d+b6lyvlLTbzcLdeTuV8cA7LysM3dl/+6fTP9q/dtikf9LCbnd2dwZ76
x+SP9EgtpbVOwJmK+JGLqLw8f16JD5Zp7n8oOgcZzPJchiuuw+v4J/hDaAa9hF/iZ8tz+Bcd
c/yF4rnyLeSaBXVL+9JFXOG3ZLYW9+JdaQY5ikVBEIrpdKZXAHnlGUNbvYrSG5b0SWW4mJOG
rRi8FNCEZ1KVw5KmqEIWZzNDUva9DM6krxZxOi4U3bALRgiJoLi9Dt7tcPCoCMPP/HlonCJ9
0BwNMuCreYyYsng79A5ndY14PTYrY+2ulnG5VxBlkYgVeTaEQ12l8iWy1dDmrhbfH1ixVYvQ
SaUSfbdMlC+fSjEzD6ZTdccR8Yp5Ju1vRXU/EoH15wHAxndr1V7URabElIwx1jBYlL4xHTEp
UOn4GMM2oxPv0ajtBsD0Lj3WYnbTQ/ivO9cNFRuVsdhk89f9/jUbGltXdfArNWjgDvyvPSnv
NuL80ubvmWqNM0/1hjXNGvImv4Vnks3v7h28q7vdjkjXruZ2fPqhAd3LmYDiE4egJ3SYdnjo
CQ29UM0+iqfxYXUqZj6lnoq+FjXdAfdGpQVrUCNTQI0i2vZT2lFtVrNoc/hiVQxH4gQwjxnC
aH9APwKgnK1678C/S++LVWOzMVP5KxTNbV+7tNQAnwSs2Sgt1Uugr06a/5SRxDo2/T9Y+wy7
CnLHD3yxcVVurhcNdPvVrocP7Du1J4P/0ozeA+Wzu/MO+8ZXZ1ucZtsNGcji8erBkMi5RrgQ
tocOh0hfrpadyL2OriGLFsziaTQdnJaOo5ngjPSi9Ib0d+nfUsdUbiFHZJfcKbvFqKhZBJfQ
KbhRFGn2rHU1OaYLkq60sygXKAQyYWlIAd90ojqGpGAYOj8eDLiDwQDKZhHqlUJuSQohnJWC
Jhl3o+wQcI6uSUGXk0FoOBcQu3F3hf0d9wlHuO6c4W+CoUHjgXLUddk93sFcSI5n0vSak15L
L6TJfPqjNEl3Defm8NbzEWDXOdzzDAVF3SBXQEXqYIraUihQF7WlfgMjLZTQOQNAwsykUxaA
BUMBQoOUP5Vq83G9fhCsKswXgIH76xZWQf18bUx4s6urbPoIT5F4i+9WZIvGjc/9jX9Y+G31
Zp+jd1OcI3AxRZL4Q9NTUNWIf+etp1ep2o0vUuYPbtW+7usf0TQsD2a4r5q27xqIaZQJpeVP
Laeh5hF84C2XC/Tn87f4PP2qTnfkxWBQEIOSJPAFamsC1HYopCDZFGpBvBvB8YgREoE5IyIG
fViQpArCbthWCijIKTgwlnwRcBo2RHxeRrBjEncIPN7BY/7IBHC56IwHUQBPBDAKfOM/bFd9
bBPnGX/f87d9zp3P32c7Pt/lzrFN4gBxqCElR/kSXwqw8ZEUj491kAHLCBsJC0PN1ECgTFuA
DSei7TYE0WDTRGkAh3UVQhHtukpldFPYR1FVIrE/cMUklrUiuex5zw5qpdm+533e1+9f9zy/
3/P7ATwOi2Vp0ZEjaoIoi4lSRkzEjKbQLZ5u8PoqalN9xsOjCA4DM6yUSvWxjYdH+9hRTKqw
ePMIQtOX1ZQ7gxiWmYf2C/tiPUJP7CTqZ/qF/tgwGo45jYIxljTGHaI7yZvZwvSLV9wZWIZA
X2WMoHw8mGX78S/Dl9nLYSsirAbU1rJ4y+arrNUTaoKrn6g2LtCErBXuJlSYflzeMZ4mpjD9
8C24A+vfr1T4m7DeHiiVasGYGEsLoLmC8rpIG5Q6gwy7OKjZDNao16W6Dnxz44KYOLlnz1JB
i+7bHEm9sNC0evI6tbw7NZ+SZYfUvO1p3vjtyXMH1kOBW/ca/lDVIFIyzI61UN3Hpj3IiSrx
b9S5bWybe8A+xo0F7/H3wmORh5zNErBU+qkA7ef94Tgbd8c91by9sgdsip8Eb9m8MOXVWV6t
BFYvEXdDbmESuDw+Qw2aB61n6LxziBqi3zW9a7sdGcNjTidltFjNNrPdj/2Un/Y7fRHbzuDO
8EFTF90Z7IzkmWuBa5Gx0GOrY2NFRQYZfBmLjXMEo+2b9XYAU6IGUYiFFlmjGrCBTwtNAiUw
XJSjOPApxD12EL+iMl+5wK0plv4qtujmZXYdsSfriD1pxJWsHFE8ik02KUE+wFNmxsnJ8J5C
MvZaIfObIXPRFTJ2himI2G33yYg3QkilGuGrFzKpV/NHGFCeg3YYtpq5rKkw/UR1cFkqwGVp
eKjC9L+uuLJgCB/BYiI7Z9YGuzedWZQqf1rwTAathavAr1momBBXXCwyAXO4WCKD5jVwGZZS
DH68BP88/552Wjv13hv4LH7uxvbm7g2Du5Zu3vHSWdNWWmvX7mraqDb5+Sh24lp8evU7r2n/
1C4MfX+OioOfwpmjHQQsqkfIeAHQzwNNfziCBEA/nRUI+rc4ss0Kzgcm/BPCF6IxaQ0jTIP/
EEVwIWZRchIql0K1HKoNh81ujgLBwcZw7P42X4/vFz6D79W0gpVQyT7UOBHN0tRaehtN0Ydl
5W1M6RrEUtIguWc+YiKn+8xGXRoW2eKMSQAY/0CtjEoePuAP+imz5ImlcZSHIHqr0ljwV6YR
Iu4xldRtY45sZoTGM/GYiQmgKYGEDS4iKTP1ikQlQku3TDV/Y3EotCRHNeMq7Xz/9ocxV3dv
7yvUTu1Ye1aUZem5dsM+kt15rfdtMUANTF2jTg7kf0ze4FrtJ6Z/A8J8SMF/VJcaHW3BtvAu
2cg5GLt7BbPC3ec8wRxnj3Mn3H1e+xK82N4m7pIHnXk2zw16hwKXhPPK+8z7bqePYEgggS5j
rLK8suU1QDDXBImiw40EhGw2u512mGgza+fsvkXsSu4oc8xNd9Fd7EFfl9gpn7DnA7fxbbtt
XcU7dgzUdE8NMK56RzWEIfQAPXIYkEMK+TMuA/Gbb8mz6i0F3DBsmG3OmAr4W6rLEb2LrOZN
XEUwXr03RiAJNSOQdCKJlShpjYe/WY2ryWh1OLn66pLU0WGZyk0QWF7/0p2r5EqIAJP8WWwZ
B2Q2ThSfFFNNRULsWSDXXAmoqwlQG2glBkANyrIi+CQZV9IhGQVYCAoHW9EbleHlh52w0A6e
8cu4yg0BGoBtJL9nsAKMdszkKNcBYFVZJ+vKeuFhAKVueFAJiTmTj4DNC1akKq4AFFFMIBF/
CYguNq4YPqq9daq6Jt91Q/vHygntIzyA5+MsPqPd0tqHd6w/tDE/sOHQmm30kaPW55Vrl+tx
NzbjOnxa26v9Wftc6zaZfv+6dl87/+sD37uAV+FlpwrQUUSH/g0wKaEafFBt2sDv5we8BqsU
kFbxy8PLxe3hb4oWDpmQmTWxZmNdeleoK9QlHpM+CP1JupO2Dvr+wn8ReBp8ypvSVrpA/XVY
R62eEOBComYJeEFe6ZRaI4keSRJflk5AMVEyHAv1iOPiE9HAimvFO6LhjohFfzIsSopcGyrg
T1W/BPapqqbWDbAX7sZioghS3QrmFZtUG42SbJJK3vcXDJTqo6tkkBllFqDptWTy1z4/orsP
4gRZwD2Z6uxUMceSMV/aFXUlDBzQWJxqhKYgjdGxP5d1kamfI2Nf9yIBXWdBkwjxWR7eKweV
anmWJ5nGcR5CyleTxomAkkZ8CBqh3AklfiBcPYKqgegcdDZlpbPhgNu7EJfGcg5u/B/ymOPT
HamF+Bm/N4YNLt2XEhYRgD2mVpZZpHNivH/v0h/iZWoo0aBt0Fa1ZE+82nzyV9RurferfLLk
+qEzOxZGtUyLL2qQqd3U4NTv5h7Zc/ZnRJntnv7EGANmyWKsZgN1mxJdMYO5AtsYS8pcF2D8
qRomxSZcaVFIVc1qSDakdiWOJ44nL9YXkjfq3dkIaqUiGBfwCtWLWpmGaAPVcHE26OhWIRIV
ojhagO5aVtmKeJan+IveRIqxKoyDYcKOMGPsZDoTZ5kLjquOUcacSjAOo2TKzDZIGa+tGW/F
38Uv459iE96EFFahlAJm1QqOXwD4r1/AWKNgfeBoODq7Nji/gLNvlqf4eJFQAoA+N57T5zGY
nFyHDvosYh/lnhRzmAUmKOV6SgxQBzggtwQlEM1eEMqlr9djlEQlTg4tkmuur0zoSryWytQ3
zJ3j10/mGW45EpEHvTu7vBE1femzr63X/vuBun9jXZSfz8nyrKcn9x2Z29Y7cm7TZ1dfWJju
C/GVTtMerfHSh99ZXiOla2NfP9DWdvTSf/gqT3WCQvcedK+ra1236MWeN7aeG2fpRcLzpFIr
AbE0IFZAvx1BInBogK8XCR0uYLl6QVQBRjdFYx0kFP7YYpmEugSECCuKNiHCgAf6mOcnKyNR
C1+NBOp/hJd9bBtnHcef5+J788v57Ni+OyfnO/t857fY55c0jdO0vqzvVdqElVG2ymphjL6u
TdISxqqu1UYVUY21RVoB8U+LgC4SWqNGypxsvG0V9B80JKg0IZCKENAhOiY13UDFDr87pyVl
Eli655570Ul+fp/n+/t+eT+DxrBduKyVAM+ssAS7TuJFrIqj4nmxQ1R5BavKqHJKOa+4lAWc
RSLx+qyjy/xHi/XxQR4OO1LWB51O2hyElfwb4puwA9oTiCbjtoUNwKLCCmqfiCROVNECpDep
7thg7HlGWD+Qbw7knTz5+a+t2yUY5HDrwqmj8eD9v/4naLgiA5+6iI/aK1JcukV+D1akgDus
y6JfShCiO5XIaie0r3OvaFe1X2pLGgvvEaiDxzzBd4xB0DkVOSXMczfS76VvpzlSC3N8Qo0b
Win+VIJ+O35PI37AzXFEhaFVGScSiiqLiURWLcgokQzYyUQTBQHDN70HkywkC/WUgvcoSwqh
nCwWreJocax4qUgWGT+t0AS9LpMZzeLsSXM5cdj244EHGW8njjttMco9EJlEPM363Yahc7pH
Z0yUSvs0HhxInE15TeRPwGAvsdN1loVmfAKazkSnHf6o5ei3LCgpW1Hs204kpKDTgON3lIYu
Em9pI2uk1S/sPfKd7Yacfxzf7K4OB3y1xV/P7H3pcNT6DDmsxweON/fPTe54+vX3iMzuHdD3
9EJB3dls/v0310zrxjTxrS9VE9iuBQ8Z4JqT8NzzSAMqB6LJ3l9puOL6ZpjgNdwv4KpwQJgW
GoIrIghhUZIERGIZSSDWYU72eRmP7I1LEPKsxtLLVp9AUyqDaPCnNJ0XYEsKYZKi0oIEMynM
0JTLS0pg08IMSdJxnxeBN2Q12A9v5Lf2aoIQRQu4gAT8ohVUvRbc2+vFXimhHY6fe1Zs4J4z
jifMRaXtzaa4Y+MzG/6cc0AeHAwKVQxiAbIxtb2QszsAOVUQ7Un9ei4qIicCrhzr7dMUzw3a
B6gJVGQCfAAOU7aSa9iOWXYdoAyhCODjCLpdHPLatoHszlY+3jI/XR0hzkY+qwp8AcextxhR
ldxmqIF3fXn+/qKr750NrK5H/HKwdKhZJ558dls0VvAGdFj74NIf6A9g7Uv4rjV7jv1Hhtgq
HpCmxYZ4Q3pfej9DV0VM9whIR31opLynPFo5BJmxzFesymhlrHK6cr5yqTJTYd/G75b/iO6i
pTJ5jD0mHU+fYV+SLqEr4Rn0DmJFKQMwmpUq2qpuKk2gCcwivouvnUaYlSQaLKIkidEo40Fd
sOP+5ILagpsJEAEhKAfUdFxWEexCr1/mlSjoUClblEuWK+NCnsbSV2dFjxsSwQnrQAZ2XhQx
PKg7k8+kQ5lM2os8vIfwePKiEBJFgXWzjDstSjCXKJpOZ7LwUlbwetwuPh2VWGBDpJ6AbZfJ
ZuBaFLyQCT0lVQFvRXjcDM1WbDyG3PhHIKYZYhBZIG41mPNLP53jA728VK40iH2zK0lxQImK
zai0TAuyUbGPB8BM2MQE/wsa5hF6VnCUQ47hqP4PnlZe3KtP8cwgc/L6FD+I66AUYC7q4+No
AlJcmFqm7CFolN3CcCd0KXv7w1P7urOzTd0q+gOjN0RVW7tSrZnWK3rrsQ19FjG82Sxh983+
QnmoRlzYGAuL+Y9/r/H9I0BgR1L3nrt/uePgvy66dl7ZROk6kZKNE80jBHF+cgSsBnbT8bAw
2XyB2PjUY90Zk7Cp5KBfzQOVNXzB+kVwq28LvzW2TZnC/1xLZVZn+rfhffiLhefV5+PPmRd7
ptU3iHn1J/GFwkJxofbhUCDEh2JSscOP2ZTfVHCXSzGpoolLMUXlSjG/ytV4ZOIaT3G0TEmx
qCydT+GUmZZT1dqAXCWxSyaRiEVekEVDBWvfX1ot9xcVP3KRzmhINZ5Px0qhWKyEzZc5bK5T
uZAKHy6ZaoznMEM+nBnSEBBD7qn+mMiB2L2IDDgrRM7yS5JV7U8ZhCRSJGMNNfDNZWqyQM1D
RLDtSxYXm4uLbXQCDjGACges1AER8JpiDs4Pn/w/KtojfuSeH35tMJBtPK2Qwkv+GucMaa6z
htWgWMPt7IEjtrlcZRORMlIdbV1yrCi05tUYgzgtS5aNjtC52rE9Dk02bB2fw5P1kb7moZEC
zfX//N160QwPNT9+srL+OexrXXnC29VbIC4nBgr0xtfOHVEG1uK7a7Zkovs7upo3z64BgKhk
NMjFHsd681hGLnvgjk8rfANvwfdPcvFuWtf17gi/fwldnerrKkSBsC5dPGn3mSBQNQNU5fHu
eZRcuj0bitdA9T+0XvNVFb1H6BGzyZxOhsSQpCQPGq6zxvfJ7ybnyIY4l2wYM+ZfkmxV2qRZ
5r7YF7Qva5PJr6QY3ZUkk4bRY+T7UB8uu5hwMieOmR1Of4qoMjecyMlYTsZkGVyBb1jju3G3
2CV383mcN3rkfFL361jPC2JI0A1BNHQ9TZEhSk9SJPxVAeXzstxN+DimaGCwsX2zFonJBuGz
WCp5XBFHRAKIMaywQNHCsnFAESsyFpmJuCILxG1kQkP1+YO9t0xcMJ0OBvE191H9jpNrFut3
7KPu9C/bTGAJxMWcYtpqc92ZtKPMIyjVcytPjl9z4Mk9aFyfsGx4JRUgKA49q8iZ9cny4dZv
I0N9w01686AGBq71sz07hoiz8hpz9N7i7mhiN+gIG8u+2Qq3GgcqD8wcuLKNP1yLdT3RmbzQ
quFvXyx1BSVStysdh0qXodIhdMvyYD4YqyEDAI7YlvfpYKzXhz0k8sg44CGvktPUFX6Rde2l
Jqkp8gz1KvkqdYWc5ufIGeot/s2Al2aCnZ5OL2YID8KYCHTXcN7tCbndHkx4vEcjkLaEqMWM
MnuZMeY0QzK7UIP4nRUNMTMMZtzImw6FEEGk/011+cc2cd0B/N67s31nx/b5553t4It9Of86
Gyc+O45xcK4QUgJJCGph0M0j2wpLQW3saFDxa4Hyq81apNJB2lEJhgqtChW0tJCGIeg20JDQ
lk5qm/2xDXXRNLFllDWgrSVh790F1P5z72w/n5/f9/v5vs/XTLvXuHaZfR7vKHgMyU72XRyK
bkT3hK5yk7h1TAN2ZqqssV4lcED2GRDo8r7tGHDcXAL2GnsNdx2IVsQjACG0wU15hQwBJAk2
aBJd1Of3/gbg+Y5nT4Wi+a8jZPDaRql963JkYIbOrwmu/qNjM14DNFm7dvwQvIT369OZIdiH
9osl1l+EZwgHAeArhBMeUAUHPZqF28LMaJbdJkIAWcJJM7iL0r1/BP5HtRPoEYAALOgFFUCB
X4FjhAO8AV4kdG+tauIq666PTRW0t7W3dbS5HA+tk9Ny5VNwILUgxVFM4+LUzJDx14lAbu1X
d3pt9eF6tMaFM0PgE22NK1T3t1flRIczQ+PgMmhlugDgldkIOwB2IGjdoL4wJ/EO+su4EdF6
kG+uyoFzVXNfVMBEMQc+mXnm4XoMnf8rRfxNTxpqem2iGEOW8r37X5J/IX9DNBItsKh6jCxb
oOrYQkZtacv+LPeK6XCOLOEl/WBp7lwB/NR0InWq5Xzqamo89FlqPPf3FJMzLTItcS3hOnKr
uHX0QeJw7jg4B87RNYoJ7Ci9Rv0i9XojRZR6Sj/y9pYGuEOe0+D4vEvgRslMe3tKPymSi2no
cXpgEf/Kb7nCrSLIKDRSGDkZk5OSnIy3KCeVCwpJKfOVLmW78pJyRHlHuaj8XvmzMqlYKgpQ
im46RK+lN9IUpIt0J72FfoE+Qp+gf0f/iWYsdABlNOl20iRvjQgyemJ8Xbq4GGaGiXI6DXk1
LmftvMCv4fv5I/xp/hJv+iv/L/4e6gF51cZmeYjqkcWeFJLpZGuSSrbFF9olQYLSTYJIM63M
IHOJoerQAAmGxdkELqisWtpRgmqptwRLb3mAJ4D/Xawn1no/AAIykWfzMJ8xqKKU7Td8YYAN
BtXQY+g1UAbf/OYVqBQ27tGTTu6arE5V5Y/KqNmcKpcHWlAO3p1Ada7VWZDT6HNc/CbZSXZ6
agKRxxVQG+TEF0cBuRVyePYazbbYWlpQTQMDWnuVaZ5XK5pZkrIjJwhJlkghYgs6gkRNHRME
YXEemQ8SbK01CMxhdGmmikGCwITOtltax7VzJ0DepblXVSaq6D0JdVaRXLZJ0k5JTfM5r8c9
+26TkkGH62xjludwGxaJOoz6LCUDO04+37N+BOQ4NfZIwl8b6Si2rhi4/syew5zN7Lb6A8HM
hraeJ8ybi9GQL5UZGn5q2YaT+7+/Ph+f4+Q9ghxrXNSpLN7VXl2QGJ45qIZYiV+ycOlBUHh0
eVN+rohtXL4/QQUQdxwRBctVu7OdJjiWg4D3OeoFbgT8Ww2Ikd2kKRixWGwDdjtr4QiCDYOw
avI74yh67y3N4UFtLs7P9sTH4rAhrsZ74pX40fiZ+OW4KW5DnPoEH/QlHE6VBQ2syvawl9kx
1sD6Yt1VHVZkJR9iyT7rC7Wy6HFn+TptfI8TWrGWIJhbCmm2PCDL2tS4PjU+OzX+jal3Hxx3
E6jsTsqkjUWaVdZD7Jcoq0GqjwT8tX5oZJD+SVQ4CubU+IKE1SaY0b1ojESB3xoMEiE6GP1W
iBM4xAtXqeJ2Q4Wp1A3WH6LfNJygz1P0c/QeBg5Sg+ZBYVA6ZBiuNyIBq5ZXAweOMI63FlmT
qFWfaA7oRTGjW5YYBqc3vdj7du+W67s6NxUOh01mWQG7jebOotLR2BRdsNLQOT29pTr2/Gtf
7WpoWksdX+6qDUBp+o2Z3kGx2DHv1I3PeubhSt99f4Jcg6qWSNxWn75jBPUMWM2cCF6BV8Rx
cBN8Dk1mGiRhwv0dYR3zY2ETs8k8EBx2nXKdco/AUfe54Kh4JfgHCZ0QHhdB2mrHiBsoR8bA
DQAp4AYQhFwe3sd/4QCOf/IRiym0mLLYbcAmAxyIjK8Vj2qAcWRRaT4KzqBv+E9Lt1BNsNcK
tbA2Y5qdh8dzMTk7ZgImrbLX2LImX33zfu1QQQaDAC93s2WUGuh2YgAfoZOTVbYF8etAHBeq
AAsxPiq1nUbYSRo+MJfN4z3XEUMOMgsddthME6kKC670X7ixbuv4yycXNRe7GCPHCQ3h7OMd
+aWNq27z2zYD/9VLL58+8EShrfvJVp9P6Tqy+3ZRnkugfViGWFmEWAkix9yiiq9a37J+aD3v
pZzOPE0E2SDkhBRD88eE4BVRlzXEz/vgmFFAN989T8u7a2poizAC1qg+bnMo4jahRxH6gZYg
eBbJXkLbQBvaITtYBuAZAIA/rVOGh7MIMjyqbrRfPemxNKykj6ZhWkD2qGJeVA/+6gPKxliK
9c1t3sk/LJp4TxFD8l39FbJEzMrklCYo7J3Je+BOWUfmITSxcMLqqpdECRqdkVg0HoVGG7Ky
SJRIWNFFcoRQe2WXNVSARklCoyRdsVZclXAlcSZ9OW2s2Aadm7hBsRLfmtrLDaVetQ57DydP
eE8mR5O2HfYXHBBHsbxaozut052epTs9Szd++mpkRho8nMeQwwGPPqyj+smec2kRfxDyPPlH
I51qntn4aH/72b7H+z7oW9hXZGoaFuxbskHipXQ2xcVWdSNxuv60O1RHhbp+vrJ09LmLw7e2
ZB8B/g3eObWJ6b373cLrv3z37YhrSM8CsowY8xB1IKeuMjqXusvufnefZy2/2W2SzG/Cq/Ca
42P4MTluHfd8Sf7Xah70oHrp8mRXkuvI/vCz5GB4F7nXdtP6Dw+ToO97Ac0wMk6DOpqky4Y6
LwHavSMg9n4g4jIZRkDwbI2F0ezWgqLrVX3hrPcpAhOEg42wx/tksWXxqPKOHOFPh1vDa8K3
wlS4Lo4NCYIMO0ueNgad+hhpyGpZU4PSaYwFrC80SyB2T7lrujyBGZRlnCwytilE4dS03llM
/J/tqo9t4yzj997F59i5873nb8f2XWxf7FzO8Z2Tc9J82W+TpgulzTJV3Ug6V6UNFaxlbbKO
DiqgLdrafUCLqq1/FLQOEAMk1KgZxS1DzYQQAk1aAKkarVArESZWKaNIWf+AOeV5z+kGCEt+
nvce3722f+/z/J7fA1J11skQ6JLJ9mgkFmH5hF9VmNZgWEGKHFdQJASmkRedxnFUNeghz6JU
oxobDY8eoB/Oz20/KNYQV63f90yPfXZoz4b01tqXl/Y/Wv/Jt37/QaY9lLFTg+jDqwe2jz4W
Pn/8wvFrd1Do/e+99ozq75k6nwEoRhiGG3Hthwo1yOPERHxA1ViJZ9wqj91NnQZoWV3GoiD4
gfANLAma6v51GmkqDzUbV+OVOHcRpEh39kQIdfm+kYdboB17TRLxVSRTNW+ZnAkDAYpS2KxY
3I4qepqAT5/RzRu3YOy7zjD6OuidwpKEpOtLwJDXRdGvCxRz2Ih6YurddpuwJLCgMARLOCac
ES4IPCNgYbezXBLuCm4h1mZaJlswf5e6imYQD9rWmJ2AWp6jtAg9bnZ5FqSPs3oP3zNW34LT
o9MFQE2b4NDQtjrU9wqlUQxyBwrbTf26pSVORw2npPpgnCuzJTlT6inl7E9IlDJqo03xoUio
J4RuBdserf+pUgqeOoX++MbRI1uG7WG+ScCRZI59gRurH9kVbec0DcWtrezze8bMM4uPb+ga
6U15ErIU8kpW6eKRPXBMzLa1zdxNqCSLGWa2oh+QR9pxi1TJt5/0nOo6q/+s6Yrnkn65cFf7
cJPX2+Mp8f38YNuEqxnKVvfo6gZ1XH2p+dnO857Xu14fbSHj2khK1KOY4QbcWrCsi6bgKPRW
SPYy8feXSTZnl4migglFbauM6McL/qhdrnFNJBQM0hINJvvOCULSZDliFm2uxiWIABlcPGe6
x7JJadwpNX+FeuKFX9s2jsbHowO1+0sO9YoDaKA7Oudm0ZzqRibtbhxP9PwIgYfASBVzBEkj
6gg7Mp7CNIidIEYSVjGLa5yLBLO2BVuxNpJs1WZtksoaefp9KkTzpEO381QgS/mD+dN5bjK/
lGfzR7aBPHaUFNTt8hA9b7xCJ8h1W6/OfgQ5suKEDaNRyEN1Ywi0sLlCNfOK4dS8QcUxnUPX
PX3L/U6WgLA1EAx14ci6oMmlKcv29HU7ATfNFUrGfQ1DbU+3u3FPt5NBXKMVr19l2e+iwYVi
IHrw2hZ+rmu4r/zTPzw8+/kdx3/0taXpsV0nnnjquWduz1e3DEw+3Ds02dX29L5U/5e+/+Kr
UvyL3HeeLHb0Ds6c3e4a1LUCWyDP7ngxVSw+ZhU+FSNzYyes4oUvPP/b8tO1lw8++erCRutf
/5DVUs/2LaMxWQlTpbSZYZo2QC/Po1tXGP7+3Ust/QWnKj9dsl2bWXaysFRg3S4XH+azfJMk
Mmkmr4o4jfO8/6Lvmo+NIyagqb4ae5PI6ZympjNpj6aKmUxCU1M19gbZm+nQ1Hwmg+LwKBPd
1+ROp1I+n+htVj3I0xkMkNTGSoCMPWQHyHApQEbh3T8AF1YRTK4DjNEFJq2BgawNECzb7wSQ
FEBtgXcCLA6gAB2p/IsFpBbmC6xZOESRKJfoH1mArRwPuzkeNnQ87OT4fMHxxAdJX2Aa8qyz
I+eE4IfdzSEzt5hbynE0tNA3YDseasLx8KOcWz3JlJ2LdU00JAbNH8g84JzqEF4fioCqYECj
fPXxi4p5YCfoIkBNFSrpnDBHKQlVHQWQopXZUkk53xEUKj5QPI2rQFiEKyBRH4lJYOK44qP6
IBWsPNh/itIaqs5BzhqQsnJvQ4TDlBUBiusFNpOdYYx3U9r7jxgI819tOzb2ma/qHcNr2e6Y
32/EO7bmpcDgWnYwJufKoMP/8sjozMkLa2f3l9ya5k61fg69dngw1Te21jITSzdrGt8W3s9d
fsJubget0AmyMeM6wLQwCeYmCSvH5EhFkhk/k1Bl7McJPqKpfioS06KmynSRiWpq4hfoA5Dw
PPxb2e61L/KIJwwSErxf9nooBgmIMh7sYT2E0wVBElWRFTujEQLbRygYAyXqFtoytuMDEccT
s8uy5yPodAQ5Q17kKFEmFVZVdisXlHmlyVQqymlYLCq3FT45sQiEAgd3r+qQSuPY8OrKemep
rDh84UBtoE96RW/gv3EGTLMbp3cSMj39dmF0zV1WgoUR1wEnQMjOtcF6fG9fk6ax6cheNg1L
wO3+b9Y2ozp08RamyPyZDoZ3iRKO2kwP2mftKx62DhdfCJ6wThTnrfniYs/tnpYeR8X4ZJsp
4iKb19QiHV19meid9Dm/VBR4CiLc83NAjoIZqnEcCTJxHG+LW3ESn4zvjh+KH4t74jXOvZA1
DAfnyP/D+U7eoJ/JPmxDcl0zbhssY2CDNd5krzPd7F+dJo0d1D5GDC+vza4A6RpVCtzKOmrV
WeZ/kXPz62un+1K2jDygy1xO7nPgnCFT05XK9NTbcuzlrxx9eljP5hGLcSyS4r2IQ8aYa/9U
haJbmVob+mjDqY275mYeym/s6hJwqDkjyx3tweGDkRV2xK6Y7nbgwk3Ahc8BFxbQD8llti3U
f4X9pe9d9n32n6Ir6WltySbS6XSmL7FDnBGfEo/Ix8Rvxr8tviK9gn/cekl8Q3oX/w0HWYnD
ntZWf4ffxWhMAWu4YGVckoSTyYSi+BBiwapeX4vqDScialjXVA0okwU2DOGgGlI1NZPJdGpq
IZPhXG+xIJ8W4anNii8ID2JJ2pVMBGEvSVSSCSz5WNRsqUyB8Xp435wEIvlScqcCoplENS0T
DnlvWX+32K9byAK1FtrkRTc8NXRoQfcibw1dvOSbw1eRj5GQQsKJSSmpJtnkEUVRJUalZdvZ
qdMzxsBupr6oL+m39SY9ZlpvIo5JMRNomeowkGFAddBaQVbdqy7Xl1dXq/X38OoE1V/QLKn6
im3Dq6vR+jKtGGdibT5ZMP5NePnHtnGWcfzes33n+Bzf+XKuf8V3tu98l/pysd06cULc5tyW
xP2RH0ApTUvUrqNFg05yuoHWhuKUdStDiIiCBhVMq8YE2yRoIFuXSYgGdb/KP41Aa5lAohJF
WjUiITRViFGX533v0nYdElZ0z3t3ry/yPd/n+3ye0HHhde+pnpg5hVdTVHgghhs1EpYocrx3
Lfir/uopciSigedOgaVV+kATIIZMhGFYtmONY2NEKB42cn8B/vbdzZluG/2kuufxQ39+AsaH
Viqdyr9W7drYSrm+9p+T79Q+kUxq/lzOs372C63fvB7LQlXGQtGNiB98gbjdPdYGqjHB2zRQ
jUCBIYnY2faLaF5EvI9iKEHxCYwgMByANfE3IGwf8TcAbgHX5hoVvsn4AtQqKnPYvTjHvXBY
sMplznUxHG0VbGyeQ3McojiBo7kZRTwrzouegjgkzolL4jXRJ+L9pXIZx/NWTzlMTAw3oY+4
GDGwVfOC6+hjlrVw16p2fPjVOwblefsANij49TsoivkKsOswPWYrIzQSRcUOyBU/30FVqWGl
A5rbMIP6KnFNkRbpqy9nLU3pgoUtZWuaUlWzvKZ0qKptoKymGIv0H19V7UFU0ZRBWNt5dZOm
DKsqm7X6MizyytV1h7zyoUDAy1LDTHWwy5A6AnUbeJCA6GflbJmqn63P15fq3joIPsTzCk/z
+UQc0CKOOeLZ+IX45bjHjs/F6fiNTDbfY8Eti9yyLliXLY9tzVm0dYPiK0qFruQ31Qg8p7Ll
/bVrNfpsbb62VPMU4LBc89TiI/VF+jMLGdz4TWceIV2fAGj11mqcqjrFgImzij/4xY8KK8IK
rgXMmDgJ+O9u/ycjpVYoJVNcu48p6p16ydcjI4ZNcQkZBdsLzDoZJYOyM1gKVVPAqTwBH2rr
zqO2qKT9bWm/bPiUtoxBpTN+FmHSABI4cWLzblvbX79Wp5mgFiwH7foVzjfuG/ePtY1zS3Vf
Pz3OjAf/zXjxTDR9ZJKgSB0ktSZFXvSCEBmCLvKvBYAREgFRYJb7x50YbneuQyTnPOec8+59
wf0eRHz+S26AuotFCMgF/nGE4Er0/0MLntXIJRZfu0/Al0YfH9tzLDPxvYkHHrEMqPOBpCiZ
KXO3FY7WWp2GxUuFZFem0Av3ZOIBnp/N7Ny8c9eeicmnnm6dOFwGlvEZyQfQ6eNbMkNDrcDB
RA5XgVr6NDrdtLWIsr0VeHCIIbZwmBaILThcXYG6MGkv5ur3XuEG2hhkYS31b++dsJAPmDrH
eN6lr3jeSXgiTC/QtucK+kuSFvkQmKuphISMYJ7jL/B+lOyUNIV3GFsHrlazAWBuwthpzNgR
FcjbVNVMOs3zoUD8kM/jZZOLaN/CMkJo8fYr9q5YLzpKUSYTINQdiUgYuyXQPi+htHRZoiWM
4BLgt4TxW7J7++AA1Czh2pAwiEuYwSXM4BJmcEFCEgZvXrHmLbpgNaBsgLotl7pJhIdYLn1b
Lm1bLoVbLoWTd8IDfVudbtcxDP0OfuuooC/py7pHd/Fbd/Fbd7BbK+vx7rvYTahbuAe74coH
U3e1RcpRcLn7A3MasLu64iD4x9g77bB3epW9ecze6VX25jF785i9ecze/P3sDaPiEZgVAb9N
CpzVVfP/EPLHNXuxfnLH3sckASRp9EYF0Uzs2mb0tgxXnkfHRg5uH3iu9f3DBL1z8QfR2Ueq
mZkW91A/+xEZwsvcdvu651XQYTuVQTvt2FsJZASR+Dl/SG9HFBvV2TY/l7K95H2DjXpt3Szz
XuRNqPgHbe8lYcQJQyQsDGwo42hrXWZ5SV1WaUq11f0qXvps9VmVVnlREWnRXuYQaVzwXBLh
0TieD4bKXDwLz5h92ejtn8bO6SRvdGVqTFidkW5CqkZXKCdB1RVih1tQRsjROUVOyzQjdUQ6
aIbRk52Jzninh+HbRQN+ZUpGa9pEmYqxKQOFgyEDyZ6QjDoCUZnq9EUNyvUY08yb+Tw4Jphh
qQsNoK1oq3A06GswzWBTaMRnmbngnDAbf5t+Uwk02UZ7g2/G5tjZ9ll+LuZHwB/Tk4AhCLsT
EKqapXvLYjTLEFYFWK1AQnE+ddQ69vuHDx67+ofrNy6v3xoNcfUeSzbaJT2X8Fz8+nvfeuvJ
51DXxUvIHBn96+++PDWyLZ7dsA9lXmqmIjiDRmubFzZSWaqAHrXjYsHPMxRLhRVGYIUw01FQ
YSbSFBbDBIf5gnlDdacoO6laJ6NsWISJicnpCsewIWEtWmsnE2LJyS8OC4MbyjjaRajCidJy
iS6W7NJEqVHylkQXS9pFO4iKQTs4EVwKLgd9wXhxbJrw/TQpliA8Jp7Bbr60EEuT+Kuogsth
krQ/YQpnlWwtOVtL7tbSPVtvggIwlKw4kxUuyJCA+6XbDtN6d0yO50w9pRu57thaA+kyHPIJ
y0BdnTmDotzUmk6TG9TsoZGyig/NWFNu6s1u76NSM95IfU1tGE3zCenb6tPSD2Jn5DPZH2k/
lV7MvqSdl36tiVsiiILcTsHzJnNQoGvW31uhmQgsSVuS8JwCMwnJN55OoJ7RuWhx+Nb7hJrQ
N0vrt+764ou79/78S6Ob11V2HehTywO6fbC2r/V8vRzL5ehMdL/nT3jem6mnC9/428nvvD+T
TTx/bGDn3/85OXgaK2AMFLANFJCCyeQhWxLFYT8fpWJKVIh5ZSolakoUJ1tXU28qsTeymh5k
u096uVg0xB8RhDDL82FFoVICsH0+LK6WOi+OizRwqpgoOlIoulLAEawuVJ4oLhfpRvFskS4q
XTBR+PGNAP6qHy37ETltg33+eKHfdWDwV6eIcbZvEjeG7APfFLDhXiepXXGz6uZ0Xdr0hfRc
QM+ks2mayetMLsd1GZTarsgoxJs+WBttmoHSIU1Ga9lukmVIs2PZeTfV+YavwTVyDXO+uFRk
oIgDTb2Rn+l5queH6Izvxz0v+M71LPou9FzqCWGqcZim6Eix6Eqx6EoRS2gyx7AktzCEEuuu
rF8FjnUwdIRJaWPmCDujKf3aht7hHfOHPjVz9bGJ49YzWSExfuv6xv6IWojlduQ3DRgbtb0H
7IT2zPFffPf2qb7Kwx9+8vPRHMr9l+2qj43jqOIz+3W3t+fd2d273fvcXd+n7/Z85zrr2E4d
btM0iUrBdkCkteCSVPloaPiIE7UiCaG0CVgIaNKKRKURoi0SUfknxS7JtQjhSCWAhJRIFBX4
o0TIKlVal1ZxS6vKNm/2LqEI7qR5M7tvZ2d23vu936+YqW/Bv8KPPLOvpG+8f+WNV++5fZAy
67sRYr8Cp17BZT8ilaRRKRYlHSCFMgz2H3Np23O7TB/sN2ftoWCYtTqXFRJYvxwzPOLiM9Ip
l5GSPaqnZJGFKnaWWKQi4Lhhmij3rG0FAsW8bGcDgZIv2BUaVtl8ZFDxrTGoc5nhpnI/pRao
IljZiNJCkZfwDsThHRdPha6GroVYQKGXfAlVFNM2GbOaz3VCKxdwAM8LbNoJLASy4c3n8IEc
RjmSY3J/rY5/LkCUjkIB2AAhubhIFgKZQmuA61JICAWQQKMHubirZoBYuzeLLCRlPtc9nJAQ
j5sUj4MKS9O3XApoYet7G0Y2bqgPjYciPdlUJe7gULQxshJa74YjpQH23CuP79jU3PjJOznB
yDXve/DVkVGSTrJABUePMPykkUnxlOVtXV1gXoEzGmRm/C9IA3HS5EhPJUayFU6IGbHLxcul
v5Dr5EMSqpBidYSsrc5Ip/OnC89JP8m3pRfyEh/le8KVeHSLdHdU8CU/ymiDNjrL2BhTtoF9
SWv+mFI4vMnX0VmtARe8xg03YSfPpu1UipZTcDmVwqk23u/nk2eNG5rGl9yQZpU0qYvevhb3
8Oc11Et6mV766SVJ8TqjnEzHdUhqW8ZySvFww5vwdnhf9R72znuCpylhO8yEfXig08ulKn30
rRQGABRuYkBfcg2t5BQDAAIWFlsurQu/CDvAjQKgMOGBsB/rbYbH4nlojCIMYeldukTr/vsH
KXh0Hux1YPuw1mu+CDP0boen6crnYILAwhyBhWmonb01kzu1EMzgJ7Hfl4AvmFGhIWloZBOa
HqPjOIWai/RFlmUpTau9+ve5aKxjwYPaWXAPHAO/FxEPLFoDX94CR94CLz5204W8tQQLx2Rx
aRGRt2iZ85WGH1GbDV9UoIG9UDfq1PGiby72w9Igj6/OdSxsFdhksR94JYz+6IvQKfYD1Sy2
V9+dA1gCu3CRFtcMYNZ/BNMUmoZUoNUKyhXW84E6oiSEu1WfIBXy7BrKSqBIQWoEqLZmMACu
YeYHSm798Q2VdTEHl1rjj23beMCSeo1ekuv/0eaB9WP7fth/x+nvf2pLWtWMBHtp5dJj+4YL
6WTlt9/dNn5msioN4skTJ26vDmze8sDIZ3Z96XxRUYCSoNLqDeYMt4yS6ElfPimdjDJBI0VR
so0vwPFwsRgbP85gwZEGJF9ipYPiHlli2DaW/SwvXYim0pjjkMLbPMNXdSN+OBbTffj4Oo0n
ks15DX1ev6qzejJFkQNiDz4v0P+lgOEDpR8nQChgiJrLC63m2DK9BkNMfn/bAJ5G01hdE88H
1X1w2OyAxpCaB5wYxu3XXlNKZMM6a+uFqaNq5Mg3fn4Ht7zys13Lv97ayO4y5netz53BH+an
Xj5Msbq5usDdxp5DOfzEi6gAq/spaLzC1QIjRtPRavSuKDcafSrzXKad4f4ZejvM5Hypx+ul
jcIj3eaJzv0thFdDGOgbn88rBVvP562CncvneYGPJPeIUkRCuRx8AAEJ1S4nswQq2QTQcALI
NoHKNoEqNoGKNYGKNYFqN4EqNoEqtisCVgTsCFcEBglEYAQq3yIFqgQLoNwKXeVW6Cq2Qlex
UTtb7dyGmQtd4UatnwTKOF/AduH5AtMoHCgwhZgdx/GqQnFlDiaWu7pN7uo2uTNZADs6yLd3
ZNyQ5+WrMisn810h1wX1gDvc0gP0t9T6+IiWiMVAycE/0AkBJWhN09oANTzIiYMu7gosmgql
UpfBdU997XAwZP/Qt37l+MZvf3biaLX8CXxMr6QL2b4RqraWC/tBZh2bvOu+R5/Fh6isWn5k
9zpLT03gpUBkYaSDxnobTj+DT/gpjUEM1pCGuQFrypxKTFoXo9esd6yQRSt0z5BFN17K2F7T
mDC2CWxIDtshzsRmGghd51QwbwsGidtGe/U7/gMKyjjpTGazQmKKQjBC2xUZenJGxogTiAMA
QShYDhCfMCRtKmmiyJjPQNELhQQhg6T0v8jhAcVXJhVWacnXsQ+PBOXFwU9jhgbTFcziSbqy
ubEJL1hhOl/2LL9H8Yi103raumZxxMLPwz6YLPAEdq73EmSc2zmNpWnIu+XkUmspsRjUanoe
mjmKgfeNwi3oztRd+Rh5eYavJ4KOm0BkEZP5Ttv6bxMcXqtFUTRu0cVadLEMUTNNTBuInWuz
sdHAxKn5YFZSmvgmHPKYIhyQdKj/AIO6HmAejAUBEuzNld+MOmY/frehJmpPHR3qH8WDtZGR
ld9lmD8dz6fEYlE1rOLelWdw49G1dpkpFoW1J5ZzNMvV1QV+Fs65xtzzgoZUXIM3++e0mIdY
xEmGZBJEWMKFGrGG0TCbsabRNCdiE8aEeS9/r7bN+jK/N7Jb2qftN/abu6299kPkiHbM+Lp5
yDrsfK18sv6k+2fhDfS6fL32AXov8p70vvxRrSREBEmQOcKrnOXXJ+s76yLGjKapuo4iRLIj
IIjsBFfGZbfPLiORiIzIhW3R1B1YmW7YZskp2iW/vfrQnMoyTnv1kP9FG9Uct1bbbDsx23Z0
JCLBZtB224KhxbEii9ntKompKgGcQcxmVYO+RjiW4cSapWsYCark4DedjxzGccu269hwVSUc
jtTKpYQZEYUayyCpTmO+NlQPMGDEC6zTG1g/kUx5dV+SPQR7Ys7Xcd00U+UHHbuN+y/4O9UD
KqP+EvcjB4ngHad8Q3xYXBXZAdEXJ0VWTPbX28y2IBLbuPYt1x2nwJFKAmqkEsup5HJifNOe
O19vdQADAnOMggT8boXmNPRUCM5P190wBCU/A9E5Lf9vL4hYN/XxmHX/b+h22pl/s1/9sU1c
d/z73vln4ue72OfEZ8e+BNtxwsW5GJwEGwebkJg0IWmAQKFgugxCIIPQhKWgqmxVh8ag/IFo
RSkbo+2mFU0IDWhZSqmEtGkq2zRNbFK3qSpoZV2LFOohVlghyb53DrRoo2hTt7/8Tp/3vu/d
3Xt3733e932+giVpSWpHTDaLTkhXD/6pS6dQowhjd8ubqA/ipRYxXoYgd6jLBbg77M2TV9er
Gnf/hcrc5Sm4FfvHnLA0m/yhPlixe2eRP6KSi3P8vp3bPVVNxFXXqEx+Wk6PTyyhP/quWmHH
WMNRsmzyObLZ3VljCYU4qay0E6s97Z5w0IBMb3hqQtKYrmLscRGZnqCvpDvDvhdl6ikXEtTx
qp8k2Pb6NxKcwy7KVfI2esB+KHqeXExaBLNgEbSI1F1mMadRusjmHnMOIwKzSYo1VIWEIAkG
dbnKp4KNAZNGgaedUupQ45lGWhchqs8vM9Vnl1mChwhJ8GaGjlHyeWQpGAnJwcZEk9x4xkR0
7+jG+MIdkGfIgQY1JjfU+e3oCvU8IB1Rj6l0tbpXPatyqu8F/ljibIJbndibuMFzj/C7+CMJ
zpfhE+hCExGNj0gsLN9OfxtF8vsRsjTydORY5HcRQ4Q4WDVuISNxkRAZITuJcTf7mXxD5nrl
b8nPyUdlww/Yu+wTxj1LXiRvEu6PqNPXMFlkTE6kHYEUT3jGq3zCIBOZyaqcMCTUiOzjGbGY
7lpSY0MwYJLcZlPRS8lzSZrET/opXxJL4mbQ5ug0Kk48tk1niB0I8Z9U9/neIn6I0G0wF5I0
c6rymuaIr49/MoHqRye8kr3LdZ3pZfHhYWWXHUme1dKwohOSIBFxlYhGyLJIvhSr8yXv18uT
qLXyvET+I5WxE9wM2IVehRKtd8Q9rvzzOcne7w6PKavgDsFtqOxQs+5k8r0k2k+pWcWNJkrZ
YdAPAE+D0qbQQdhYPOAfrHuVHJOPVbwh/4p9xIow9luJQ2SJs7TsTnwXC4f1oE873bEF1W0T
l99AZv0wwFC36XN7iA690hv1qhM3mn0Vi9tUk8VZWTu5v3V4U9fLD3fXU5M3ZjFy0kNVPYEI
6WwebKHNk79+WSmjGAeWOsuTB/vbmBOpyAeDnUdGyMz9LbiJiMMs8IJZ/U7jUK3LZwyF6ML1
+ukxmeHGcU+pZO3rPJMZtWmS/7jTNc9ARNIBHazds9LzqHdF3aBn0Luhbrd3zPu2117trBbn
wBxPBjJswDRgHrAdVI/CUc87EsNemcpsqt1kM8sml1QquwQjMRKDjJGJUxZnusLVQcWuqhmP
JHo8ko0xN4YtbA0QEZjGp0rVI9mZDcyusApBzSRGoyd4Rdnn54NX/C4R4wejyQPFX4leiuai
XFTbtUysjkWRnrxLdVEXioF0mbGmpiIcC7eGufD5SgWMv0XFLtVHPxMK6Jq7rk9kL6Mwz3N0
5K5Q6BLGU+PjGpmQAEQrHfFdljolLxjs0+4X8jfj/0435HOzRch7Xc3pZlEE3M9vUrMmBPUA
SCNOXgaSa5MXWufXkb9Fq2e9tHludB6J1yVaJ//eH23bsHRgYWxWMyEWC+/2VjdW0dcPt6Mv
pTPcVY9P7ifeF+aGalEnGJtPTHRO3k72PrYgsSi9oKq42DfzgLbyLvSmm3DlHeQvGPECV8p9
xN3iDGxs6sO0NRCKcRUeX0yrnfJXaGUuvUjyxhK0g27gvsmN2vbQvdwBdou7yYo6uYytla3i
ltve5H7JmamAr4/arlGqWlRrRUmFY7ntHdtfbTdslmJqsHmpaDM4tDWLlxSlLNYSRwkOb2OO
dezrbCd7nv2QvcZ+wS6jE7OyNZQTKeUo4RhYbWIxtRMuU2wd46rSrLgIHIIDVQcpMjm0lmqW
AXoaSJGYRv8JIhG1k1xEVhRbTlutRasIN1pc41BAD9XEOKTRk6ZgCugWnJAxGjrJRol2r0g7
19FxSk5xjHTeZcuw0jWhhwHXr2sBnDDeLei0GdbOcYzpxq+mHHE1KySvCuPTzNBOdIcmNEd0
/8bQj2lk1/wZ+jEsz2gHr14XXPmS19svnbQ7U9PacdeOn2t9CeeF84D+CTR3SUb0cIRk9X45
fM/Kp2zaMllRjFI3ZtjL1RNlcVQZClFWVlY2kMAMpFqgpNJFZqMTms0tuH2B0gN9vbHyAOec
pOlzP1bKS7neQNdaInhvvza0Hx3yx+SwQaClqCa9aUZTMAkeI5EMHW1aUHRZ+ABSXePI78qG
SoNw66KhkhzG4FNPmx4M+swXYAwZakGsATDGAEwmAHM3gOX7ANbHAYrrAWzfAGDtAPYPAYTq
+8PxGwDxSYDSDQBlnwJIewC8gwA+O4DsAagsBUA1DTN+DxDEvkJXAMLvAdScBVDeBYj4AVQc
M7odYDY+GMPvaTgH0JQEiF8ASOIY8xwAqRbEB3mkn7gXC/A/2moBMjh2+z6AjjqAzj8BdC8H
6MFxFl8HWPpVgGUHAZbjFl15HGB1I0D2JsBj+M19OYC1zwOs/wnAwPcANh4C+BrO0xDO4zB+
y9YzAKN/LuDLxBPuAgoooIACCiiggAIKKKCAAgoooIAC/lcACgS0JAKnFcSDMMEDk/4wWPMV
ocThFF2lZW7J4y3PNwWCoapwdc1MpTZSp9ZHZ82ONTQ2zYkn5iab50EaH2htyyxsf6ijc1FX
98M9i5cs7V22/JEVKx9dtTr7BaOeePCHfVnJACswF/DCX81V5Kpy8dyqXDb3ZO7A1NR0SySX
xpY+rYV//7NL8E7P6b2Je+CYFlg//SYHEuZk+kskvPK2Ca1ZWk8GK7bMgs5pm4IddkzbHLY/
O20b0H5r2jah/XFLT2vr/IzSu3Fz/9bu/m1LtmzuG6pt2bJp3X9+A1qgB1rxmg8ZUKAXNsJm
6Iet0I35NlgCW7DeB0NQi09ugU2wDtv6YQBG0e6Dkf/i/f/HG9pMGwW4Bkl82IgzK4CKr4N5
D647h3WcVLIP71gMaGm1OyWsp/+cEA8DIxygR689EDA4AFPONA6QMWc4TJmLobHMNHNWYv6N
7fH8Nl85JDnAqhc9NnUD0Zu8H7D97vzbI+DKYcoAynKMkLQAADJ+p6YKZW5kc3RyZWFtDWVu
ZG9iag0xNTEgMCBvYmoNPDwgDS9UeXBlIC9Gb250RGVzY3JpcHRvciANL0FzY2VudCA4OTEg
DS9DYXBIZWlnaHQgMCANL0Rlc2NlbnQgLTIxNiANL0ZsYWdzIDYgDS9Gb250QkJveCBbIC01
NTggLTMwNyAyMDM0IDEwMjYgXSANL0ZvbnROYW1lIC9CUEREQUYrVGltZXNOZXdSb21hbixC
b2xkIA0vSXRhbGljQW5nbGUgMCANL1N0ZW1WIDEzMyANL0ZvbnRGaWxlMiAxNTAgMCBSIA0+
PiANZW5kb2JqDTE1MiAwIG9iag08PCANL1R5cGUgL0ZvbnQgDS9TdWJ0eXBlIC9UcnVlVHlw
ZSANL0ZpcnN0Q2hhciAzMiANL0xhc3RDaGFyIDEyMSANL1dpZHRocyBbIDI3OCAwIDAgMCAw
IDAgNzIyIDIzOCAzMzMgMzMzIDAgMCAyNzggMzMzIDI3OCAwIDU1NiA1NTYgNTU2IDU1NiA1
NTYgDTU1NiA1NTYgNTU2IDU1NiA1NTYgMzMzIDAgMCAwIDAgMCAwIDcyMiA3MjIgNzIyIDcy
MiA2NjcgNjExIDc3OCANMCAyNzggMCAwIDYxMSA4MzMgNzIyIDc3OCA2NjcgMCA3MjIgNjY3
IDYxMSA3MjIgMCA5NDQgMCAwIDAgMCAwIA0wIDAgMCAwIDU1NiA2MTEgNTU2IDYxMSA1NTYg
MzMzIDYxMSA2MTEgMjc4IDI3OCA1NTYgMjc4IDg4OSA2MTEgDTYxMSA2MTEgMCAzODkgNTU2
IDMzMyA2MTEgNTU2IDc3OCA1NTYgNTU2IF0gDS9CYXNlRm9udCAvQlBERERHK0FyaWFsLEJv
bGQgDS9Gb250RGVzY3JpcHRvciAxNDggMCBSIA0+PiANZW5kb2JqDTE1MyAwIG9iag1bIA0v
Q2FsUkdCIDw8IC9XaGl0ZVBvaW50IFsgMC45NTA1IDEgMS4wODkgXSAvR2FtbWEgWyAyLjIy
MjIxIDIuMjIyMjEgMi4yMjIyMSBdIA0vTWF0cml4IFsgMC40MTI0IDAuMjEyNiAwLjAxOTMg
MC4zNTc2IDAuNzE1MTkgMC4xMTkyIDAuMTgwNSAwLjA3MjIgMC45NTA1IF0gPj4gDQ1dDWVu
ZG9iag0xNTQgMCBvYmoNPDwgDS9UeXBlIC9Gb250IA0vU3VidHlwZSAvVHJ1ZVR5cGUgDS9G
aXJzdENoYXIgMzIgDS9MYXN0Q2hhciAxMjEgDS9XaWR0aHMgWyAyNzggMCAzNTUgMCAwIDAg
MCAwIDAgMCAwIDAgMjc4IDMzMyAyNzggMCAwIDU1NiAwIDAgMCAwIDAgMCA1NTYgNTU2IA0w
IDAgMCAwIDAgMCAwIDY2NyA2NjcgNzIyIDcyMiA2NjcgNjExIDc3OCA3MjIgMCA1MDAgNjY3
IDU1NiA4MzMgDTcyMiA3NzggNjY3IDAgNzIyIDY2NyA2MTEgNzIyIDY2NyA5NDQgMCA2Njcg
MCAyNzggMCAyNzggMCAwIDAgNTU2IA01NTYgNTAwIDU1NiA1NTYgMjc4IDU1NiA1NTYgMjIy
IDAgNTAwIDIyMiA4MzMgNTU2IDU1NiA1NTYgMCAzMzMgDTUwMCAyNzggNTU2IDUwMCA3MjIg
MCA1MDAgXSANL0Jhc2VGb250IC9CUEREREkrQXJpYWwgDS9Gb250RGVzY3JpcHRvciAxNTYg
MCBSIA0+PiANZW5kb2JqDTE1NSAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVu
Z3RoIDE4ODUwIC9MZW5ndGgxIDMyMzkyID4+IA1zdHJlYW0NCkiJXFQLfExnFv+f77t3Jo9J
hIa8tO64klYmKWIVkY2QmdAlkQc1sVRGEklUJPGMileV6HjWjyyqulZVVOmNDcKyq2+7GrHa
bel2vdoufaTs/n7KVs3dM0Mte8/v3nu+c853Hv/vfAcEIAyLIJE7qqBXSn7N6CZgAQuRU1zp
qXa2peUD87oC9Ebx7JlaQ/Xp2az7HLD0nlxdVjnn0V3XAasNUI2yqXMn32xf8xcgie1Tj5SX
eko+GPZtDvvL5T1PlLOgU2XHNYDtCK97lFfOrB17cFoJry8AkalTq4o9FJewEZh8htfOSk9t
dfBB2gDMZz20aZ7K0vkvBEcBdVd4fbO6asZMzpufuuN+ffX00upv99RcAuwcP+S2ehgx/Maq
OxGjJCAaMC/ze8X/91WYV/x6/198w7tb7r5AI/ZQBfbgT3ibrvGuN3EIzTiOKDixBXVYj3pY
MI4lLyCfSWX5eooxm9EL2zifbWhl27EM4mF0oWjzayzEUvkR71rKSHfHEOSiCqtopDkL43Fe
WYL+GIlpqKZFpttcba4zX8UOHJLHzdsIRSyKmVrN79Uz5udI5h0bsAnnaV3wfmRwlEVs+TKm
Y7OcoJBZZv7IGdgxh3NQkI1WOiYc7L0Ulyma6mQme9luGua7bNUVE1COzThM/WiYsKvjzWyz
FV04Ri173YR9OMDUgqP4jGzqNfNV8xpikIQnuZ5mnKRj0nd7sW8wI6YySj0xkDVV+CM+wCnS
6S1RpdrUFDVDfdb8GJHogzGc7U7e+U+6IRYwLZTvK1nmUIQzLi/60cZ7uEix1ItG0VOip6gS
W+V0BHHEPkwlqGC8N7L3c+SgA8Im2uR2Zbdyy/Kw74IZzieSgJfwMt6iMK5Uoxn0HH1CX4hM
MVG8JC7J9cou5bTVw1U/jUqswm7coE40gPLo11ROdVRPL9ImaqVTdEUMEaPFM+KqLJc18qgy
lKlAmaEsUZepKyxXfG7fu76/+m6YKeYy5HE/LObsN2ArV3YIbTjLdB6XSKVQCmfSyE5jaB7T
AlpFv6NG2kXNHOUUXaKv6d90nW4JMFlEnLCL7ky6mC7miPVii2hjOiW+E/+RUbK7dMh+Mk0W
yirOql6uZdovLyqxSptiMs4paoP6itqo7lbfVq9ZbNbnghD04U/bbyfePueDb7mvwbfP12xe
RGc+w1hGoRvSOHsP0xQ+7wbuuDfxEdkYu1hKpHQaychMpClUQ7WM5PO0mXYEct9LRxilT+kq
5xwmugZyflz0E0PFKKanRamoEWvFOtEsPhE/SqsMlR1kZ5koh8kJslTOlHNlgzTkh/If8pL8
Qf7EZCohSjelu5KgOJRhykRllrJVuaxcVserJ9SvLCGWSssyS4vlX9YnrOnWXGuedYJ1jfWA
9eOgIu7Od7AfB3HfQxfkYumS+7Fa9FVixElxkvt5IkpktuBOFY20XMynZtFDrbUMEoMoB9eU
BMb6ffGK+EEMktk0ggowRfS5480SqbzOvzTlHbQrR7i2k+y51mKjBeKqxYZ9BDGQY74neysO
eQKfyfNkVbbh70oIRVG72ClzuQuOKumqG3a5BXtlDc3HfuHi6XQraCX3cQ69znNhNKXQTWlC
ihzuov7yCyzBM+IM2vkeL8dvqEQpw2r0pTpcxmt8K3qq0yyJls70Z1GheMVD1Ayh7OLqBlIP
kmoknqcJcrPlqjiLWWhTQnBOvsHZt4m9Mlu5puZTOd+A+ViGGnMx5qpu5TSVQdJTiFcu8HSr
kymKnf8LeaqM55l2gG/3YZ4DQ2Q2S6K5c0ZyX4zhCbGZaSPPCYU7qILv+FieYifRbBktWlCm
hhNPHUA54cvHOPM1bDLLMM1ch2SeB/VmHXtsxFdYg0Za6puHajzCN+ccjVSzRJuaZSYLrzgr
CkTDg+fLaMdTNL5h2osspKt/gFf5FAUYbK40/8bd/RhP2E2YhF/hS67ye44wXB5DX1+OaDKz
ZDXXex555k6zG4Wg3JyKUTiCHVYVHqsjY8iQjMHpv0wblDpwQP9+v+ib0qd3r8eTkxyJPR97
NCG+h97drnV75OGucbEx0VFdOkc+1KljRIfwMFtoSHCQ1aIqUhCSXHpWkWYkFBlKgj58eLJ/
rXtY4LlPUGRoLMp60MbQigJm2oOWGWw5+f8sM+5YZtyzpAgtDWnJSZpL14xWp6610Lg8N/Or
nHqhZrQH+OwAvzbAhzFvt/MGzRVd7tQMKtJcRtbscq+ryMnumkJDMvXM0pDkJDSFhDIbypwR
pVc3UVQ6BRgR5UptEggK46SMWN3pMmJ0pz8DQ8a7PCVGbp7b5Yyz2wuTkwzKLNYnGdCHGh0c
ARNkBsIYlkzDGgijVfirwQqtKemYd2VLBCYVOWwleolnvNuQnkJ/jI4Ojus0op79Mvp/S3be
KdNdf782Tnpd0RWaf+n11mvGb/Pc92vt/m9hIfvgvSI+q8ibxaFXMogjCjSOJpYWug1ayiE1
fyX+qu7UV6q7/JKiKZoRrA/Vy71TivhoYr0G8ufa98XGZhwyLyDWpXlHu3W7MThOL/Q4uzZF
wps/9/cxGVrMg5rkpKaIjneAbQrvcJexhd3PlN7TBbiAuZ8bkX8PWfJnpD/JDWFoxRpn4ta5
pgH+T+kAeIsHsBk/hcS7jBI+kQojOLPIG5Hql/v3G2p8hK55r4M7QG//7kGJ567EEh9xHX7W
3yf3Wo31P/OGw2EkJvpbxJrJZ8o5pgfW/ZKTZrcIXa+O0PjH8CGXsfUUpvZi+O12/wGvaMnA
JF4Yi/Lcd9YaJsX9l/tqDa7qqsLrnLPPuRcKEogXChlKQkiBQkhI5BVBLq8UiEBDyOuWSnhY
KQHBYis6bblMeIRLohWFSYHSJILEBIcLpDYwVQIzbaROQTuGqsVHH5mxjWNph3amUHL81j77
XG4OTINV/5i5X7691n6tvfbaa+9zgoIZY0qjehnXtLo1gUKuCbs1se5lqYjkZuKHbCDqvzf2
65cwMHHO6pyoNvAzqr/u1OcVpOblh0qS50TKlG/zlnSTnPrJsTpViibOKjGSdFXSkwxZi6Bc
GmvMQkmfqEjDz5JBvarF50dUSo2WnBtNKJvr/C/tnZJyh51a7CvcS9LNbsrMaM6Y7vKXu8nd
zOsTMWAwLsG8JaFIpHe3OoSaM+E8RYh4WlKSkjwrSoU4mWn4tditkxmlSdEgXDaLGyD+HJUS
uzVMUuVS/HF0po/NRaKLRHJTk3MjZZHlLXZ4RWpyQmrklH5OPxfZMKfMDZwW+/SupGhuVSl8
tVrLSec99X2layHNSqBrx7qyE3LkLsf9mX0tpeJ7WiGqv05fExspAMzzDaXvmEVUou2gkN5I
TzCMoRQUR+lRtG2EPAN8mvuifSHwV2AqUAQMUboFwHKggGW0PcV9McYGHkfyRgr5h9F6s8i+
gfn2mm30MHAQ5XrxNjVYU2gd5EPod0YQTeI26LPXaqQa6A+gfiV0B8ElkOtQXop+marcy1eN
bx0wYEE/GuPsUusdaZyliWKj/SbWUoox5wPbMccD4FwgD20SwTOBHVobVWptdj3qwVSB+Xew
HpiteC7G2Yb66eg3AnIFykNghwXuB6QAo/SjNEX/Ir0IzsD6i511A220mtccWxPsVzbdCsfG
vHhgzl8CqfoUuwPcK842Lyo8mGdkUxhcDiQB+fqrtE58lTT46xmzgwyGn4j99BdgmlhFCyFr
sLPAbKZ9LAMLJDbaN8QBqjWu0mTUfc/ai3XgS5ZfjvrHlKH/g9KtNNqM+JqN8bcABzHm32U8
rKIlmH8cOFt0yBjaDlRhrvddP7FvIG/Bvi7GXJ/6OYYbqQC4H/sSBtayPZg/g33O+64VdU1B
23fQZikD+kESWDvHJPfh/hgrTcVh/U2merSphl//BhZAgG1wIeNMAXUvY5zBgAUMBcYBHUA9
UA7kAC8AozA3YV5DxitihmNTxgdiw2yDD2GbjFlnDQflfjpnpk6NxfOkWEepXCGFx+TzwjEL
W467Y/OZ4phxWcZ3Oce99gGvk2Mqxjh7opPuZxvkGURsucznDjbzedirF1IleB/iuIJjlu1z
mf3CsSZ9gjOheGrcWjPlGQEbRKkq1itcdn0R49V0CGOWWSuQU2pprvg23q4/pBXiCs02RtM4
MxM6rAdto3onLfbjXYu9XAT5GQ/XMHzt2hqzFetsgj/b6Vn49FuiXR8u2jXTbLLfNUk7bzbp
T8nyLeyF1urUMTPi6/5d/eeBfslsQs5sst8z220b69nNZ8LXqWUCyS5DfwIIA/f5x2g1/nKt
xVdICRbRVWC9CFKOGaRJohX7E0Cex1mAvtB8k84Y1bRTtNt/1MIU1ttpuy9Ay/H90Y/n0i9R
BYPHB2+Ii6NuMeeNJZfdePUy53wVU8PAFs7fBYV3FD4GPkIc/URz5pjE+VneD8jRwHYnXu1r
sfg8T4fBu9z49MRpuSc++3jj0svybkF+d88p7Njprp/zI+c4zpGc5zjPuO29HNc/ojcijjkP
v0ohda6HK8yHjW+ps488jP0utm0r1z5iNdsNxgC7wcpC+Q+AaR/BujfF7tQSu0vdp6Pdu9TR
013uPWpm0zqVzw7JfPMh/Vjeo0XSvl7WMdpsXse+IwdKe2vVGYQ/YXe5KIPP91EV1jHY2IHz
CD2wlH0i94Lobr4X+E409sDPfBdVU4XxBt4L3Deb+sv7YjoVw/bzUoc7lZl1ZjHVW52UJQqR
a1tpFe8Vr4Pt4b33P0Z9/QHkiXYaL36GNgHqjXa10gdBOiLjgvuW4/UDX/hWkg8xuxBteLw6
2SdIA5Q/DklfyP54i3B8sS8wphWgxfI90UnPmYVUjDNU5wtTnVWIMxegBoxxGP0K2Rb0GyLv
6z30IM5XJXJTJXIOyfgP2deNJqxnE/I6YIThoya62wzDh+Vy7bOFk2N38PkxGulejhFrD/Iw
vyf2UESMoTlWOVVDV20iT2LeXdBtxfnNxNndif7DVN4mzL0Teu47nd8y/Ebg8+ILUqIVlu8A
kjbwOwXzG+9SnTGfKhHHM/x74IdtlI77QkPs3QOMdyDlpxSqHEhdgsNaipFAT0p9Nr2mNxp3
IW75Dj0lttAjooiyjPE0WPSndPE7nNVPaL/Rj5aJV2i/aKEqlkUijTLwzjWa8bZk/UV6gPX6
a5BrKCSmon8lfVMso43GccTe76m3eBh7jX7m9xEnI9D/Q4yroL1NIaMIZ2s7yp/YR7mdnKPZ
LmaIuZQu+8VB2urCY7OeB7/Nx57CXi53sxe2xux0bbyNfXKdPC76cRuxn6YS2ZeBNIe78vVq
agJq9T/RLGMBfVdrQII5QLlaB3BA4ec0V/JxIB93/ATtCWCcmEAvAFtQHgv+FXDMkfF2m0Bv
ANsw9lnwSf4uYOgzaSIzdAeBGuA3bl08eK7b6eNhJlF3+XkKM7Sr9g2Gtz38PBHzTRTT4E8A
sfg0w9pMId/j2L+R0N+DMT0y5skSz9OanuzpCdpFypQ+dBCMX6O7H+CBd4DLcZzMrO6G/8i+
zwPs72bgIenff1JAxdAXtEs0HFwELjIeo00MyOmQS11/alcRa4wG+pHUx/bP0SNWCO+4aV69
V/bua0+yfpIOx8ONg1g87KatDDEd7QGv7D9PWxnWS6h76VZZHOkBIbrP2CdtIhljHtlahDsT
0EfA1iGyTxUjJl/EWQa4rezfl6oZ8uwCejM9wojVT0D+BuL8OpH9ijllvbs/7r549wf2BcUF
IIS74gJlggvAM1yOxbfKF91iPt+J95jMuaTD0+bmmbh5Ni7yXXP7Mf+fgLPzCtAGvPy/nouz
DOeIBM4Tl/EOmY53ZDveJw9SBdEN5JJPM4CfIg8tAb8OHW7vrtFAX5T7Q/cN8LNE1z9C+VHo
2x3YukiiWvWuHAzdL1RfvxqvwOl//ddE1xBR1445/a83AmtQ/gB4EuU/g8+Ca9D+PfTbCj7n
1N9YBvlx4EXInZDXAiUoPw0OgMcCicAA9N/L4PfILd+h/3W+/ffHnTLeLCth5zDwafAT3m+I
O2Z3P3tg77eGu/89sam+JW5lxw/4ZnoL775o/LfPZ33juIz9VH94EKZSP2MQvQ/YgEHD8D8D
WAQsA34APAdYsh1r1gObgTPAFVkTNAad2J0dbAHtknRyzdosKS53xKUPSfFkcanDC/Idnj3P
aZbjNBv/JUc9bqbDI8c6PCAtK8zcu29W64yBxkD6LaDThn8xXq2xUVxX+N47+5hdY/YB+IHX
O7Ne76Z4ANuLwRhv2FnjrWlWxA641OvY2DwsUWiF0dpYqlSYqEUtSsGolWigUu3mR1uFRox3
g7s2SHblNm3cuFQtpVISHkmtqvxwDBEiICDud2cXKCqVOrPfOWfO+e495z7msZCU/ZY4KCUS
GRaWER1ggiXnUQV3ujwYGpoQTIQKTKBkD5EWJgWayneFona2wOaJG9vgUzaXjbC59GJXaCj6
EvuEnAMmAIF9gvNj9jHeuTdwOzsgI8AQMAFcAuYBC7uB8zrOa+waWFdJJRABuoAhYAKYB6zs
KqSTfcQfDobkdgRg7CNIJ/sQw/oQ0oEvRMo+YB+gtL+mautCY4ahVOYMKZAzCktyhrsglGF/
Sd1fIWXYP9KyIg1Hq9hlogMMyS6j88tEBlqAbqAXsMC6AusK0YCTwDCgA/jnAekEZDYNvA9c
IVWACrQAIvtzCmky7FIq2CBFC9if2O9JISZ1hv3B0O+zdw39R/Y7Q78H7YWeZu+mvBKJ5iFO
0MYJ7YSuRNzMfpMud0sLURebwPRIkJVABGgGuoBBwMImWFlqj+RGJxfINJ57EkuRm4b+OXlT
JOo+SQ1uwh6TuQhueBEWxJA8FGRq8NRpXHIRPPFDWFwEv/sDWFwEv/UaLC6C3zgEi4vgnn2w
uAi2d8HiItjcCgsiw3766/IXpNrm/VSOOtgAZmkAszSAWRogJjbAT3LfxGv7SaqiAjN2RlVW
VEjaONUuUm0r1d6kWg/VDlPtNaqFqbaDagrVPFTzUk2l2gW6HlOhUfWdZy7r1CKqTVPtbaol
qRakWoBq5VSTaa2aYb7UV9YYKmaodJTfV9Avbgw5UKMPM+rDtvbhtp+AvAQsGFcqSHJZllzs
5bosXRHJXq/eEDoQ3cym0HAKyzBFrgMmLNAUttEUOplCBw7ICNAFTALzwAJgAbsMhQ8a0gFZ
CUSALuAIMA9YjHLmAUYO5Eo8ZxRWmSu6mV+xKZxlOH3Mp5Y6PU7FuVkY9FCHlzZ7F7yslhTg
e524XaIrQ/NHP8+/93k+sUVt7AQbJKVYiJM5PZi6Xypl6Bup4AUpuoz+mHhN2HW0jgRpAHo9
Pv349VriEbmuIR52FjqU8mxHM0cquFIap4t5q1HpvmdWuunJMJj/8lyQ/i5nTDQl/Q2es6PS
Zc8x6b3KjAjPxWCGQo3LBnXMs156e9qgvobAmZR0mKtR6dueJmm/xwj0ZAM7krhSHdLWYLu0
Gf01enZJahJ9jkoRzw4pnGWt5W1GpSqUoGTNChS7wmMk9XuNDr9am6F71ZXWU9Y2a7N1nTVk
XWn1WSVrqbXEulR0i05xsbhItIuiaBFNIhOJuDSzcENV8IVKllqcXPH3Ef6EGLaTcQlhPNeo
yMhLRF8ixFl8WwON65O7SXyXrN/d5s9Q+yvtutnfQHV3nMRbG/T1SjxjXdiq1ypx3dryatsI
pScS8Ors+xlKWtsydIG7jpbo7k1tY4RS19HjJVx/6ejxRIIUFRyKFEXcG111X258jujOSeXp
UfSMXaqfim9r098qTeghbiyUJuL6j7bJHW1j9DN6K9Y4Rm9zlWgbEzbSz2JbuV/Y2JhIxDN0
u8EjMr0NHnbMbYMneonMeUQWvVnemSwvgPbglXMFns1GAgYvYLMZPBPlvJFkeaxxpLzc4BTK
JGlwkoXyf3KmA+AEAganQCPTBme6QOMcfaNB8XhA8XoMCl1OPAbFQ5cblO1PKZU5yrEnlGNG
JoE+5XiynPwbjzn5N8BR/t+jp0FRaLo+sbsj1uOPdftjPUC3/vqhvUW6tkuWR3YneEDWhWD3
rt17ud7Zoyf8PY36bn+jPFLf8ZxwBw/X+xtHSEestW2kQ+1pTNWr9TH/zsZEuqmlpvaZXMee
5KppeU5nLbyzGp6rqfY54VoebuK5anmuWp6rSW0ychFjj7e0jYikIbGpI6vTLM+O/dpd4ks0
FDh7Nxqbt95XdLhk3MT/NOYpCX2Rv0HPB3hoVXRVlIdwT/HQYrgduVDR4XpfyTj9ZS7khNvl
byBKX3+ynxTFvt6Y/SVxwNXXzyc8K5Xk/zoQi+nqzsZkHyFxvWJbXI+80t42YrXC282HpG94
7MvLi2UWJrPO1XBu4E5BeELkvjD32Ww54n+vf39Ob+J3gcYupKnqpX0kmRB0b7yV4VHQ2o6x
drS3jeNzib8ekgkMMEkVmnzch1E2ydqEj/cx+vpzVm4e+nI62wpNko+n48mBNnhU4UEFYcaJ
t4uVNLzD6KzFmmGn1SXEbJoViN1qmqWkWLSYZ5lwkVUTGz1NV5MixXk3/Cj8svNOeMujMInA
dj6EqK7yuXyuAAQei+ShLEw+VM3kAZFNk8hFdghpNmAeR7o80j+GP3H30mWBGnNm4Z5aFlxR
k2exW80ELxuz2ZL3qU0UBYERqxi2O2yajdkwteqyfEeN7RoVTGFG1XxXDS1edPAXRQoKUXgl
zkdKZ9goyInzURiCutx1dRzVVVRRlghr1ywT1hjyZGhm1dXqmSohTQtv3friZlby5/dbX1yj
3yEzxE5ePm/HxJy1ZGiLGqRCmDFqp2Fix+e0ECaW9dYNzaSLHCBHyDBGNZz3szcwNXc678w6
55CbRLh0zjkfzfEyqqvWIO9Si/WFdetqR2davhaqWyfMzBx8PbileOeryBulGbaPfRNrsVIt
7mW9AttCtyCln7Dl5l4Qik29x/loZzud/ySVW+aqq8hB2rlkrW9ZlK2gmfPnefXjEN9D9QIJ
qEWMFxvOlniOmIYRHzYZVd7t7JxDgdmixmdmZnjb61imB+ZJjDypygKf4f2mI2yQnRZNvzJR
G7GYmWAz00WMTtsJXxC3z19TRaiMtssXmVUsj5m7F3O3mcpm1czMxXnjNEyPkmzlBxWe+6CS
3TmRwjrq4mvTSToVn99lsVjXYnbWsAf/5rpKgJu4zvC+t5dW2pV2daxkWVqvLHvlg/jGB4Z4
OwRnOBxcIFADAoOL7QJOfNE0HMGAwW6AwQ4tNJABhwIxBYfLZWyHKeB6yLSkAy2TBJKmMAlH
yYwmpGRoS7Dcf2UHpmj03tu32tF77/u/7/+/7f3R1Tm7v8xsptY8vzbh/Rf/vNjg6OyRu1Qc
7M9NBIks4oZeMF5GqfJUeap2h7+XRXNZaB2xDq2lmk0NlkZ+lbDavZV4E22jtpg2WFr5LcJ2
90fSRYc9ESr5KZ/qNQZVzTSG51TNKO9KqsoTiofg45WMrgyUYQ8oDJ2i2AWl6RyHuD5co4vp
TTZdhfPZwMOJNmzrQ51ncjxNJ4AT8PuppCbXDxCoLt2FXR3ZH26NAZ4e+S4cAXo0xC4A/JKI
vSicGSkqQmMMLRz7oHBjA4RW08bn5efmyAZpZOiJYCIBdxxOOTcnf3yeFkxkSKf8dIKW16+8
c+781yvq2rZHH16/Hn3YuXTLitrNv6yuaZ8wtWP2hu6ejevfI+NTf7O867MbXdW7U8cNtZ8d
AStxfscFNKe2ddPiqrbWxyNlHTMPt2z8XTdo9uUxxBUijfiDnjfBO0PWgwvkecFqcqVc560J
rvauU7Z5typ75CPes96v5TvqQ9UxSd4n98jkhNSfMjg0MHKTCAK2noDKqCnKTOtiK7ZafYmK
k0ZXy4E5fbi2l1J8AvjIIsKCCnXJoxsE8iDCI3qwp2Mc6kOFvcTvk5ukJ9BKuoSljvSn0EZi
tIoYuA6HbxnQZoYjY5gSYUMnBQZUz+PxeSGGCSbCSAC2dknEMNNQDEFXDNr6HnntktnryvNR
/gd1Zx4j9uKOyJrV3x449hm+dKj5F6eOrF33Lpotrn5lxvpr9bxn7gpkunYDiXuiX0X/Fb0b
Pf3+OTJv75mhd7YdPw6CGhmGHFsBeY8lrEjRqzLFLLHGVMtViu1kh/gn+iJzXrwvWkx0BZqL
y8VaywnxAf9AeGDlKJ4SKCtpMXM0RfGC1cSwLA/XJoZnIXOrLO+EG5gkVYp3whOcQtMmhSGZ
Plyvc4SJv6djhPEAskCILbqdV4llLDmrnLpM3aDIDgpR4Ih1Szl/nr3Bkx084o25aGMvs3g9
28Jidqftk09jKa0hDhp8PREx4o0TAWZPyURvpOTWRCPVRdrojPR14lBbhscYRpNuUVGbODRk
HRpqo0dHCMb0ExaolgpUy17KRprYgZH7Rh0wYlSBGhvCQZSLgmSAdARILcSwJM79K/7JF0eH
9757HX37dmmiL5ceeFSKzkZfwPPRrv7Xtm+FrLCLIKh7gK8E7zNpxAa9nKJKg3OD1cEmrpVj
fuZdRddzTZZN9CYLE5I50hNKU2Q/xznsSlpaairh8yuAUoKiSITJozFzkjXeO86vqLGsFk4v
XhhjWKzePSwDnsXqndGAYVByJhZlSkaFQXb3WCLLlQI58hPRWnEQBXIK8g2NakGojTkFBgeN
611Y677UVF2zece8lgvbojvRpA2F06aXbtwX/RzVLdImz58w59fboj30QEX/skWHc0NnW2pO
VmaTsyS5umzqq6nfd7F84YrSWa9nG7m7euQu/XP6KmDQp1dW4eV+rBI5QhVRTzT7W4hWfwex
hz5KHhL6yV7hQ+EKccv/wC9Z7X7J7yfTmBQpzacmvCjMdc5zzY2rpVf419i32veQb1v3+LrR
QdwtfWx1EE7CKzpFL4X7Rv5xKqUIGWoMpRSJNgJR8Q6FJ+MVihM12zRCUxFC3gS3ppqQKU6p
Whir0uGyCIAYHkUR0p/kHq3L4XADEUaNyM1QwcQkQMeelJtDuVnN0CR2Oe2GKqnewUnRP96O
RD/dexxNHvw7Gld8Lndw55GvFtbd2fLbLzHO/ub7C+iVv91GL5+8eem5rrcORL/p/CB6782z
kMf2gQbnA0dsgE+rrqkJaLJpNPCSqNgIE2wU8rs3wS+OxV15GnfonwY9O2vy63o+Gc/CeyEN
b4YUE+fxejBjMfNmwUwyLtkpO2SSiSfdAWS3Qucx+QJINksB8G5w1jT4bEAxkrhlt2x3OTFQ
JDmQkz/KkRAQYx/679H5b1Q0N720uvMvm6MnUVHnoewpZbtXvtQT/YgecPlnLI1eHnovGj2y
JKcnP3vKvcN3/p2mGCw4AFr4J5zTQizQXQytmEwsS5CUcVAzp1gIE2vEzCfa89g55DTVrArY
7BUobuzUfPGC0UAZ5TkWqu9upT9LePAMUsAVGGsHqKTH+8j0xx+TrfRAT7TkWFToMXbSDTvZ
DDvhiOl6WmwnO1j0ZDOwkXdUrFow9lqerG4uXvjM6rfAIowuHH525W7yi8e38YnhcmPVCT3D
1fAPdaCBftBAMnFNnxLvjHfhyhBaZHIgO5mURATsbpxMwOqIcStWEko7h5AWSk5SIYNiNVSJ
SdzYEkIhv6aakTlOq1rwA2vLxDBQoQy2AErPHCvdmRNjU0P70AyDB9R4gQrG+7y+OB/J8JqY
7NISNFMypQWTPYI/QMg2RwAedjpUFmaJdHIA+SzAEacEncIFAkQSCV3M5QNXDBv7xLMbrAGV
jE+W/k8lspvNwCAThoXqZadAKAUSOQPX7Yhe6boW3d97GpV/vh+ht7TjgaVnXt08+FqgsA3h
zjfuP49LjqHhm41N/WjRtU9QU29N36+y6lvKftw6s33/UPQ/LUsKkGRE8iBoJzHGqdp+QjAk
73DlUaTCmbvMV8zYTGNsMYEYVJZlwi0CErBlNKAxyw7PAq9UAalCuVAp1AtUcYUnPdwgPoyZ
dQDWiCxwrGQimKGYwlB6rgSBhhaE/uAgfjQ4OMzQA8OH8fxHpfj0cBn8ecHIXXJJLOuX6eIy
XMM041VMu9AuMRwGv+DVA5Ri4zjNbDZplrDqQKpDd5Q7Kh2UA2nEdPuZCkPfETHc8NCoYBDT
SAkY6jGbAFKE5Z2GUdCKj7P1VVOXpwxWXNh44X9UlwtQVNcZx+85957dc993l2WfLN6F3QWj
KG9cxZk7UTG+AtUqoOxIa0yaqAmE6ERbI2kiPmISYzpEp6bVcdpgWlsNASm2jWU61Zg0zrSO
j2ljbceaaMeOozZNBS79zt0NpbCH851zd9l7z/f6/X+PDgV7vjOn4wX+7kho4NxTV9kJQQci
S9kJoe1WGV9Qk6LizCKpylUtzZca+S7+Eu/eJF3hr0h8Mdkj7CbvCrcokQRUJVwUmLK5Zone
WCVvsj9QWnuVlJft9sKaZmeBzVFnPt3r9bP9q9bsEHxTIjGbiqHQbIgAURKpRHhBMInkIwRW
4BQXQIJLkjiCBYTdMuWoxGMZFNoAnmnpgOmHyHFymlwjAllI2Z5c6kYmtP/jbh7EYJcly2a2
OPQ4LAB81Q4E236bhWctc11tLRuQEYwDNAYCBEhAAMNNjVpaC30/CH0/An3/F5wwdnlGs1P2
nZ85LU2WRyyAJ5kaSglsFERSoCKu9vvB9Kdc7EFlb4oW+FKC5UuxB+9LgJmbmiBom1nKoPZn
01x7eooTPiiG4OX2dA/hy8g9egB/d4wb/eIORNFkfGn0ZyP78Y1btpD1nvCQo0srLAVhiGzC
UZPREX7H0tyYz5Yn14SWcCOdqYqsIrGaBN/yB0CTe8fgjfs5zqXD/zPQRmsbh3XqwxEqbFK6
lLMKLyoLlAU6P1lIqFO1Jn6VsEl9XtuhUhkTmlKrtXq8iJ/rtugS9WFN2o8P8N3ubtrDv+N2
ebGuaaUEg2MxVVS1lFAwqbJUX4oswDxKRUmWVVXTDI6KuNXb6cXeQdzDqajsPWLSAVRmSYoo
mZayTUbyIF4BPCrDFTwAcCiCnDH1NgMZA3jFSZO0kk7CkwHc0+th+RpisjZdG4RHd/gP7PD4
4noaaBAiwJjwGwZGZNGwY6tDhTBBcv0P/37FKWPDHB27CHx80aG/RccVuFbshIg69uUJTWK7
EB1seaE/ltKmxlLqAJg1Ka28xjH7SmC3JBsHzcCP4H2ntSJ/oLoGxaB+oELk2Y/iaFWpP1SF
ViNyyl7xc7uJDA7ffeORhu/zIw/qhI+Gq4RrwyaLhYOQyZOcrnXrhFdmBawKChhljO2mkEgU
u3meigLGopsKvOlykbQpI1NukFvlNrlTJjKFduaUPgU+me1rzRmV4tS79vvjBc/LpB9wsjAt
c0CIZcP71KpLQRk43V+XolZ5xixPuSFFGHf1h8Asz5hst9AxLbkw5dZ8MHLY+n5/DpjRjBkF
M5eZX54Yz5ls9jmNphlCGLFiizwHz/B48MyIDcfzorANjqZzuBPoaQ301U/JBU7jItw2qzWs
I5/h80UCkYggGIJPDsgR4WigX/udxgcCwQg2o5anPqc+YIWbSJPYaCz3rM5ZGVgdXBFujLwS
OICNUD7Pe/NlMTdpAhSEO6MoqifZWYXyJqJimrGi020ZWQMjAijmGFysXGDY5HTBGgNUHOep
xICK3Bq0E1V/hOp+8r7d/8F5e7DnLIpe+hOKbL75xif2JXwObUBvD9k/+vNf7EN9Z9HKX9v/
ts+jShTpRfKb9t+5DCcKo+B/lQtyjVbVWs86H15kLPKtMlb5BFnJhxTkAsEMwXiTNGyGEbzC
QTVbI0IT5UJ7+gt2+1+hk9PasvogkA9Yi2MxD9jj1Icn71uyfl/zP+0P7Z3o27/8QXpx2cv2
LjKoedf2bzhlj47+lEd7trW8lKvCnR6GSAVpAPdZgBZbulfWkLc6b+Wkx+mGSYJ3YOxvvd5w
Jcx3eguKKj1sHS2qNLKznp3h+uXeaDJzHd5vZGd23eoAI6EtzFtoLpNb8jbkPSs+r23Wt0s7
9bfUo/qA/rn2mW5oimJ6dJ/Ho3t0RfRGcCzsl1xej6EqJCiK/kA4lB8IcLEC58yCQV3XaH5S
O+hKm/G2eGecjxcEs2dXyPrLV/gHvg9dDzLuZtUke4SwDXILhBYC5bBDmzaFQIthhzreB7g0
6ycStfSUbsz0eGey+EbtThnRIE3CoZQHEskLQ7PyUgY0FaNgEozxzGieIN8A0HMK+WkYvFPo
eIq5qjB2GO/+7cdbzv1xSfHyxWP3h5Y/3VgSW/RXdHh796NvHbFLyWD92c0HL0YT8Uc32u2o
7OU9M2T36Ea+ombz/G91sSrTMvaZ8A/g1FLOtg6u4dcIHfxzgpAoquJTeXP4Be7F0XmT5sbr
ipbxze6WaGPxrhytWE3GcZwvSlTrlYVzE/OmrzRXFC5PrJefUtdpj/vWBjfLW9Qt+lZjY7wj
0cXvlnepu/VXje3xlxL71G69Ozc/EddUmcRA9USo2yXw2IUS8QLYAziPlLwOUXzbz5UYyEQN
qBW1ob3IBRx13EqU5Of7eZJfIkaS4YVikpuMJofLY0kvSnq/7uRs2TgoX79t/L/CM0bT12Hc
94DTwGceVvG8TPVx6XbI6JyafFxRntU98aJksqqyuroCjj+r/XJ9Ab8QcLwBJBZPtpxUV5/d
+sy7yxpaZtnrv/bkEy/c/d6R/3SRQf3Y0eOHUzPQlabOLV3Db5+x7x1Al4ynX218uGPuvCcK
A9+YUnNk7TO/eezJj1/UXnntxVX1FRXrimf1bdp4vuO5m/AMpZD3g5BNbq7eUgnOh+MBieIi
gjiAO3odGEDopMtEeDqPeLD7UAZx4SrtP5DJeRa6xuj19A0Wspm8LysFtVLF9ArOsaPCbjtC
1GPHHtxjUXAYqirjah/XbklJvUlooh9Swc9ahx9aR6Uwi9YJC+km/cfkc92tcNgzgE9ZeS7R
l8Rp049Mf4Mft/rb/J1+3q86moV9VoTPSulc1nPAJ1PSTLwA5GYKqVOCIEsQwG2mgDqc6yCv
R2gdeswevvCJ/aBtaP6xrRf7yeDIiU/tkSOvIfUmXz/y3gd93xxCPnbvIlSfOrh3ifuX9ch0
gh7iivmENF0pVVqVXXSXuFc5rdxRZFNpULAA8gDUp2hS4gOdwMHJYeLDmIgIk5umBLSylqK1
mLK7l4tTDRR10r0U1ghZKraKU6sxeh3/EGPMdjwmaSD/ZbtcgKI6rzh+v/vcu3vf+7h3lwuX
x7LArgrKomAwXBMBCaKoNT6STTCVCBgfYLR2ko6mqY8EE+10SDNxEk1j0tRQUVFDEztaw9gm
xtGxiS1O1UwCmjZSbUvsqN2l57ugpjMFvscuO3fgnP/5n98hi4BQtgO2XmcYoJQt3Z6Gd0co
pbU/0RrDy1AGMdaXh4KDRkU5ZhEMpsAicKAREvEBbRwgZAjbPw7wGsIHwFrP8N9LnS8MJfnw
sYkOlBDDxxxuTQBmJLJQ8QhjFCNyavIPZ9GPxlnZY9HWE8nj0Dv/tGHVunV0wa0qXB0Ewa3F
Po222tMKiIhaoEWMMmKiWqZNNGqIarVGqzYWEPPVBdp8Q3nV9apMUjQgHstBrNweQeBFSZYF
n1fT/AHdMPw9w+XdDGFk4lPQVHzai/xAHUD4JKCHDyHCYFyuDL/h8/sNTeD5DL8GV00VZDlT
UX2Komq84DL8jKwqoCvGLzCUocgwLrlcJPi0oWmqSrhCuh5SpvJoNpFJCLD7YdkEg2YfzsxE
CAWDPah9/6hnh4J1SSDCZCiYNGZWNk67fNe57xAhtm0of/XOAu6p+y4f/u8BTrxZUnp7YSvv
vXP77ga5kSE3Kk6h5jZ6hm+MJCwX3ozeS9goc0rwTrdgM3apk8M2nEDvSAK9GhzeYgDFSB7L
IfRG6pnfXwqHSt1I/9vZWTnm2MsfpVZ8mDqZx+m+1MdQEhU/7/gmTF1MhlJX/9V+kNoLmJTY
mtlYffstXBnsaGUIKH4YxkCKvg9GuSvdmo5Htiu2BBc6CBuFNx73X8OZ8v5sV8GFzodNi9AF
rqi7UKKbUBPb5LnI0gxNUayL41mWZyk+0+3xud0elmJ5KpNEUEuIFTwsAtNCnh4yaPNuN0+R
YGFSD2nYvMDPsd0b3KS7Bx2yRY9HyCSoObPIbU5FHTqAsI8Zh0XpeBauotgN7GRg3SPHZexk
APdD5epICjePi7mghhicKXzZLEFKFNhq9+kQahNCfdAl8AL9wfAQQQ0PIaeWsOUjpzvzzrQH
C2bZi/uDuPEuvNvAs9R7laWS9yVPXkVZ9ZUPPIbML5Pvk8upulTVs8+u3o66/tOd/BmOd3uq
mTQc5y61LZqKIVJh2BjBafD/c+xemsl1jLrT9XrTHTIbKnf8Gc9vjkV7YYDLUYv97eilvr5U
Mze742ZfB352XqoZHXSeHbdNmolxrEKRMQJpLMMgci9N5XJEJ79jETx46P88F2WVAFWXZKGD
qdV9feilVHMHm9cB7PbQ8Ne0Sd9P5BOTULr9Mi/y0aAYihaI0SjMgP5JaZOjNdGEmIi2iM3R
hqIXxU0FrwV2hH4l+t8J7sk/HPwwvzd4Ov+s/0K+a1oAWbplxMZE42V02ZgaevqYh10LY0+6
mmNrhc3Cx8JN8WZMnRSXEK0UhuP6hCyf8XjBygKywCyUKqRt0k5pWGJ2Sl3SNYmSJJPSe8g9
dsDo8JkmR1TmuSeYlKdgsbKYyM0K95CP2EqeTUSUSGakKNIVYSLjy7BrWxk58aKyY2XkrjJU
puca2YXho+xplrTYCpZkx5dC3FsBCWD4id1IDEKsBgZwN+qvGEz2gxkUwm9b4XTwQB3lA4TH
uVzc9x0qmOR8l8TzMBdwefeTDiYE/H5fQM+JUCwnAVHjNgYfosqX/Kal60j16ukly84vRcWV
W9b/MH2fseLMC1v21Cu8nn3E1J/oXfnohOXNTb+IpD8/r+q9jTOfm+mTxFA4171i7JSFrUZr
e629+KFx667f3jilFF3IN5X8usLpDY/MmvIDyOAmyCCeExUinThndyJGkMNMCVPJMBXWPou0
rGyz2HzAXGVtt9jJ3vJAeWhGYEYo4UqIC+RE4LFQi+spsUleEVgROmb1Cef188EvvVf1q8Gv
0r+whq1gJlMoF/qKmArZZmbI9cyTzPn0b+lbiqD4JZoliTQTnMrtNyWPET7jQYrHhvFzg4f2
PA2DHFFM5ZLkMQQEtwvtQ9cRbaEKNAtRKJhRPWnErlvbyuuU5BBms1YHDOBHxfEfKdPWNqI1
C0pCBRiDSUUhcrLzKGCxYmdYgQSgsb882Lb/ia5WO/XP3x5ZRsbn/XRt59tr1nYyHyS/3TZr
2yerU9dS515Hrxyd137q5JkTp6Ca6oe/pgZB9SHilF3NC8gyH/Q+qM/1ztUbvA36DnIH9Zq4
W9kdElxi0N1CNlMtzBphlbhBfEc4xB92HxKEgLBJ+IqkpOzH5ZXyepmSERZrTRF0pXqigVhF
bCd2EV8Q1wFPZNkDSKeZHs4waY8pIzksZafBXxH2xCwwPOhfNaY/fJpDFlfBkdz4tHiv4w+t
g7C11c7NqXWaCMJNZLBtaLDN4VnQqlpWqADUJvrvQCzSsUhhBtUwut4lVxwsqnx/+rW951P/
bvvrC7/+i9UVXL9oy57dP2l5GW3U3z+N0pG7E5HPdb2Ztuypj/547viPQVlVEKVLoCzVUdZ7
bpIWc8W4OE1kSnwl5nzye+45vrnmUnIJ08h/39dgHrM+Yz73XggOeAd81/RvggOOggKWFQth
2dWGsAa5cWRYHBeYTJaItWSlWOWrMee7HxaXigPslcAtNCQpyE9JHkUGZXk4lQBpUR6jGBG5
qpyrKGdUpKi22qBuUGn1aS18lDvNXeKGORrHbhZHccGMeP2osOoGQVLlCm4f/Q5x4nVPWrio
s0pwUUNVjwQMZIZ896RFlTb2rv98Tctnzze8UtidzOxcs/btd59Z9+amN7befmsnol6cPZWU
blWR2qef/O7E+U97IWa1UI0ZoCw/xOyivcQiTD85j0owCX6ep5FaxqzkGz0uhVCQQuZpfcwt
340QN16bHBxvTtXqQlPN2dqjwTnmYm15aLG5jl3nv0HeMBQigGRR1+sDGLGpgClvV3YppKLQ
aaabI7DweNThBXHptuhwd140vk9EYsiCV925kTg+7XTsjBayAsVKmLPD0fh3QjZai7G6ZP9M
5b9sV3lwE9cZf2/37dtLx0pa7UqWjSTktYF1UrCFwR43FgGbDFBzlmJAheEqlzOGgDkSU1Ma
TCYk4zJlIGlSm4ZSkk6LEW4HKFPUyYQ/Ejo2TdNpoVwTJ4VQJ542dXMgu99b4ZSZdsazn3a9
q9X73u/7HVtAd7fYjkvP9TtAA6naUoMZJ7Le4TTr3tZRsGmoohz5dDHuWHccL3F4kf/2+bKP
z90d/gTrf30Pe/D9O0rm2dUHc1e5+a6pi5975nW82HytB0eBC1x43PCN4c+12Knz6/Hh/dPX
n2CKF0CIa4NkaqIzqTG6jL3hr4UnhlPh5vCPXK+4X3dLBe5x7u5wNkzCbHXjCqLJIsnNu7yF
Cg5yth4gPEVKp471kUCKmBZBPHeI+QtoyaSpSVZTSmE02QHvei0UvoDPozgawgpitiNt28xm
aDVg3AfSedsBWjoAXnHSxOm7Urrmo7JIJZAUTfZHkI96I9jG9oS9e7ENwNrK1LZicnIKy5Aw
h2wMgxUg7ZnOzkDBvpY5yyNTyxfM6O3lXz64ZVOy/lv+V5X6lasO3l8HGHp8eD7/EWBoDJqA
BlMrVVXQy1RLn6PW6VQuCheVqSV6WaJKrdRnqfX6YnGJul79QvlX0PNooqz0scRjpXNKO8q6
ysTKeOX42rJ6tT5eN35RfNH4DeLq+OrxK8vayq6W3ol/nPik1GcaNHiWO90zrjAgOgymxSCA
Mv5qQ1nUhxi6WlPThMJCr1I3ttClGMEKq0KxQqE+E2tmylxptpnE3ObFFhobLb7o7fXe9I54
SdRb650LrBi2y7bF2UDaDc5AgvA6M5nrHwJ7MsBUN93PqpMGtwCLmaZh5rWzFNDF5SfTBPei
O/obeGg8151Sy6dvaz0Q8uCW7muDT1554cLuE2uvdf32o5dOtD5z8he7d55cUjDfKl+zdEr3
87jm+lGMDx5tu7/xs96dP+cnXMlevPzmpTdh99sR4u8Az+no9DlkACzcQTNpkcl8HX/eTfiz
I7dSxWY4aUo+l0/nBYy8hYKoq4rLklMVlckRGWdlLDcYDFFmsjLZbQwaXLPRZXQbIwYxON1y
UJcKws2D8D7IMH2gDQQ1BGfOyzO9DehilgSaZLOkmNdAZnEduHmoR7Q81BXBbgmAhgBp9l5k
p7FdkVdGwwj6Ej6nKzToa+/Zk2355eye7ZvmvVADMviPQ+njr+RWcMfan174YmvuN4CxAzBi
8C/Ewxa3ptJz5Q65S+6Ws/JNeVAWkRyVm+U2ufPBpVvyiKxEZdAqkXA8+P49kC4EShQqWgIi
naSLdJMsuUVolgwSDpEY6YMzQhqk0RVuhRWyOaodwKO5i2351i2ByRVBHlZxoKenh9zr7f0y
SEq+vMoYAH4j/xn8RhVfThWIdDFdKvNe9z+FIcp/k9+hcH4aCziBZfCMv5QFmMEeqH7BuRB3
LqS+D1cogdBCp8gzwYHTR5Qlyg5+u3KVf5+KJyhO0BLRkqroVLnWPdfdSBrpErFRbiW7hJfk
S/QP5E+0n94V/00/l4J+RRF4nnCUihBP4QQyqiVSXRQpT4glKLogQNqBEwlDDwQqSpKqIoWc
xd6MMFaCkkrEHI0v6AB6Vi3EWeCNEK5Fc2FPwi737fjMdQ+GBVwRkA+w8VCazc1XIRYkzKxq
Fx61CQs8AiQfD3wQNalGquGdI/SVhRtFLiuqkqWiohoK6SZTVAXlj5mYU07Hq5yM0wgaCFyO
bBueOIfoSDYTrwLEZzMGKzcyWhXNF+fM5ZTTav5huxFgyB5M+a8TLOkGvE3Xa5wDPDWUCbGH
/346kr8dpxsdQ8cgC5EKUq4Im47fuDu8EV+8MXzsuxBoL+Du4ZbcGi66e3gZIGAfwGCKg9KD
55AAxD1lalJgBJ6cnK8TJ+XrWMupKQsm1ytEhU7hpkDmwmFQ4KNCs9AmjAgEJk/h+Pwwsm9y
hrIAWLoT4SxYNe6hySRf4da288h1CGqrsxK2gn2Qxr6oz7MHLQG2TqBL55A88ufUNNUN7NFP
+uXb5gcx4T1hKMaZUiwhhyIxmecTYwppsFBVwTbTREFYU/os3GF1WZxlmgUeq8OHfWdx+lch
qyOCI/ApFUZcRcLCfQgzT8lFEUMLj8LF1lm880x85ii7go/O9YOID3yazjXUrZ3xIVhnplsw
dA6UADZs9EYpxaUHSnSXL4L97uAopTBlZ6sLVjp2iB3yvOII2MMMc6z8xMaWI9E9b//4jTOJ
5Y81/7BnyZo5e6tJyeGGFauWnD/161wp9+rmFdWHj+eOcJmdO+e9/IPcXx5w7YfQLQNdTgUE
nga4k9pZ7X3+b4FBfihACZvZSdDAXRo+qvWFboVGQiQm6R7d8APpYmq4FbfH5SlWHeZVMfyp
DSFnIxnzhgZDXHOoK9QdyoZIiOcqgsYD8vX/D/mao8T7aU0+DQL1woQx9q0d+C/3GtQnK5Ii
KjzVSnzUE8Fexf+gYRP2MtGyHUwHKx/EwIca1v6T7ddXHpunKT0TNj3x1M9IyZFTdc3fKG/N
PcXtf7Jp2qHLuQuAuhngGUuhJ24URr9Lpf2iEnbNpE9Ii2mj9B26QZKSWrW/2pgcqtNm+2cb
daHlwnJ5gZb2p40FoSahSV6jNfmbjDWhHTgoU8G9jF8kLFKWuTbza4W1ymaXYhYS0QeQ04tF
1opAsZWcKGIkamIM7N+kmwxocD3MDCJ89hSjFNzCgMahSQXMHEKr7AEwhumhdNp2UtoAzANz
0Gz85YXCQnmVsEomMOMBbQp0AgUdvUYP6/WM48+9dQ0bT997/ubwwLlM+/7MmWfbM1wAl77Y
Mnw79/t738NjsPvyO5evvPXO2/Dq9uENJA598YMT6k391KU9on1dm62R2lh3jIvGxrsSReXB
8qLHi5pjHTGp2qyOzDJnRRqlZa7l5vLIRmmTa4PWZG6KZGPv6tdD1wveHdOv94+5FRuJGQli
a3ZwMqnW6sksban2gXqvaFhTfR5w1yzQUgMCLfKEi/sUrCkpZaXSphBlGw5UcBV+C6H/G2mj
EGnxf+gu99gojjuOz8zt3e7O7t4+uZfP9vl8vjt8Djj22cY84oUQmeCAZRxoDDZBLZjaoYAN
5WkUo0AMhEACqgA1FQkgHkpabGyDMaGglqASFGFV0BT+AamoQSiuqspBaql9/c0dWFRqz7ez
s+ubvZuZ73zn+/lfTJuGWr3yRaQ1ny8yzwSLsGAT0x0vDFXXiakHfrprqPXn97cu3j9JP7lh
0+en1q/rGWtxXt5TV7c3dfj42NMP3pg6+tRx4ptrN+/c/PpbkPZOSMzXYbx09J49bbKJNQ7n
c0nuVa6ea+bWcy5RF0RBVExdVJBDwFK6o4iK8Y8ELIRDJjZJWP+/WcWovjaeVYA5R9qBqdLd
gpySNpZKpN3ocm+7xjrZjpue20gm/fKwGnYee6WlasnSV2bNmrbUyuGin7XNmXoqVl21rH30
Ntvvq4A3e+D3F+O79lYubIWninPF2ZFF4RXhDnGfuCNy0vy86HcORfQGfN7imqI/eZ1ZZCEh
WgmmvkahUWykjVKj3Ki0Cq1iK22VWuVWpS/aF1Nj0UgsMrE8spg2SMujy+Pr89dHOiMH6Sfy
gfihol8Un6Bn5OOxE/He6FdRTzZscbaRU7lYiBXIlAuEohM4aVJ2gMXjYK6/yl/rf9t/1n/L
71L9uf41/vt+Lte/30/8l8hC4D7EUrSGbUw0PAQ5AGuYYLbjWJ4kO9s5bj2J8aTG7FXZJDs4
geeCk6TcAA5E/LbpS/oHyJJzfKQQPnkhWDlUiAsDJaxVFJhuWcnVElJV0llCSjSMcQSFImr4
/nh8ePk5xrXNg5w93D4/bWuM5EYSw+3pRdsGMJcAv2pPS7P9IUwbvGH2vBmzs2Mv5eQDbkR1
zdBMzeEKK6EsJMb5LOx8CYocCy7z3PlZKJyvyMJEmoXjMZG6ElwWytWymS0mWEzJFCweJAoT
27ezrNrGwl6TWeHJqDwWjU2CdF9ekVkFoJK0ZVos/ntzSMY+olXn1N1bOzaVFRy8fqR25pTC
j+u3XV6sd8vrWjpaPZ7JWTuuHFrUcn3brbt4RvCd9hWzZ+T7Ckpe3z6/enM8NzFn60rfgsYF
FfnBbJNGSmd2NC4++qMvmNIiqX+QQucRYMvOi4jC3ORHWVy8as+ESqcfcq6sUOxAHk1MqBTM
wCGpWhiFsWIUyDjFC6+Jry3j1/Kd/Ec8h8BFP+W7+av8EO/iB0kr8uHynubMYgEPGGbZ/uEI
450qqDIf0EtLtRssUCQSBV7Wz2gZ40W9QmeMaLEhIlrgjek/XlW0Y0dvf7+ZiOd8dlR7ZcUx
8pO9mF819uHe0YPzigKsL+/BqnnARZEPXb6IAtAHETIQCZmepMo204mGlUyYOCKYHhmbHgkW
vA7dQaWeAp83vYl68VUv9s4PpJc920QDfw+QtYFPA92BVIALAOWMGwIQgBgSh4AHOHG+fxxe
hp/vn+AMrJdV0zOOkJZUgNPciqoQSMMuwSnALsrJWUgR9CzE9tDCwu3giaCTvLL0QMRgKAD2
vGmZlLO6o6rjztLjtZrUJ+mr6+r2Tev7pG/Oz2rL1pEDo70fvlxdV79/F6kEZMAowEgOxoLi
pRfKANTCeiVlq1nRK0UIEEmBFWQg9bgXzvjZGT7xZ1vMyUuiOBRw9cgWIU8iDxRwdc/uj09K
ohAUqjwRxcUorURldA6qpovwItIgvCU242bSIrSIm9BGvJFsFjaJG2kX7iLvO3bzu4Q94q/Q
YfFj+gU6Ri+jC3wPvYG+ovfQHfo9+gt9ikZoEUVO6kMeGkdRWkFrEWR3p214kk4bohAFjCgQ
qSWKFDkIEAOyMIYGFKxbEAjBLp6KDoSdk2UshwXbtoHciDiAs/ptCL7ECTVbDBEbh6XHf2RT
NhzwjzaNNgV8ww+bmHEz736OF3qaLbq2XesCsuhKuzlE97amxAsv1JSHS03IhxUm5PjfjK36
7cOCXF/i+4tjq7no6I6Va97cQHZlGM6FkPMCzIhBemxNtXAhN5GSufoSfZ/u0Jk+xdy8pBbM
zvCb/evcSJJzyaLpyhL9hpNDnEsSJbdgaMh0WHxQyJKyIZ4U8IVCwp1EZfxUYZp7tqPaZfPz
hBrpVbVan2ssURcY7/DLhZXGZtcWfr1w0TWonjd+cD0V45IeR3El5o6rMWOyNQVVGBuF94XD
jkPyKXyanJZOyv3ovGvQ/QfgvrviI+6R+p0x4vqXGDQcTidImHeKlAqSLFNN12F91fQ6kREa
SL1uN1PVHfq9zgshXjeMhJMHGOTdVJYLFLelKG5BV9UEFSxojpzjs4gI5g1OUHXZrVCdcg5D
kWVB4Hk2rYaqut2IWk80BS9T1iqdikMZwKdsGqqleA19lxI6QBbaYq2O1+jv6kRnV5LmxMvS
xOOAiT/Vj5+YT5rT24J/3khTkw9sH95MAE2+v47Puvbsz8gwAlOEni675r0ohv8+gRK63ICe
bm06O1idHTXdufVv9SkhOUS+TD1AGA53aqgPFashYyD1AE959mqo6U7WA3QKqaEevhinb+TV
13SX1i1O333Qw4cydw24m5O+Cw86r4bYs4WB1NA5vpg98RyaQgYz3zT+8PF23nQ7PfWgl4a4
EGL/AONN0647dfu8UYmK4BhI3e4xGaY2ZBgPtUFOYyJPa9z0MqHnO2IOXDN2afBMFVd65uLR
shnnz471XToz8VsQ/S8f6l+T1aOHb35Dmp/eIx39/74F6s8bq3P8DdQfwF29ahCrzItOBCvj
1iL1LHXYiq0SNRQvTmqs4GXR8Cg+IybF5JhSLpcrZe4juhQ34uYcT4PRYDZMaDFazJYJm10b
lM36FmvLhJ3KHn2vsdfcbR2mp6UvtUv6oPWYfmf9oIxq/7RSwRyQkKyBHsE5/JZpFhjUggtV
BsEVSNSSJGoahixLLkfQr6KgFiSTg1eCJDhAqvpV0zZsa4C8aUtVhm2Qt40rBjEG8Kz/sF82
IVFFURz/z5s39tTXzPMLR0dzGsaPHNPxKx0bUofR/CInLc1KQitFnKIEDcWIoGWLaKUt27VJ
KJOyVhIREREV0aZaKOFGuIvaGDqdO+9lVqi1CYJ7Lr93/+++M2e49xzuu2/GZnKhzhHHHyXa
nPE1NU7Vq7aq5pAaUSWVPO4W2WiyUvW0wzlOxUdfuSvn6VhCGw7JJbv2eSFNW6CjcbpdW4oq
2PnLkVcg332Ui1RJFioyKwlQPVJZ+f0KVZaVMmqnjD6EGllEfGTRtC6fyZEPMxW+OFeFz0qb
+L0UX4IrheeUJzWaUo+pOymXv1cqePuxhdHplN49l5L3FvgbUhNyLPGrZ+bee1xZnvnp1XCt
2zveUbbaf0vLczsGbZly3srk8OXxEWnw69OpQFc7DAv/jin5D7lKvKLNwLqO2xtDdQzLqc2J
eQxsewYoi0DsSyDuKPECUN3ErM72esAmE4eABA1IzAGSqE+a1UkZAVIVYhywVwJpvYCjTSdj
Tidzh8HIz2SRv5PWYOd1wPUEcFPc7DggZwzIPQvkJerk0/zz79NR4BNQsAwU0lhRQMcrASUU
o5RilQWB8rdA5RudqkcCgUAgEAgEAoFAIBAIBALB/wMkmMAtGWbemdKJGGxpZljWtE1L4L+P
miPDGHRn5+Tm7cr3YHdhkbe4pBTleyoqfVXwYx9q6Hmwrn5/Q2NTcwsOtIYOtrXjcEfnka6j
OL71f/8TkzFBVyc1GWBO5mKFrJj5WAMLsU7WxY6xbjbAzrELbDQSMTwKyKOS1bIm1mZ49LBB
NsQ9bPObNSMHm5t5Sw8FfUYkM1S6moyZqNR0HUPKziPJsTRih9vQEqyUGV2babzJ0DLpXkPH
kB4LhILBYKOndmigJ7yRRgAhBKOtER7UYggD6EEYbTiNfgyT6qGxjbz+dpxmZtHoUo2TVJQS
NBSRL2SV8mKme5qE6Ro9UWSeSsj43qNPSqSFWbNfl7OaDDWU2VGFh3mutJgnjFWVJm8sPXh9
5YTN/0VxKFHvm/O5+by/0/zx3fLUSr9WpbTQLV/naORvAgwAIXbI2QplbmRzdHJlYW0NZW5k
b2JqDTE1NiAwIG9iag08PCANL1R5cGUgL0ZvbnREZXNjcmlwdG9yIA0vQXNjZW50IDkwNSAN
L0NhcEhlaWdodCAwIA0vRGVzY2VudCAtMjExIA0vRmxhZ3MgNCANL0ZvbnRCQm94IFsgLTY2
NSAtMzI1IDIwMjggMTAzNyBdIA0vRm9udE5hbWUgL0JQRERESStBcmlhbCANL0l0YWxpY0Fu
Z2xlIDAgDS9TdGVtViAwIA0vRm9udEZpbGUyIDE1NSAwIFIgDT4+IA1lbmRvYmoNMTU3IDAg
b2JqDTw8IC9MZW5ndGggMTgxNiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpI
iYRXWXPTSBB+96/op2W0FQlpdO/TBhIob2UJFZviAXhQLDkR2JJLkhf2329fko8Etjg009PT
13x9+NVy9nK5tBDAcj3LvTwBH//wIvc9P/ITSPPESxM/hOV29vJ1H8OqZyYf+tXs5dtFAA/9
zEVm38awXM1oFePq++yT+dtxrfVi895xEy8wNwtwaZUZuLlSGiyvF0t4fbm4XgA4X5Z/zXxw
UzyxPgq5YnFohQq2kQheXKLoIPcis3BIwYd3b53UCw3M313NL2Fx+2b58fLuGm7fX99dLue3
7xbwCRbzxe0X0YFOR+J0EKGb7I6sbBx5ljSmcUoBYL/ZPV/cEwOu5ovXN5eOJRPmZEvoJeb6
joVfL2cB1DATUQFKir0EshTcwIsi6KrZevZq+URzGAVPNfuk04Cz/Eo2J798qCjykkyuyQ2f
NAZxklAgJyHquBxGER+yg0E4hpkCTl5+6CuoG8eNvNysHRfdMK3sum0xCKFWirLBThnwXUJT
9ZXSlXsSB0p4lG3dQykrFbdyfDzdy2bruKGXmnNZownwrxNYPNer+2MLQInf8Y0y5B3Vd3X/
zZsAdwiTPz3ycQw1TByljDgmwDMaHULypROmnmXMk+lCRGAKJuUQhHpL/sTmzZKBk5uPenx3
zccIW/7K7s4JDtLHGwRpPr2AuncoONC0A3ROjICsmCDkXdvIor7fCB3WrbBBwXuMSIApiTGM
KTOfCQm5mk5eh5qDW1QcEQBQSmSaoeJdh1aFZicfIQ2kIDHF8aZuG2jXUAqfHK0HEQitUEHI
aJ+PHqN9CVkvPHshrnjzKBvYqooTUzw2Dz4KDcqWAyUXN3xWHLmxheHxxFDcq594VW7tt9Wx
YQOMDBy65e+aTcGUTRqwFUMxNdudfDcV45fey6fIF43QS/lA9eNRVsVevr3y1/+gbVgsTOUB
AYIqqrJiHuHfr2cXJtGaMpE50TwaNHLrV80FFS28G+WFfvSm0kVzzAaSb9Fo1yhrJBfM1Zzo
7c8Vj+YX3WjZSYTtGGAqXBTgUspBRe8SUMGi96/pHUNSxdXqZPeg9eNGvleYuqj3PdnB8O11
Aauir3oPJv3nVQJJPysXdkqcIBcz5w1mINZPyoG6YYARthBWDWEJ7lFZCXhYdsV6cOtqWLvb
3aZ3N+XO9RNv+DF48FEa6SOZjIjYVBxaqgiU5VhDHgtESYb41P3Q1Sj1+ewWrLpjeSMjhxa+
VdXuzLpitdp3xVAhoErY79yhdUvcXqhyS8ooWg3l2MO+6AqsCxXlFHpGznkwXwOXmsC0+yme
pkeuvt1WqK55eBoVFtA/tvtNCfcVrNquq1YDRalDM8iE8gKw15RYA+oNoPF8f3qRMMqjQ5/L
jxp5waCJjX46LLaI4b6f5gQdjvAduVXjNsSsT7BFxnnohQllN/VpPKOJ6DCvfCKnmv2ffbF1
eDzoCZfW7JsHb9V637ppWGCBAcqzNAcEyJwmZLWdZoVD2z7t/RZ7fmqfsYWnM/E2mupQKi4z
eHLN/ti8oGzDWrgBeoSa+3yqRSAlgMVGpoDY6FlL63ECSHkCiDml+On5e8/XWD6shJ9eTC5U
FGyj3ddFLMQhjkmEydxmP2/CCljxapo1fQXsB87pAKsqPl4ra9bHSRJzYvjodCcliEaOCvTO
KTubx6317D6MV0XSvZAlNlJwiFuFjfHJJD5IUTYoT5RW/fNW4NvvVBIOMoGOUscM7Yla/dQE
ssys6mKj9TMzoyHV9kxEz36MgkTPocZRiU0ObV+LLFaVFF+V2qU0+Jhnq4jF0Y76Os0mOTfW
2GyFjLCHayZvjq6u+H/utSk3bGvaphaqips3ZS2SVCyai14PojVVLXJXhMLtrjoiFsc6apqH
aH8y/I0F+1e4O6v0GqHwUN9Dre84qmXjiIKd9pHHmcy86B1+fj0uSyFXTO31fy0JPNNjRcAu
H0GGv3C4HiDUx4JwWgaC1HoJlZ0Y5+AoO/rpcOQMNgOb5fapS09/CchPHVna459yOf6UC9Ho
G6oZAc64tNEZBKNfbH82PoaHKB1mZpkJrSDETgjhuYyf0jI+LL2dNTS05iM6rJE78Lr14GYo
vbPR4DAbxGPTFciXU5oECIICFu2UPomgJFFE53TeVXArgN9pDnWF8tR6sxlzCTVj8/ts5HjB
2YQ/OeX6Z0fIZ0Pik+J8cyicMuWNuw24WpkT+A1SuID3XdWPJfhByjS9UsigoitdzYWWSwLm
iVTmUcp8/n/z6judwzwI/QsVjXkjsH5L7kTjDu6Ut9Dh9QJejTPng57I+Kh8GFdXZro4QRhj
+f/ZaPXM79RsetxALCUAphop7AA4pyEgfRqM/iAzMenywJVV5usijmMf/z0D2OMhQSc4UvJG
JoTiB4sP8edYKOLtJN6O4i2Kz4JwdAsz+r8BAPbf+D8KZW5kc3RyZWFtDWVuZG9iag0xNTgg
MCBvYmoNPDwgDS9UeXBlIC9FeHRHU3RhdGUgDS9TQSBmYWxzZSANL1NNIDAuMDIgDS9UUiAv
SWRlbnRpdHkgDT4+IA1lbmRvYmoNMSAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQg
MTM3IDAgUiANL1Jlc291cmNlcyAyIDAgUiANL0NvbnRlbnRzIDMgMCBSIA0vTWVkaWFCb3gg
WyAwIDAgNTk1IDg0MiBdIA0vQ3JvcEJveCBbIDAgMCA1OTUgODQyIF0gDS9Sb3RhdGUgMCAN
Pj4gDWVuZG9iag0yIDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQg
PDwgL1RUMiAxNDkgMCBSIC9UVDggMTI0IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDE1
OCAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczUgMTUzIDAgUiA+PiANPj4gDWVuZG9iag0z
IDAgb2JqDTw8IC9MZW5ndGggMzY1NCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFt
DQpIicRXy5LbyBG88yv6CDiCFPoJ4AiRmBHXI5I7wMyurdiTwuuwI3yxDv6T/V5nVTVIEGhy
HprRShEcPBpdXVWZVVkf+8WHvjdKq/73Rb2qgyrwny/qYlW4IqiyDqsyFFb1/1l8WH/z6us3
XlSob18XH247rf75bbHE4sJ41X9d0JXH1f8WX7LP+dKYlc8O+TKsdHbXqSVdVZm628Rnqm+7
Xq2bru2Uyn/rf1oUalnijSmwyYa3wynixsbJxl2DrXW9clmXk4GH3W1ermymtrvNtlHd/qb/
pblv1f7Q3jf9dr/r1BfVbbv9b4ONEp/Rvpt4dnc8ezTRNx9hoqBjY598Wa7K7AZnztQ63u36
dtd3vF/bL7T6l1pw0LQqfb0KldJFuXIK+yOc//3H4vfFx34SZF1jBUc5FMcoF3wUOkWm8v7f
CzpFWVmtlnqFnYeoWFqmV8ZbObBWFJOSgl2sQnbHAelyt6qxjcayrGv5Wc+/DwicpcXGaSxf
/fh/HDlbroJ2HgEZ3DIn98/XW4nG8MUS58fF8J2phwwWWgJiFOJBfnNckMgGLpvscNjmAZgB
ZJClTDXq0Kz/SqExHBqT8XdYL3fItgHQVLNTd/yAYlpR5HSl8eI9Q+SOlICzrj45a47OVuKs
zZeWiBVdBr8U8OvhZ5Nr/HbbtdowoEO2zT2WdoRjCzcf4+P2/m+D53/E3T7JivbuLq4VjNHX
CILObikItPKtHfeDOyf3R7kWjDBxCyP+u6PnyJHPNlwWDqrlu1/zJaW655s2XzpK/6bdqA1B
gZxBLaqzNX+0f5TV8ili8of6JNd3sveegyDf+RiEmmj2Nq4Hcbr/i2S6OmY6eurHnmr2VMNT
FNCO6pLNyCcnsIWb6oPqeeE9L2wo2dmOr7sDFmkKhrzrcactdngbR574V7KbVHyCKSP/p5Vv
eCv5PzYE1MJj/iPZwzgqjqPiTlHhmJQSE4OYyO2OF22JJlIVjzcNv7mLd3/nV/JsWMbb7fC+
fLPEX/xXHRHxJSsHP6+4QC8aAnEZo7Fl0jo4gp7ph3fnrqj9jer6s1ct/0a011mz/jQ22hL3
/TugpT4jgD1i4ktWnVV0zogEIvCZhtbW7IZncKbKqM5TLWulJcovQwGCodnIop+atXTH3Zqj
Kd5TA11qW79Hg9TFheKeQHc9dpxzEfN+Skc/AunwnHMZ3Z/wgkgh+eVLVLITR1ASQBLyvK7f
obY/GYsx00fZp0VIuytjCiX9H6mcl1LVhzdS1wO7Fvu4RY3jRMub+NXDCDXyAkRoZOFuEwVV
s2sohmVEhDyMYInfc93U3x0prSUM0OSVaHIRfUDHEBAfhWpd+cCFkiQq6hmqZQXtydKSL7RF
JQ+Qlp4qvBFpeWyZx6Du0MICYEFKoT20Z7dwi32kmz6HhyE25ImIraqVKSaWuJQjHfNzoVVa
kziXKUr65ktGwtsIA5c2cFIrkh4J04Z03XQzMb2ZmzbGidqemtZ1ENNbIMYWLBWWpJGAGZDf
ABuaGvzHePtARQGvscpAm2fbPT+oiXL6pFsmZ8VUE6bW5azrxFkhq0zqrIWv5KzUfTQlho8J
GHjmLmRKbmzyBBbRClXyBJ/nJ7AGKjkJIM+Jyvablr6a2HB2Vc4ycqxq30URogepAkpjqGui
hvYhXKOGweiWoEYZAVtY4sPxjHGGEGbcbwA7EP2+lYsk9EtMALOdLkK/LOern4R+GkxFkXDh
IvAxiHqTMHwGfO25858Dnw7kziFvqUQQ5E1FZTJCP3lKX0cwzE6ZgnwIsTJMTjmC/EvQjhCV
IWk8hfaijuxMG7+AdoQgpJD0BmifYN6saq+r52DeqgQEjph3NSBbzdgcQb//JccAWEn3D4yH
imcHCrklWBrN6hKR/xyHxSQx6mJVuYk5Cf5DqifQn9ThXMz8rmNdgmzXKMaGuvGaIWqlNhMw
azqeBxQ3eXEJkC72i/mxEnyF4JIaPD3Wq1oVyv/Mx8uMrWL3npp+QasaeMs0fVGrsqC4S581
RR0XO/ocWteoE/TcQ6aOeT11jmwJSJx+DlncdbKUdNY5WXBFev3VjIHKTBZ1J/1hbLY4sjOJ
E62lAJ19guNpLTBpPx8nWs3VOuB3k4eLBEGdMakjJAni6ojpSZxe0dDQSavpVpfpgUU6JAy/
jB72Ej2utzVrdawLs7Mm6VHEmjNJUW1iV9vImdqUKV8lwvKdLDnRBNWykp7i3FWaeJVo2BoZ
FfCFiqTiiCZ+3FN2HbJPw5WQwmSPTS8POBs6e4zv053EiWgdG7mMSDT9KnWkVyDS2Ll3Yvg+
YdhGQXa2GoC0PhKxz03JBQElwAFfmppXt81dBSXjeNDiR5fYIcVydpYE4kxVRHzO8nKlIBs0
4bmNt9QyZxA0AkG4XGtU1WeU6qBSmho5FHb5kmrRtBJEDB51bBuJfh/vm8h3CItLUgaytA4T
C1c0PoRglTjPywEID0hTpgynAFiYCNfx6nEn6GOZ2XH1R32EFRJTFI4994Xdlb5gRR7Pz5IC
oDfz1U+OjqYsEjbeC4ApLEIcWuOnWAzlgEVnBU0AYwkwYmDS1Euzg8pRRxFLCtwED97JCOSc
pxlsykVuBF623XAZhDTr5S+qI0HzhoVFNdzGRcMURLKDktbsNukqpmNBHNkfaYpdInuQ18Xs
kzGSfmW0RDyl4RJiKqdWs09pnV1NV4/kf7Y/qARcwEth2sxGk1IMNiqGiVORlZsN1WXUhTb3
zA5d8J/UXOmjRJrs9PYwjcD80PdGYfPfF6QlQ+m4XJYVGdwscIWKHYGpAcsSqNhTyDRWEqjo
QS9/1sR6EkV0s+U0QvGQJiXBU5NifcPzP+MfB5gUEgmQYqCc5F0QijDYIQxVDAOkHH9AYbCu
vtw1wGSVQNxJ4NMIMB84xXISdhqaV2aj0acCu5RE8sPUNzXk42S7f6DIexob0l2Amnk1tYf+
JqWUW50pJf39XW5YT9GwoZY5FIzDpjJ03CWqkwGDTep4sVvF7vmSMdeWc4cvN61jW5mFJ5Ya
Gp+ynx+46Omso+Hq0gAR4vA0M5yUSD4dVeFwd5vSRz5WqfNP3qk9RdCTQArBPEMgYSa5CnUL
fXc2yz4f6uNPn4b6zNCLoX5m762hPj3e90N9Hp4U4tyl8FD9YmF4OFB4pPFDNXBJJh9vSWlc
Rn01C9k11JchEeBrqI9TweSTd5oK7HwquDqZYixShxTovdQVW5WpMXBIdhRanzjQaSmjSZxU
k60kwo8Jw0GLKDlbTeGKHGjXkE0lWvAeA4fP7tM8qKWUTTZ5Gx5ghST0emiEB/bJKYVwbdLx
SRV8TAazaDILtIsB+jl3cOEBv2zckMbtSZy5tP2KVVjKfooBtUuH9jIDjnpvltK313tO4I+R
bFB5T9V8dx3+ZUgNoa+C/2irZ8B/vPrV8D/f5I3hfz00L4f/LD4p+HkvU8gF69QE4rSHvzRE
oRcQCqgXYCyr0QuKCzQIMrQ97xygwTyrz6TBNLVvTwP/3LGnjmOPUTc037hsHaee/o5vHxG8
svrhQ038x2mCSNBF5U6zjfXj2ebM7yD0Hz5B7bOB6mL80NCHZ+OejeNek1OZ/NjK3TgGPnvs
AB1XAjt/VgSQgBJenyJQJSKgy+h8XD11fvA9Eh9vdnsaYy2PsSG7AVFIt62bXh7wXGuzXYzG
Z4JC1vIXXdfkyxokuwW9qx8RGF0JaU8zrGYwG3NleEVhUwnyaoSIyUssRrV1J6FtxyWMlKvP
bvb38Lxg/2Ew40nKZZu8YKSkyq8joXe+/YnobKjQYuMux54em1F3RsUqM8W/8uCB+opZmR8I
vCHOS7huC/10B8VQcD3GlaGm/24xnm5fxROiFLsY4w1hVVN4NRnDcVPTjZcpb7ahZC2etwXy
b6UBt8lm5mXgG+/y/96rZbdtGAje+xU8FXYPgUhRonhUYrUuGsiJ5dRAP6zf29ldStSDsoO0
qi8WKNrkzL5mtrO4awFkB2AfyszY9wQwV283bK9xejJpgxulJ18IK+2P9sTG9Eoyk31XRp5P
orqiO3WFDJkfkMXGlkoqD+Kr5J3yMP0/mE/G5iL4JpcZAsc6iSv1J+WS2zSQ2ocSRGis0e9Q
sdin2lshLDxJ/IEuDcQxpyl0OaYbxCx0s9t9/wrJlpFyesKDR/upeUcVd/Q/acOLNRXqytnp
q4JK+yoEYHbX6Gu6jmWpxXXI4KAMfXQ4yaACBSuuyQ0eiJG+D+dM4G/1LSHxUMuSbLNfm3E/
aDEPq11zrvFNIhdHruhc50W5Lum4JA6HKbOp0I3ouOHp0LlR/cnDnpaH5Rkkw5ynqajugqgm
tjW+u9Shpkoc+i+bn8kWuhZZWKDlzXVtr+8KdWxYxD2LljuNxIzgoVVq6tQi7MaVnfiIwIOU
8rqMAs9OJa4Jtrbfd0/alUoUXLs3LO9Y1421XlBvz2EJwg4s/KKCsv278fbTbQ2499Jiud9s
TaApJeEzZsH6gQXTD36ub+bBkZGle9eHw7khGujailEAVoc+kvP1MauU+qwU7Qsjq9mTa8Xu
K6EkG1mCE1o7UsfxGCay8VxfF/+I1k2MfhwlrMoI5cLDiIY0AWbVw0x6mT7VZfnlhUJa7VqC
7ePbWAi8DrLsXwF4H8pcUF6+EAx/E8a5eeWbvUk4wn1prnvO1RHSbl8gooiCozmxMYYRmpLB
WLTe0rhQzLGOpYT7t/Ow2hjWIFup2UU+HPPhAh+wCfXj6XyRR6JGk+Bibixz44QbmFiUrgn9
rmRqOEEL2r8hF26I7NChwsg0eowrZ1z57pESzkne9W/UddK6juJHD0PBcbl5LjdjEPft4IyA
+SmwZTkacyeP5SFUWN01K8mrPYH7H5j4Y7P72dtcPv0BwEhxgwplbmRzdHJlYW0NZW5kb2Jq
DTQgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDEzNyAwIFIgDS9SZXNvdXJjZXMg
NSAwIFIgDS9Db250ZW50cyA2IDAgUiANL01lZGlhQm94IFsgMCAwIDU5NSA4NDIgXSANL0Ny
b3BCb3ggWyAwIDAgNTk1IDg0MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNNSAwIG9iag08
PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9GMiAxMjUgMCBSIC9UVDIg
MTQ5IDAgUiAvVFQ0IDE1MiAwIFIgL1RUOCAxMjQgMCBSIC9UVDEwIDEyNiAwIFIgDS9UVDEy
IDEyNyAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSAxNTggMCBSID4+IA0vQ29sb3JTcGFj
ZSA8PCAvQ3M1IDE1MyAwIFIgPj4gDT4+IA1lbmRvYmoNNiAwIG9iag08PCAvTGVuZ3RoIDEx
NTYwIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ7Fffb9s4Esbdo/8KPkqL
WhUpiZLurZu2iyzapqh9uIduH1xHab3nxIHttLf//X0zQ1I/LDm9wwGXh0WAWOSQM8OPM98M
f17Oni+XRmm1vJnVSW1Vij/+qNMkzVOrytompU0ztbydPb84FGp94EWpOqxnz39ZaPXlMJtj
cWoKtVzP6KvA1/fZx+htPDcmKaL38dwmOnqzUHP6qiL15qWbU8tXi6W6eLF4tVAq/rT8dZaq
eQmJSaHkJauDF06xyUXx4gVU6zrJo0VMBv7+7pe4TLJIXb57eflCLa5eL//x4sMrdfX+1YcX
y8urdwv1US0uF1efvI0S20gvLLBy0hupePk72deJLiwLZQoYVYKRNnx0/JgiT9KKAMqKpDYC
UKT9eoepTioshyJBqAwHKR1C7+OKkInnRVLiMMCkiJT7bWI4Eh0fZHTPnr9azrTaqJkpi8RW
GtbzxCqLQU5+G7VvZjezn5ejPme5TjIz8Hl4/okwMHmiXRh0ccrzDk496PjEqfYnzrS7ugYH
gnWcRwLg+JWHjbrBFdpoJ9Pbrfv4HpsMN7uJUwjveOkX/q8Of8S6ig7H5ha/QC+Ru13+dHIk
TE19PHaKRxX87zQ9IVd+WBOuxuac95HyO1MZukTQqUQhBBMs8Q43XSHAj008z5HS6m8+0jn4
NMI2o/BGBJZGQUlehSjvB6vWOXGVxQ5a6+IbpnJOPLavXeap17s9cg+c8XDg3w2iKo/uvqi3
scXHe06+N/i2lJeaVj5T32NEKigHFHbXNNdqdeRdW/4vgpWoE4HKlFjZPchEI0NZk8BGGUnY
tvk6NzihrrswDwP6+WvHL3wZxlR1yzGG4f/LXwfElVRpaYSLPJOuA7uGxKzg4j2lJH006hDb
6I/YpLgd+jzGGTBBvhkYjdSK5niNrN8hVwsgcMcjtfq8++b0fFSft6K8iUmZWsmaa1zktdpu
ZNSwPje43qxXx0atd86a+xEtsmTD7mDZZudM3q+c66TpE91a7WkhQDZ3UBBw2g6BE5DPoceL
iwBf5UsSorfke0cQl/CT+AocpzU55ma/8qxbyQRmMHtwUjcPOstoz83O7d7H85ri5M5P3M3f
0tKKCqsugCcqq1vklzw4nRv5ufuSUJJBq9vpbK3k50BQVdGDU+IdHPXan8mN3ZYbxH4WDTx2
J3FG7tby6xV9dosdCsjD4GxICe0uLUPU1Gnexq8Nl/Uxut8gS7EN9YOKg9+ahrvLM7+TcyPp
X26amCIT+SC75iiueZ3/1zkW+pY091SHFLHRs5hYjFMHIU0pUUacfNYnn5Xkg5TTr4xkQAmY
uQSkCIl1KqgTzHuFbgLQIhxirUFaOWXafieKj5xXFvjQf0lAiwR0upqVWJDFe4oHxEHrzH2z
99b2bsuK/RY968alWSe7JskrdEc99mKcqtAgGZdW20RRgSiIcAZEWSfGFlphuUGVOGsJ+4si
F7fg30hHVri6sOQqZDkpEZQXK8ob4O+mhz4gdHVtMAh6Hzluz7zm8+KUR2l2mvuDGEBTmKFS
DkAcKcCsJZCRdlz+KqZ28l9ICNB5sz6CZD+AXQtcLwXQ9ihWUDSzulIDbXUnta4+Yxe1ovtv
0OH78/4G6fEiGHggxb2UQF5W6PwG6DwOjOj8CKW3VFNK4hACaP9PopQ6cjChR6iQolhtKjT0
aAWoOei0CI9KqypIMzsQa4R5Zid3k7jKgxgvFupBOgtMjn5g2rpBW2Na8xUortfeZGh8z2zP
0A91ttfVYHtuzlrPTc+6LfGa6cnRfJ05PIk7hy/KwdmLvDpn/RFx59rglUjhL2j05GLG5F3g
x+RdZMfkXehG5R1sxuTd043Je8+z8feWyWsAIx2sdByhmFQuyTXXT6KkuakLqt8XOzd1d8Ol
FNVQSnotRRfl4INfIg1CHbmFqLmu/tah/mZJqSko2hcAO5KFXtpk4gnVGK25+bFQSO80Hn6R
H3W/35Fkt95tY0+hJzRyWi1/i5pEytUz9QHVqY4upS65MufL6NXCTbzmkvdbfO4hOAHmD0CH
zsl3XCV1XGzE8z9qg6aH0OS7lzai06DSSo+cjTxlj1Rh6aPpotJBO+s1OlyEtS/Chouw5iJc
cxGegFZnwqbrrzE3ffsVSsJ+c4jpnMfNWj5a1EZvY9hsNKu1NAdq50Rtt+A1MRbWdI6wpnKq
uVE0QIPRpgLDaGt6G6xkxVHmnTis75XHFnR+5NVyyktAg9CNEHXfyDGAe30W3Xn3GfQ4xmjh
qK/OOd7p/1eWTIV13jm9NGglNWigT27RsqhXi9FFp2h6sdkmRZZJaVUcvJ1iV9TEJVPlTKTT
5Wx8dyhnIj5Tzsb3h3Im4ulyNr49lDMRT5ez8e2hnIl4upxNbPflTMTT5WwSebmXqq1m0HGK
/Li8RXZc3kI3Lm+xmZCHw4/L29ONy1GvxquUrkGZqVQpTkEd8kk73jNtebq8o7DXIAz30TB1
kEhRJlXIJDfPFSVlGqD5Zn+IKW+eIROxf8OTfuuwVnWSLy9bf0qfgm+ohaT3kaWs3YB+czyv
KsrE6+5ohSdtFX3e8lRznfQJf4xhu3Zw7LIqUcSjBR64NWtluo0NP+AYCPCw496V/+0RXOc4
8/bVi486sCm9eZkdo7tvjQzvmDsz4c7MS1ci3MqkErr10of+Ft8BeAo33TfBAeeh59jhyG+i
KrqlcR0ltLc+oTOdZY/RWarbNumUzkQ6TWfjuwOdifgMnY3vD3Qm4mk6G98e6EzE03Q2vj3Q
mYin6Wxiu6czEU/T2STyci9p4tkgy4kZulJt7RkqnJbSnTrpmTsdtezFE8r9lTvxuSsfVe/F
E+p9RDjxmYgY1e7FE9p9wDjxmYAZ1e7FE9p9PDnxmXga1+7EU9pduDnxmXAb1e7FE9ofEctj
SqfnXlMg0fCaSoWDHAWlpK/U+G9tpg7r2fOLQ6EuFm4C56rpnba4wMpfofZ3TKE/+65g8K36
+ClV14i7gh0sTAkY1G07kWW0WGu52iJD940hUDB5GK5nlU1MGsZl3t3rR6J6PQtjQ/D5nbqC
xlaxDNezYNjJg5+8eeD2evb5p6A+19iIfahAiFoB+pyMYCxTnI0gDIqx0vbwyPGI6+CBrkB3
8JBhi4eMg1ne23HCdvEAlWQtHplhAghA87CDh5OHa+LNA7cZj5Rjic6UEpmQkM6MI6W5mAJn
WLWFaryKcnGzkIlSbOUFYU8TBecQhTNid8sqatObQJvAW8pEs46e0e3s5qcn40dNfTBBx3l2
O6uLxFYhOLZ0h4UNMY0x3GOoK8J2S4XA8n780nq/P4zp7vlqaNAz9iTsV5mDnSG6nVX028Gw
tlwGW9R9LGKiooka/axp7y3sl2EtlcwD3rf2NBzQ2jrIyHyIOw9gCEyP+ID2aMK4yEx9qPrY
9RNpxe0CAe9it7X5hJxQ2hFfJ0+MS07JLKDJ/oCA0u4laDBzysDmVO+72Ynrsb3sDBNnstOc
ssT/1RFkjs0Ddp00deD6qAMD226WlsT1GBfutn4wSzu2noJ5ZI1H7HyOesxPchTv0H6OciSe
5qiRHO1YexoOhOqTFUk+yNC0V3w85m2Gyp1Qgvr0q3sJGiZOE7Rr9En5UebdMnXbtnOVc6PT
g/ACmmC//IpF25P48DM1n8lfJg/beDTWp2sm0e3kwd3hONM4F7tvnP4qqXobgkY/4b0PJsKE
YwRs0X0nMh9xXsfJRO6ZybthBm6kjsvChElMz4aMAxBOYcDJiXVQ3xs67T5lnPUg9sr82Lnv
KSKMXeuAa2TGCXKHUNg/HDuMg/mqZ97fUS8EhPL+DIo/g2IYFKFDGUZHKUU/3LbjvNObeSw8
8Pwz7l7K/zA8/s1+tevIsRvRfL5iQlvAjpvPZqd+JIYj736BFlJgaBMl/n3Xm2TP3GYv7gVE
wJOsxBoWT7HOqeqijGj38kg6gOmOPdf7dSOO1bfcV3H43sPd+mvqWvMQbVZemt8ti7ulHN+o
wx+pQ8RTlVceaUN//p3aEILGDeMpif97ScB8cYurg785B2wbwW006UWMCFVSDQWcr2HhOTEG
j88qv0UafGT5fvFlIQz9PRdiQ7zrkk6H7WqAAQpubN4wccFgZafzEqJTdDZYbOy9i/398vVL
BYDhDvhJmIHri8O37s9vl+/D3zFB6+K5pxoATopdcmCI25rkxEy31fB52SRHflds9m5DyV1y
oN2HJjkeBNkkh5dNcthQgyXvXeyUHJsv8axCNBaM5AMMhYogwpCMwgrLSm9EDJWUGZyTqy48
Agd4I/JlA7848AjOjRgCFBqqOcKbghrMDpUEOVMknlpRhIfDhk8qX7ZWKj+IzljFD4Y106wR
Q8Aco6FAkEjJxu9IO6MaEpU8sERxdJhzxbGuTAQnDeNw0IW6PC89E7UAFu5+HjpQbsi0I2yd
oJE1POxA5wokuIW+HJizjypMS6kpV1nomyUaMn3cYpB+b2dUg6dXIhIRWO0Vc54gbOpsC0mr
l7vOSgcVIUpowNrdSMobz8u1dj3P37V2xXBYuw+ayK+MInDRcdrawpXEVtU5/kC3hbtw4W70
RT9fuB3mXHFACZVzdatEPKhb330N8AiW5n3datmWB/1jhjjswwXjWdzV7tKpzliw2lWeoHZZ
udKna+2a4a52W9S5AtkNYx/V4AOlsR1iaEMd+XjDazPTqCBh9I7UBIRUWjcShUFeihymyGaD
RXy3hqmcDVkQwq10G5x2CTVwdBVB19I0wEG6iGxwRTuRnHBv2DSvEgTMwFu/o0s7/NyFYGvJ
gp5nadINmsa7ddc5FL3+rOeZQW5gncMMOmzAE0ra0daxXpncr5U5jUKIqBuEqV4LrLWnPJ7y
+G151InmTieu21ufYXuShjpJMn4ARfStOK8TmenudKIZ0g33pN8ZGp1QEMJj3ZD4kdHo5tZr
UdeSh6oUp0q49Uzv10mfMVUsA62omhoxbo+1YlX9u7UibJ1qJU+JPCXSSQRmkltcHfzNOWBb
SfCAQNTkcTAE0ZgBZiznr3HjgTLBQAnPtAjzI+Zelu+XmAM9wfT35OkRp9665NNhuxk83tq8
Haqgns5L2K7obKjBkvcu9vfL1y8VIDqkKjkM48Vhhn5+u3wf/o4JWhfPPdcAYHPukhNxzKzJ
4WMsfF42yZHfDZu9m1BylxyYKkOTnOBx2q2pp2WTHDZU4sh7Fzslx2bSuBaailPEi39cYnH0
KUvwLEAtxm2hcRYjTWyIjBUTEoEGT4WcYuG3Sixe8MyQZcfK3aYHJTnOEwd+gTF3VL8QyBqo
tkQmP4jKrQofDcttoewXzC8aPFVbgocFvUTtDDPkQq/ZFDiMDnOuOOBQ5mHlp2nM6NtmFQ7t
iVB5Ruk+cU0g+oZLO0LXG3V+pWGHOVccIDtOIQWhqrSEqmyNg75NomET0EWFrMpWQ8n0UUIa
RNkVc54gbB5tq8hT6XrrN/R5wvZEujIitnSLRFXkibrWLgba1a4ZDmrX3/eQXxzIKoVHyWuL
V9Or0gtZpKe1K0MB1m7+VO12kFOFkZ2lcFS6SsOj0mV9aqkmlueD0uW4O8y54tAvV0g0nLf1
u3QfLmPB6ldoKgvLVht1PUINj8q3gs4VRz+IfTSjYeFA2gmGdtR5T3a8NhONCtJvNxU9IdK6
kajPWtGORa8bNOb9OmD3IMNGrwhEL51Drj2CDUUzqRBq0KYBLq4PIoj07Iw7QxQtWhh+F8Yi
7c4MnsVoGLK2TOiJlirZYKncrxVBK0hDsA16ohn0Fto/qkGGDnircE+yHZorO+POoPm2MEof
hjHWaUK6wVMmT5kMZVKnnDu9RElr1cv6mKqRXnDKlObp42f1srZtsOpFs2Q79uTv18qEBaFi
qGrxvYe79deUteXB1KKJkg2WyP1aERq1+GO1yCUaPZbf0kpZHkrj81pRts60lKdEnhLpJAIz
yi2uDv7mHLCtBLfRxJSdw8g/GgNMjP4alkKTTvY4SF49jE+YWlm+XzyMYK75HSCRTPGuSzod
tqthyXhv8148jmd2Oi8hOkVng8XG3rvY3y9fv1QASCxoPDkM48UFfCz8/Hb5Pt6AKVoXz13X
IJAn36YHklxqdkKqwcP/m7zgLwpJPm0Aybc5AXWFJicuw2evHsvLJidsqBGS9y5gyomNpnhW
IfbWG46xfitUSdnzPB2WlWoTA6UPUnBO2N8wTbhjk0t6frLgEZwPMQQYjXEmz/BRoybTg5IK
54nDwzMBTQGfCxAIzCqNOH4QjbHqHQxQuJlCxYcpGQpoEeko/CC1M6oh0fwCDFEYHeZccUBj
JB44ZxiHoyGnSfPSE1Ebwsadz29OAmMu7QhbJ2q+SsMOc6o4goM+uXDGPqoqLaEmW+Wg745o
yPSSzPBdSJ2yq8FT30caPEu9Ys4ThI2hbRV5KV3tN4XrrkiehQis3Y2oKjxK19p1/CGrtSuG
w9r19z3kFwcSuPA4eW3xSnqr9BaWntUuBkQGUPGnareDnCoMKKNysnSFhgel67vPAR7B8rwv
XS+lWx60kBnisC+XQ611Bbxy363CVRosDuEJ6pd1K5261q8Z7uq3Q50skt0I9lENzvOs204x
tKOOerLjtZlqVJQwxJHwlVhaNzKFpiZlvtK4rxss6Lt14g4aliwIPL3XDYv2CTVIeBXCDNI4
wMV1QSyrdiM5495QpIFpGPBvF8YSteWpIbMgDUPXkgk90VKlGzSVd2tBsCqSEOoGPdEMcgvr
IWbQwQO6b4xdl9FcGaF3BmVQwxBC6gZhrNcEq+4pk6dMxjKpk86dXly3tz7M9lQN9RLhIkIU
fT8+oRcZ9u70YlnSHXfk79eNWigI4bJVi+uCWNKtV6SuJQ9VLZIo3WBc79dRHzdVLf5YLSKn
Ro/loVastv8ArQhbp1rKUyJPiXQS+evb5S9vbxFaytv3C7xUcWaBf8IGr5RlydcEg1IpS7i+
fdSJ5mW5Lfjj2/vlT/96/Xf489t/Li8QBcytL0AmnPV3+iHqD1u4pptPandoh8GrXGEsi2r1
aP3HG3Q4vLmXvwCH7yB85cRYSMY4sxVaB75XjJg0d01w0cSGlS6acKrDi15iWkhlaeEzYvb0
uEjw+iCC8DBMXjV0HtJ728he/3bx139ecfT87/USAg/XCZ9kBXKIf2FQhWT+/IbjIKQswuYV
5lB0gXs5aPMREeBeDt+IDiZdgoRYWAQpST1GmGPJEGCro3F1oajAlHn0XOSUOr7qwypu8ipS
Q+8i4zc8EmgydrgJsxzhUYVQK6XHSWiJnycxRiIlQZokkogpQBPspQk+plUuuDBwBO9MTply
uvN4kGRKk6f7JHjGSJoWCjV5r/cpVL8xyjsgLyKQJA8d2BKpnGLIHJtfA10ohiSHgCIwtTE5
bo69B8dGF2En/4hj5lb4TUJWgvA2DDxFfsAmyAtC2hqIodcIevBVFx5UdkdQEFyGoL4FgUF6
fwDOa2PyeLWEZ7/QOwuu9h2w4obyrX/lgnc+eHlx8dhQmr8Qc0rcgtjlg9Zr1jW9m25lK1f8
G6/8/5Nuh2juljs3xyoewh34TYVHPLaORuwA8MhxGsRKNfpl6IWnFDNyO0RTJtRtzODQbyo8
o0Edx/yNHSdBXOVTrtS36wO8sdshmjJR18cMnvCbCs9o6AwnAI8cp0HMO+rzOcWM3A7RKhP5
JINDv6nwGhrySf7GjpMg8shZqYcZezmhmLHbIZoyoW4jBk/4TYVnNKjjiL8zjpMgtlR/QjFj
t0O0zzJ4wm8qvE/zd8ZxGsTcUg/P2uBPKWbkdogmTJjbmMGh31R4SoM5jvkbO86B2FGNfk4e
XceKOeF2iKZMOHvFHjJ4xm8qPKPBtW/YE4BHjpMgtlSzXz6jmLHbIVplIp9i8ITfVHgNDfkU
f2ccp0HMHfXw7znFjNwO0ZQJdRszOPSbCs9oUMcxf2PHSRBbqtlvyycUM3Y7RKtMsNuIwRN+
U+E1NLDjiL8zjtMgVqrRL9zSOcWM3A7RlAl1GzM49JsKz2hQxzF/Y8dJEOPNl5b6dn2AN3Y7
RFMm6vqYwRN+U+EZDZ3hBOCR4zSIZUd9OaeYkdshWmWinGRw6DcVXkNDOcnf2HESxAQ5aKlP
t7ycUMzY7RBNmVC3EYMn/KbCMxrUccTfGcdJEPPNLy31+bb5E4oZux2iKRPqNmLwhN9UeEaD
Oo74+x/7VZIjKc9E93kK1r9UlrGNgXPkEVrdK2rTdX/pt/FAROAJKrvgk1KpojvsePFi8tQC
vA3jVupDHVODFdmOV7CKuxXfifrVgTdhHNmASj/5R1elY+qwIluoxBRfseUKNuBuxRfLMME3
bANhCfjzjBT49esxDJL1FjhMpsPMuO4+pGaj6P7+fvx58M7+LEHQW1vCqkWt56Pv7M9rjd4N
EdyYvBu9dm5Ek2DO+TwopqDP24Drw8381qdTQ3sHM8Po6j8MjEd5eXwZmOS6g18YjEmNFNA/
N7AAQ2vylmQqNvSmnENzZt12f6uNkfEpanzuIXag10QjDMhiTpA3Djhq4t6oERfyZs3brpZK
xCXmZM4G3Vg6tTq4fX17brDexCa6D9t9a3ee6Yed0T0Mzy+PP/+rNEgppuP1RE3y1Vy+zbSk
1dpp+HbDDoMAojtasFknB2amFaKJA5pJ3DbbQphT6aVps+ne7xH38fAqL9Dm4ssvh22fFdsA
aCTJ7ZqBGusA3olfYA4fEJ8J7+2yDX/rKhRMcbQY/IBBTDuLCwWsjXLYiHVjVnMHv3BL2OyQ
FqDVWckTILwBbPSmY7xGT8xu89FqCQKM7pyFrdMTb80e1Gu/G8lRokM9a+gsGToG/w3FfyMe
SXUkpZBt8ewMfYcrGc5LGd7R/Gw04WYbNNzNFs/XQ0lbOcWTCKNqXQzmfo0233VgoRrVQIza
oFOGzpLto2miUOY4QDrrwEI16vHkDJ0lS8Tzaop3PFfE0wuiQy5nfqAej6BkPb3RHCFLxvNa
inc8Px+PZAOmWAcWqlGPJ2foLFkinldTvOP5+XhEfBGNUV7IfD2YtJVTPIk4Xmj9HcU/jAI8
2np7v/6Q2ox1f39bW9GEHJhwNgbGVRxYqEY1UqOmUnaeJ7n20RYYtHkwKMgwctZryIA1stEA
NZWyc5Zri6aBIQbMwwkXIubkhAsDtdrsDX2DKVGZpP3YhEowtWbKxD6pOGA94J39eVs1ZUTs
lLl/pETldSBjuaDMpnnq7Fd17v9fvwzQMHPoEvZxoRqLW1nbmE6BnkCFkzdW8IhoEMM5lI1j
VnMHv2scvkxbHL5MWxxIo9pPMTRi53mSa99RLQwxDUEnJg9p1KPJGTpLlggnT2HaTckOfm3J
wi7h9m9ukoG2b9DcmkkNExbkSAC8qepudrVmAnZxlBN2zdwssO4scnZHc+uBukFO2fVJiLpB
rqzbsL7Thx90xiuac9PrRbUn3YDAVh1bmW5RdpWCMZ0CPen+A3VCU9EdChnOoXLLH6QxH4cg
cZQOx3Jox7nyFS8xlJInSPKK0eTzeY4sEU4WHu9po1+SI+NTkBcgT7Y7LV/PtEoOeERsfifb
ppDcxr594aEYif3GFImDHHkUm6bkQI54f1xHMr/xRLIgR9sibn9xYNbfiHK184m2BilyXuaV
L2XZWmF2QGVujHEgWaKSHztzAh45MOd5c9V8zDTEuZCPnPJPsAyDYmodkKbxkcY6QK6UdWXA
7ZXVyEZ8/1wH0pYLyvFWEdnjYvXsRKN6A8oaOku2vwG1UMSY4y3Jx0w06je6nKGzZIkbXYEi
Xt5CzGHbjynDGtUjKmvoLNn+iGqhiDHHYyykDGvUj9ycobNkiSO3TAHWPow5bn1kd8jHUzZ0
lgzF828o/hvxyCqFbIsnbahClj72cvHs4N9hOBrOO5rvRTPiB0fmnlkLJW3lFE8ijKp1MZjL
A1RxAwvVqAZi1PCDJeDOku2jaaIwF1pMsQ4sVKMeT87QWbJEPK+meMdzRTy9IDq9IBR9w55m
1AQl68U3yJLxvJbiHc/PxyPZgCnWgYVq1OPJGTpLlojn1RTveH4+HsEmpGLlhczXg0lbOcWT
iOOF1t9R/MMohNWQnGySbmChGqVAcoa+wYRCKdo3nnDr0/a1qEGyUYAEDAMbYfIGzaSXnQva
vCfTcirZT+BggoorSLXJKNqEnKY6GeEm/3iEo9m42iPc2T+ZgQMR3I8hbP6xbOHsoHXd1S3I
ucMm6SWg44rQodqCWmI5T9cY6SE/b8oSroixSOsA3F9imnZlCgMBgu+dGU8BIVeIkBZyX6gw
kCesRtvjNMULcdLTnPJNWNxjMhYqvEXBgE+TZoKTgVlACH2+ZjydaOUmXLlof1eobSBH2Bjt
IU9vyjKwQaPKrQNLopSgcmQgQCK5H0h6GglDoSIhLeW+UGEgRzgMiil4UztxNtosub+vX4/R
TVuYdVoxbgMehGEx6l7sJzZb9sk4YcWBWQlB3X2vsz+TjG9YfUbZLpvOjJoF+tHb///9/fhj
75SzvU9uXxNFCmID9AhhZPg1Hs5smiLi89EbU5vs8jTNU2e/qnP/b0MVuSRBNVHlQLdgskUD
mFDDIlEWcyEPLqVB9W7pVxqiBVZmkwTWRpZD3YXLpz6AiuWqg65l6tnEcYnX47zWGQ2wMpsk
sDayHOouXDH1DlSuVxV0LZNwp3UsMZLzXA2wMpsksDayHOouXD71UKxTZUHXMklzBYEllu5C
VOuMBliZTRJYG1kOdRcun/oAKterCrqaCZT0SGdUYWW2Y9Wqoe7CdbBeFdC1TP5lF0vsX4u1
zmiAldkkgbWR5VB34fKpD6Byvaqga5lQSVfUqBs6owFWZpME1kaWQ92FK6begcr1qoKuZgIl
NSgNn6MlriqszCYJrI0sh7oLl0+9Bq/EOlUWdC0TKqlBjYy3dEYDrMwmCayNLIe6C5dPfQCV
61UFXcuESrqidEtnNMDKbJLA2shyqLtwxdTrhnpVQVczaVTiiSne1BlVWJlNElgbWQ51Fy6f
+gCq1asCupZpZpzDEs+sFw2d0QArs0kCayPLoe7C5VMfQOV6VUFXM40Cl3hs64wqrMwmCayN
LIe6C1dM/dhUrwroUibBTQZAiY2sVL0zWmBlNklgbWQ51F24XOojqFivOuhapt4/dUOJe6Zb
OqMBVmaTBNZGlkPdhcunPoDK9aqCrmbS5zqjCiuzHatWDXUXroP1qoCuZRJMalhiwWbd0BkN
sDKbJLA2shzqLlw+9QFUrlcV9HNMFPT16zGyybbPIE0bmdFRdB9S23/+/n78efDO/oxtr+YK
v6pFreej7+zPaE1scIyWXoaXkiMPlrbx1UtzTQZOBsn3V7AX2k/GF2Wpa72RQbjazmyaorgA
USk0a8Tl8WVMSq47+N0CM1nianPaiZtJyUaXaZqQDRcU0zhz/nfhz14cezbxWBwI1zv4zng2
OUDLXEYNFUQBefUJuEDl1SUsr/mjhZajX2NBHphqq61aHd++pl0RyjSNWS4f3LTO2q0n2oWa
3KPQ9PL4879ihxTDOVVbHtqyoZibTVfM3pDj+SD7hsNubm7Hco8ZWZmtBrbDJgvYLlv/QzEk
hSbJ5na3TdzAs59mBxuIr7DkttO3Pd3JsU2EMtszmHYy2na/Zwht/597f+0SDH/roSIU2Jm8
aJO0M7Zg5bUJDsEt+azmDn63VR1sEI9J/g1nWf9pWF1CJBvE6hO6CKFZH8PqZUb/ic/dT0AP
YwziuumoXvsNRI4SnMnE5YA5ThGb7tWG7+k7x4Y5NsxbfE+ZOE6R8P01ht++v9Z3f6EM8/5C
iWZrvvtbJzFxnGLne8WwME+LaZt34oJnK77vTfT6FAX1vWa4n80E2JNXccGzFd8zJo5TUN9f
Zvjt+2t9n8yBC+ZXccGzNd/TJo5T7Hx/leG376/2XSg0LxQyLKpnk1GSem/iOEXC99cYfvv+
Wt9HdEGlb5Sx4Q6cMXGcYuf7qwy/fX+N7+iN2dsb2ofUBtP9/Q2ejNLcf+wdcGbTFMUFz1ZC
25mAcTXbp3GlrQrhnrZhVihsF8/nHM9bOUsSva+YDpdQZQsRg3PigmdrF+S0ieMUuwtyGujb
SY7uzSDMG3eKsuXlnf0ZO1XNyBg0B3clj5qDu70nbOY12TRPnf2qzv3/65eJSCjgCXJswbOL
WxMZ/fC6cdMDekEEH9AsMjcwtVe3Ls9q7uB3dXmCLoTuH9HTDLhcWJY7E+iN1sywW5gVuz47
YXpADzOQnYLnLmHEwnGGnecZu6ZflOzg1xQiLGS3f3I2kv0ztmbfM8FBXqJs2VC7VzWjTdEz
DnMd5Z1NM6OJplZpm8JcLqBmkPc2wx62ac5IM7nYwpo0CTMnUDxwTN5swoAfXq/XbBZOL6o9
yW4B9k/fkHQ3MZUoQFxn4t0CKPgOoLsJtOlahiIyi3eXOOo8mq+eTtl4jtPka5s1nksWmq/G
kMvfCZp9DGnj4eIjmFJulU08yssmS7OmrKyZmlKy14997WVbe8ltvNt3O6ECq99kAiiIgWM2
DZ+Ss5z0zATRCRKdQNGNjE9Y1t+IbrXyCdc6z/iX1bzEPij6aF9Y/2e/SnbkuJHovb6ijuoB
lMMlSCavhn2Zm6EC5mDMSbAPRmkAywf/vl8szIVZWVldox4LsNBAd0cyGOuLhQi4m+ltQu4Y
sBE1R1hFlfXVV0cgd37l3QjscL6t/Dp4Pqai7rdjpVcT55BzUtk4AcLleqf0TZm7nDbrm1Ir
vKZzdXqwhuyIeL2Kfg85FGzOtXPzbXV6ZPttEa9XsbF9T3BrylO2ae3d+vxobuxJeUrPZnA8
IL3hi9Z+rs8PvdiR8pSerRf70lclO3O0Eu5LeseLAylP6Zm9eAvpX7cX7kC6e8iLm1I+LAd5
XS52Sl+7810v1tKN9ynpr/Hif9Hzd/YidtJjJ/3eK+NAylN6tl4cSg8OE33BofS1Oz/yYk/K
U3o2XhxLx/6YlhxKX7vzIy/2pDylZ+PFF5X+zYu39mLEwrXkEPranR96MWJXuCHlKT1bL76k
9G9evL0XoZMeOunhIS9uSnlKzy0vvpz0b168tRdlSMvprvS1Oz/0oqx353brKT1bL76k9G9e
vJUX9qbFSVlKV/rane96MXOt+mi79ZSe2YtD6TDEsUnzb1wbMdkXvntYPMfievJ+CI7pbG8D
j++36LJ+Lzb6w2xgp6lOQRbGRja55s2G3tXzlHeN/v97F1/jXSe8B/Oh81oSm1s3jN/h/Evl
W6OfkmWNvk/mJlmN3hkqN+wzTXU9UbpcTsnr6V09j3j3uHVfnXxZ7BbZqXnZOFpU+mzMdM3r
qNW8Z59omrMjjF2yNtmY6R09B96NXUzG3ejtcP6l8u0hN2XDHnKL7GhU/OBoTWt2dh6NN+wz
TS0dxtgla5ONRu/qecS7x637uuQHN/hldpS+brI1ZaejG3/T2uitfU2TpaMxdsnaZMPoPT0V
f+6MpeOuf+af3z9OimLkoo1VfjNCPv98+uWU3RBEbQEXBBVSQTHhOwS1cwpoQQta+WVLolo7
DTiZNaRYBnILFSn5YXQLHRNHU9JdES3fXU7/vFxGRP7yC4ID6eyf/BNp8AHJzy7hvovnyydA
w7lE58vH00/vfEa/ekHi6R2i/+IJ/xTE4eU/l3+dyjBWBNwPqYy4+f0O/4i0CP8PF8gOsn7q
71IFdm7I5z/OMF19q2ghI5wlwIDhVCPcIA4+iLFqjglZDEyT+t3okhUjCJSAICUkRekitGci
6FCgPFBrVr1dSH8qiueaLfp1cLiWXZx0sMzsnK5La35LsJqtmj5NPpIzEfyd6WJurfh1k45e
1fo4yL4RRr0D7EhVItMWp4nWUBXdsH3IFpuqds4fQtvBPQDFtmcfoIy1xCA4ykijIK2pUTOu
/Q01FbUkEC9xiEFsNVty1rHgo81j5bj2Vxpe1ygNwFHNDNNMsNxg2qp0F3WhoS7ELDWfgQbt
CKS2kx+0gbBy0PBJaQ4M6FDtgYMPjqOBFldXH6Ar7yMocJ5ZUCINa0B5cm/L2WtYJ9Vi2rW/
IfEIyLgAzScN62SfG5t9STZ147j2V0RMROxVt9OpEMHE3ScDbYW9iKHIfM3EnPZBAhWTUIrW
zFld0r4q+wfoIEVJqlozEaaKf9kKc9KRrQS6K2oqUCGYD9wbPs12eJIb2kn19Npx34ZQRHsP
TiDETj8GIW+Ny1uLe58G/PF3Wp2fQUeIqnjugq5IRDZpph5GancaY/tgA6cURQeRLTzZYjN/
CG2m3gQeJQuR8zrliCzsDTJNuZl37a9o+4qjThOo057cLETjMgtRMjPHtb9yOxtUgXbOhvbv
x7IR5tgmHEnPK0mX7wS3pK8AZl56sdOKSGjK2WjpRCloQUwfEJhyJ5LJZ/WHx7u0cJSUZi1Y
D3dVm3rRQbPiF/+T87YKtDHQrJvmQLO/DYLuyu0wVo4Cokg5wofHohgbpt35PSz0lO7AOVrI
4VP0MSIqKbp7+CeTjqHhMJfvyaY5nb7fCELRAYXCFvSiiUiEsZBJ4xmnhU8xl2yzsgUwWV01
Gs02uwV/8TpBIY5JJFKPs+2PyRY5xwPKkW693Kh1C456G628rkYYKkpocHJ3Thjmsnt4FIsW
bdRlxY/aiRUxAWDQAe6VP/AjUTah0p4fTiyaajVQlPUmu6JTg9cc6Y9OwRxysfGt0zoUXYq1
gYbqrZ3qaXQa3+l6RIrSQv7Uf5sBEauqZAi7jryYIm+m7FJ1GqaITUzqq21kEfuKrGCtdRHC
L3Gm0ZqbbMGLZXbqmFEHDqWoWlsuCLIkspIqKkU1tN2XatAtsGV2KvpgE4+3fie5HwUK/Fdu
YOnSNhFHTWaM6ihXqIjATiF00j0o6fNAXzn9GlDtuSNaP80PGLJ0GtynB86KX1tIyvZSkM0f
LQSua7BaC2mGTE+B9RURc3P/9rzAzmHitS0pALkrMV6BZIY8VcOHL5oYQpPTGqhcDPjAU10W
EECJAcgp040paC4I2XbidCTJHSdZ7A2knZMniNBpFEgR7NewFKc30A5UJncz1hq9RI2M36m/
0RUJgB5HVL84gUxmxXA0cToiIq9BLA0B1CrI5gON9qFE6dKUkqHeME3FSpdCkqFP2pfIEumi
TiUOj8AN0RF4UXH2Gs2K8NHZ8621tnGUwE5YmQYDQCI09m9tR0HjCiRZ0ViRCOe4hDCg61Yf
sFUEkyGh4amjheZ0W0jJ9nark51h6eGottIqi/aqkyJWgk9t6teOWVFO1QqWdGfi8a2tvLmf
NOWzZesr+g458w/s0WEoT0ww442ptUu1nEeA7cyT6Pz559N3/zj9BpTrkJFqOGPKI2XykgPD
v8//3Y5fucDjt/KLrBu/nOh8vnw88fR7ufzKc+5HaAlV86laogi6q0XW40MtP70Lvr68h3fv
iv31bbyy2hR0QhAaNoDF6TwHhlbTy7mXKcTzTs8X0fnx9OcAx5nB+QplbmRzdHJlYW0NZW5k
b2JqDTcgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDEzNyAwIFIgDS9SZXNvdXJj
ZXMgOCAwIFIgDS9Db250ZW50cyA5IDAgUiANL01lZGlhQm94IFsgMCAwIDU5NSA4NDIgXSAN
L0Nyb3BCb3ggWyAwIDAgNTk1IDg0MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNOCAwIG9i
ag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9UVDIgMTQ5IDAgUiAv
VFQ4IDEyNCAwIFIgL1RUMTAgMTI2IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDE1OCAw
IFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczUgMTUzIDAgUiA+PiANPj4gDWVuZG9iag05IDAg
b2JqDTw8IC9MZW5ndGggNDQzMCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpI
ibxXy5LbuBXd6yuwBFMjmgBBgsyu3W7POOWxuywlWXhmoZHYLWZkqUtixz2/MV+c+wBAUiLU
qSxSXdUiefG4L5xz8HY5e7NcaqHE8mFWp3UpMvijhzpLM5OVwtZlasssF8tvsze3p0KsTzQo
E6f17M2PCyUeT7M5DM50IZbrGT4V8PR99lX+nMy1Tgt5n8zLVMmPCzHHp0qKj+/cN7G8WyzF
7c3ibiFE8uvyb7NMzC1YdAaLvKPlwAu3sDa88OIGllZ1auQiwQ3+/unHxKa5FB8+vftwIxaf
3y//efPlTny+v/tys/zw+dNCfBWLD4vPv/IeEHTFQStNscBPCLioU51xwBltjHtKkSz/NUiW
ytJciblKlQ1uUvxz/4h+agFuZkUmf149PbX7R7EST6v1700nuoNY7cXHxT35c7ecKdGKmc6L
NC+VsCZPKyOUKVODm2hxbGYPs7fLgb95pbAw4LApUlVGHa6uVjfPU+OCDTNUxlMyiq8oyxCh
DYXIOcAvzYP4q9gkc/BbHhMD/1f88tDN26Z7mH974vfdab5z49wX6IU8LWXGbyX/pNAy8NO9
dEKcmnXXHvj7nn+EHg1TPnsUD+RNZynEa/FNQCVMFRI3jl+XMKTCBGiVVtV08ubKppmFUM/S
kF8WepkU0Ixb9KqQjXg6QjsqeVg3m2d+bMTDgZ/Et0Ev8KeuXT/v3POwQaYHfKS9FrzXvXg+
8Qb8I7otbrXbHb7DeyVbqImWsBtPfuZZOzc6TTJ4E+Jutd6ejwinEYI3pg9e98FrDr49JXSo
Ia5d22xEuxcdhI3f9rgamJ73Xbsj31x4a+j+3xrKBcwIpyEd7upTHj2ENEzrqg4NWoUGdb4t
dqn4RD2kYfa8qhW0HG+Sp1bBhMFODGOhyQvritskcwPTTl0yt1LcQodXqZUn95lXUzpVtYbm
i/qdXWylyF1wsmMwbJ5OvJhNy6q052tNLEOrGO+wKtnhO+gQK1+gnkY+wSGCDH+BihdQ3ByP
YudcBgyrAKvPlquD31/l599gGrb08d+wyERtMOmKnIMdnnFlcBEYowJ0fN39eT8fseRbotHx
FWfj+Hui8rSWLidwyisDYKVECb814CAe78Ehf9VaVcGal2dmBTiAyBuZjebKBDOwE6LIYIA2
0Ofx3TUAuu63B4LLRvYcyOzK9mgebp/ps+2Nvrq90aPtS3u2vQH8vLI9mgfbF/Zs98JU13Z/
xTyomzHOCv4Cgl9UZso+zPyUfZjaKfswdZP2QW6m7MPopuxvl6+ycFkoSIwjIQde6wBoeA4V
YJeuYVglPzwkMBmBPqkA1JpjI1o8pICyzQt9Wq273R8JtCjw5WHPo4A14LiXQBsGjhaIL4tr
XMPBXHknIHhy4juvuQXJVct2DaAqt2KLfA9nVNCv+AmwtoYdTp24oZ03/O5+jrixkQ3NcQd7
+ZeZZxOH3S7o93e3oiXNUMlmD3yikQhXwCMH/og5KCm6aa5SgQ6UowNkH+LFpvsT0ghOEJmK
TcMPXbsn8wqEBz9FQM8MQHK12RyJUIEi6H8fV497nh8A4KxSPfjl3sXcSap7lIzgypHZBRxC
TOwwVnxoKMUl1OHUxXwrA0V7RrhJVAFFY0exLPxfvIf8FcAXSt7Ch1qOKzJkgmYH8AxHyXIp
atmNqArUmEJpwB70HJr1UWHhMf3InaAASDVAhwLoK/BhBVKkkl4NRJjm4iJADVBCuaC/a3cZ
uMdWK1giGhmjOog7dy3OFE1VGpBMqVITZREyxklkcm7gELJeoZDJ2YFByBonkMnJgT946zh9
TM4O7EHWOHlMT/bcQdY4dcTSzbXIeuIo6/NkTxj7XE4Y+1xNGPtUTBlDqBPGPpQJ48UNxGN/
UUGXmh77VREwy18iEQgKecYAmtDPkjZr8BAhND/Th13XPvGcHeI+ssUChJ/Bk1ERSMGFUf4Q
Q39/v1uHOx+df7giwNGFA7smToE7WgKXvZaf2wSvaPj0yINWAFO4T03DRrByGSGgE94SGJ3Q
N/4vgAAcsSH4UITNnkLsfPCrbry2CVcSUvzthiaUgTgETywl30T4kbggl27OJZfMx+CTO1Dd
IA6XSGYIO6eOoNoQd7CF38XKDXQ/BOw1XNhOjOkGgyoCVF2gng76PisD6lU4jUOgR8ZTh6aa
0LQYo6nLkKl7cqh5Oagn4CN4JA4PWAlYpgOHSmB6+n5AsihYQ+D9YUFXu3v+mo6vP8AM2toz
be/lRE9vmrNgmN6QTFa7HaejHtP56GoWbma8FjJhxVID67fBN/p3ZIaEytAFYiw0VOhtZYPQ
oHhDnynuM+jxU4K1Sv//XHd5Ajs+f07KWZJymjeDI/Kd7048xh29Zlx501feHRPwJ6du0dQt
LR076gYDB5l+xNOxoa5Qks0v7nvrTmrVn+65q00QDTssMrgDNYd1HxssC9Sj488plmpKul25
7F4eBkBDhRUT/lSwIIZq7un9gE1QOiVsfPoqSl/O6bNnIYSTXnvhq7Cg2ySjUFA9kbZonIz+
xvi14tcOxWku1/y2bfl1/yieaO6RDkDuJ4P3sL8b9AI7jHs1NJfKB8gGrbQjfWqhTPgfFstI
1RUEzOjcD4x0tkc6asVRR1wKxZZWcOqQ2sNQe1jXrmTGJGALMHAgllKH5BAbRnZw8yKqPAuq
XOuBigNNLk7gIGl7DXlBdCH60iTsLAs7dA6BAxse+5+nuklsmsKPsdbW1ve/wlvJCuMBjlhv
6Zi2CR6CksiMju0Trm4JsiQchkq2L2xoX0OW3QFb3UpGk0f6T7UCGuD6AIey0b82ws2BMsrt
aMYpHd8snHKl64UXuHkKP2ascC/EbVGrXqJcqFtnjcrbyGyvb505LnAj873CdeaoxI1M9xrX
bx8VuZH5XuU6c1TmxqY7nevMUaEbT70vjPE6WBm4x+jL3E8OGCZ3csAwfZMDhvmZHjDIwOSA
YYyTA6Iq2ORjFayDRvRcn/f69wZlCDCHUz9FYFggAf5pkozkFxpBfyKWHfiNWaLwNFATDRim
gVJek8R5L5x6XtB4PLcksYFzSY2DGFGIRaxm8RP/d0SKQNPCniWAPU4T70ni3hFy3jLuDjEl
aB6nn7xEqVCiVJIiJ+2CgcHuK6+iWecj8eF1wcbQ+L9Tl38yxxKtNo/0EXcp+cvx8EyfMNWQ
/GMEf1UdYnHB/ELSq8SYfVyWpRfQ6C/JWFpCzpQp/gdpeUVWEgv2JBiuI8hyvoCl5P+hgJYK
aEkJnRXrQrShos5c1+V9TvNAxZGCfEVawJxugq6ZSHwkIDWQYFgbql0HPlehOE7K9jml+Ptm
q3j2P5pji0xcyz+QKj1Labx3uSent3BxsacvxF/VlHcsEAP/V26XjwssXeGkVM5CyrKQUiyk
rBNSKCOFM4Aew/3PFJx3fx1Cwi2cBKrcZa+gwwEqYtPwA17e0IyXN36KlMcMcru6aBFuWMfF
oIEKW71CxcZco2JnjVJxZLanYmeOU3FkvqdiZ45ScWS6p2K/fZSKI/M9FTtzlIpj0x0VO3OU
iuOp94UJJAZrTKV+yj5M7ZR9mLsp+zA3k/ZB8FP2YXRT9igH5xYCrwYcHA5R5g6R6TmYb13A
aisPaXi0+IJb0gW3Jj1N3+kNmRkOXAekiYB/uMa1lzg6deflSy4zO2IrrIwyvXVgC679dOAx
QExnQO1AlqSEdVDvQJUpyXpKUogxjMWdCKA8XCzvr1GeQ8Gnmi5GKBGILnICYBYLsMmKB6BY
MOCgBxIt+X/gmtxNfuHhw22zQKfaERd6XgQyVTWTaUkkeE6lugywf1loqLM1OWZmiXdWvMZy
JUfF5oqyhRRAJXeb/zBeLbuNG0HwV3TUArsKORy+jgEWQY4G4tueFFu2BTixIXmD9d+nqx/D
kdmt3YsosdhDTXdPVdeFvHwcofolUTrW7Z+5otwUM/UNuuddmgiZoInub5pp5Kt8HjngkUn8
X/48cBTMaRb1SWjM67pcBNlrLOskeUZ76HCxYq6mhlyNDdZL6E5a6IbLmPhvQ7IwMuAU/MH+
EUPfxEPf+LPSOhXV3zCval1niCHylCkBO+Sh/SBJS+EXSVIX+UGXuqljlvB1SdFQl4Jo0yWF
Y10K4k2XFA51KQg3XbLXh7oUxJsuKRzqUhSuuqRwqEtx6q0wdKvw+rDOvAPXiXXgOnEOXOfF
g6t9O3C9LweOBaml9mpEkGRyLPPppETVU7+3bJlMmIiw0FU8HE4gA8a/Pz5hasS5EICnRjod
f2KUnMtzZ32IeBk+8l5v25WcxVy4pZIunQ8DX0K0rIw8yfkVW3KkVdms6g0atDFDHg/nnzmW
NBY666rxllcXq5ZZbjs1a6N4Bvqtd8WwjWzYyFmcPpNWXvBl2YNZXX1BC95nduyZHYnX7uS6
uX/hUXqEC8ANSmm3KI8N5mXhVhdmFgPzf0FZwGNcFxorUIkCnN6Od98Zev6EMu9PJO7yxLl6
RUl9oWRIKBItH2wNO9b4UpKJKRUFOW/w5QUPkr3ha+ACHMknnRLthhyNW9F30fyNjgObegSI
ituPZemkYnX3ckIB4b9eaSm2oPdHVl/99SgXqFmmHP3FnXRzKfrTrhkhhF81TUL7YP3fbm9p
St/cPhTdprcn2Mjaki6bFVv4vrHgSYJlK6lZ/OSq2m9SXnOPrU0Uo3SWolJyyNgonrLdaq3f
ohPRl3/YWzl4aKPDeuajjCF02MottH3SwbFnS4sr/SkeBmYeBrIMAwN0tCln3nQ07Tq2lr+g
o3RWpinUUUFjHfWji44KfEVH/fiiowLHOuqHFx3V18c66scXHRU41tEg3HRU4FhHw9RbYcwe
zWwEV5l34DqxDlwnzoHrvHhwtW8HrvflwKGOppRVKiJjN/yqsZMpXwZ/nCKcntP+P3nqJPfF
7pmiBAavDLhNawIjFD9R7DOtPIDiWb1mVa9+K5+qXuzqwKOkXhcSU5Zudek9KGSGQXjiL4fT
gbj+U8+7FExOfkcnv6Od0MmfQBAsdOBrPHK8k2t5GVN0LhQ36tue9tCN84YvRM8I+Z2FAVNE
o1MFrie8BvnC8+cNvbXNMmSU2w+8xeOPzaU9KC9N83rEmMUikCnABjpW6kGVGlfo3Jt8PQTy
th4w9mJrqhni5UG9DNPnCPpcjxWKMRWP24i8P8iLurO82M2MFqSSkYRyIybSCDTp6+uBqvpy
mZyhJCeX1Qb0E/gd5A57eCOTHJukvP0wQCzKaNo5767I4TeMn2PuqNUxfrYd98x6A3JP/jnv
RTXK3m/ie5kdx2n+g7IiB6nkgN0lplgZM/DrSeqzl1/ocCIf2j6qd7OTVy7KL1WZmvGDpFZ6
v3P1vkt9mSk0aSqS1ATDPF+K5EofU1eZgpU+KhrqYxBt+qhwrI9BvOmjwqE+BuGmj/b6UB+D
eNNHhUN9jMJVHxUO9TFOvRZGobYhEhlWiXfQKq0OWmXNQauceOiyZQetduSgoTC2sB7DIozd
Mno3OnqPrIwNWBjK2OKwqjLObLd4VNwc+YL5v2OKwsHcs1Hh46lKOAxpdbzXcnX4wTqzv3t7
fv+UGp5TWbZckfqMM99ui7bZPD2DcS54sSu8qHsjHWD3xRM3iIMsFwycXg5y815+sR+SL09M
IUynYPWvGJCzMOokjGpUT4yTGioHjcttx9Zj3OWUx8Is38AHX9JICYOySqIldqGINs27nKM+
jVEQSIT23E2KdoPHLUGocYvCMbcE8cYtCofcEoQbt9jrQ24J4o1bFA65JQpXblE45Ja4KiMv
PvGBZLTL5aQqPOddGOpjPeszY6QV5MzcevovNdxd2arN4LVa+2sb7q5tncDglT7wlzbcXdq6
RP72lR7x1zbcXds6iMEr/RMsrbi/tHYXg1d6y1/acHfpq2CoENR0c1KBWAYcoqb/BwBxjjtm
CmVuZHN0cmVhbQ1lbmRvYmoNMTAgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDEz
NyAwIFIgDS9SZXNvdXJjZXMgMTEgMCBSIA0vQ29udGVudHMgMTIgMCBSIA0vTWVkaWFCb3gg
WyAwIDAgNTk1IDg0MiBdIA0vQ3JvcEJveCBbIDAgMCA1OTUgODQyIF0gDS9Sb3RhdGUgMCAN
Pj4gDWVuZG9iag0xMSAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250
IDw8IC9UVDIgMTQ5IDAgUiAvVFQ4IDEyNCAwIFIgL1RUMTAgMTI2IDAgUiA+PiANL0V4dEdT
dGF0ZSA8PCAvR1MxIDE1OCAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczUgMTUzIDAgUiA+
PiANPj4gDWVuZG9iag0xMiAwIG9iag08PCAvTGVuZ3RoIDMyMzMgL0ZpbHRlciAvRmxhdGVE
ZWNvZGUgPj4gDXN0cmVhbQ0KSImcV81y28gRvvMp5gikQhgz+D/akrJWSmupRKZycPkAgRCF
NU0yBGSv9zH2kOdN/w0Aghg7SbGKAKZnunu6e/r75t168Wa9Nkqr9fOiCIpUhfCjlyIMwjhM
VVakQZaGkVp/Wby5ahNVtTQpVG21ePPLSqttu1jC5NAkal0t8C2Bt2+Lj96v/tKYIPEe/GUa
aO9upZb4lnvq7lrG1PpmtVZXb1c3K6X8T+u/L0K1zEBiQlByTerAC1FsYla8eguqdRHE3spH
A//48IufBZGnbj9c375Vq/u/rf/59vFG3T/cPL5d395/WKmPanW7uv/ENmDTOW86VBkoiEJN
xsgOmvCUv/4NXdGBTtIUhTykDe0dHiYMg8JghKIEXyhCXkSzhqDqIIfpsJxCpCO7E3zDndz5
yxgcv/ZBGcSpgM2odzxWwhbh0Tb+MoLhSl3LW1sdvtan7+rf6j0P1BSEHX/I48Cr1a/tlrZ8
s15o1aiFwYwYDV7HQao07D7McZtGnerF8+LdehScYbNRAbPDyWan4XIUkIkDLQXk2ejo0IYf
IxzHqc11nKFSDlbGIXqsn/0EUq1WddXRW0P/hz1EwASg/TKpo7xNvRxZX/+FbZrBpmGbax+L
k2II1Vrvt+W2Vo0fQ5L2MnhHU659DPaDele2UIG5x3MgVzTOXyypIEmRh5mjz+8K/C/350o7
+qhpJk97ppGyqnEum1zx3Ed1FFWs4rAR2+WOnvz/nXQpdoEV7zf8pSZb4C/x5zPUli2tyBtr
lKCIjsMr+6z48cLCmjMi8Q2jPgUfvQa2mgSZ19Wn55JfqzoY5uNUTpSsjoo+O2FhD00CRtBv
A37zE/1OyasEQ20DnUCgxyJVqi80v65eyv1YwsO0j9R7KfkJqS+fdvRaWwWYB7QPeTAQsEdZ
cuBPtXF6oo4Hnlrv+ckzS17IViCpMpsVBNQYfr5H9l5Ufba+8gLZiu2uowNnu5E0o1foyViK
8ldXdduW+AbNpjvgi6p/P+Jz11RNt/uuqkM/+7nZ4oN0nMAbWK/KXqruVvh4/LNVOxp9IgtY
LlBYqv3WdNULDjWw4YzXkD51HBSSMXQq+NmJ/zbU0ORlaM20xpi86HEm73FG2sBqF6gPB6xS
qAx/mRe6D2QUZJo7pzXLIJj1ICjta11jO4e0df4y89QV7D6HHbYyzNo0pK0wsBln2wovTGly
F5zsGErrY8vKsiDN02yqa0YNaYl7SErZ4RsfD+XvUEGxd4SWW2/UIxRUAqmNsBd04nIYRDkg
/URdMTrr90+wDJvI6SsoGdXfaAEiLzgHFl5RM7gIfCOP9H/h/nJYjyjxxTfoeMnROH32dYTN
V1n4y+MghtlpmEJ8VBjEkD36J+D7qTTPe2mUTsTaANamztUozuNeDNwGAXI0wcQmyN3WTQyH
ezAP9Cg8k0dAhX5gHsVj86GZmI/ND83H5sx8mk3MxwD1PzCP4pH5JJ8sT+IcKIVz+U/Eo7wZ
EYK7YXyZmBnxOO4z4nFcZ8TjsM2JR2GZEY/3NSM+I2LzzCrJoCnmwsUGnJUuhAdQM8BC6zJF
gsB89QIgH0Fn/0xP1Tz7AOKdjKr39W53sGsmXU4wgw5d3zOynujDkcB2nuCRa0t+2doBJQMn
7H2Rnadaedl3juZgekOhNCfgPA0wHSA5O6A2IQFy60MbrQ57Pwcfnn1oTEBjtvT1Sv8nhpl6
M+EZ50DhIBu3oJHavjAD4OigCskXo+tBAL8agy34BohxmF9qfSAzSZ+0XFD4vSBjBqCzY5CQ
B1IvIvVfsLchRYB9Zd5WVTz7hbCz5I/9VnS05xADyc20nvRP2rtm+3AzgxAajFqMZHvvY446
Wxx0a2trGQWL89QCFeZDMHPWXe4hBrm3gRqv6uYrfdQ+JmcDfJg+Z0qBa653NBNHn8hRpun4
7PDmE3svUM81UYf2u69ju//5pPOLICbEWMeJmw70x8NwBFKi7JpZIX1tLFeYD0gyBCRhlX0c
EopDCnFA7qapWOAW90qP3UY91a7AROkIcvnoIZvV6EjNXwGmzebpgmWfnYB48FGLjw9Y6qgN
Sx2fFT86+sdSR91Y7IYZdEK1qPF01jOh6ANQ9VEZRTfFcIL72ChaYBwaeCDuQbUv9JQpr/Sx
28gCR/8Y3zyAX6LOck+Prc+dCBqvN3v9sPym6DkiGIoipiuKpgykIsnB0dRFG0TqpA2O1ZY2
iNhNGxzrLW0QsZM2OJZb2mDNO2mDY72lDSJ20gbXcqENInbSBnfoOTFmYA06hP4QT2PvmDAE
1zFhCJ9jwhAf14Q+Ao4Jwx4dE4AlzHODOC2CLB24wXAvsZc9M7CCRz/zuA/hzQTPBLRhOo5w
EI0mpEnlzAAzIKSFZ+m6CdGpNkOvk/Z5LE9dU2FHQ2BDcl6e1O0DnmAgA+Vmc6pb6qL8rwgs
DHTEcjifszeWI8MjtD5sOWwEby87HzAPjRx7/MQHAJshRPv4zTcxItButwRT2vtMy/b0L5Nl
Co+d+REP8KYF3q4B54F7UGtqiXpUPpo6fMVuCIZO1C1ht8fDqeO29ukcniG3adFfSXWfNh31
6CyUBrvuocKbGXVK/Ecml2EKXZetooc0PYE0TU23wJspbCKBXHNW9vTcyJQz6nJJHY5y95ow
h+6FXmp1R033GvOU9zzjPLk96GqpmtsNagMowxQA3gJlRUhs6hM6lzHoxm7Q1WmvMWaNu/Kp
3qmWYOrIrpZVLSAwSwW46/ebRiVr8N4IqdOwNazZjDAcqBeNdVDitor1mPJombZxZamPqxEO
2mAWNHBb3O5BuDRhJJyhrpERnoQ4mTIrwsFX+ththHI/8bNG5phP8vm/EgmLkCaIdBT9BCHj
DM5y7EJIkToR0rHaIqSI3QjpWG8RUsROhHQstwhpzTsR0rHeIqSInQjpWi4IKWInQrpDz4mB
Zm7xE5yZxH1GOAR1RjiEbEY4xGNO2O92RjjsZUboRMEozyHAIxTs+589xtGAgvcIa3BE6Jwe
OyK0dLspRXDn0+3r2kea+8CXqx9B4HCMz3utdNqcOm0KnTbz/gpeeOqZcPWE15iIzq8nE6mv
j26OorSyZuhqtfnNXxZIcCtoldAo4YoKPRJW5tR5NTLdFcHuI6H5mTZ7260I3LHVoN1mSx+v
9E+QA50AG2dGLuXS+fAbgA2bOX90ECKw+gXHCtxXwX0LjZ8mTSey+0gF4ej2Rreou2vECLzT
wXWLx9oWux1ucw82Mm5Idi8WQyGqJk3+jytuD1TzjTmJexgwsb2//esVyyLGuIAK6rY1RDmB
9r4mM5F35SOuPpynr4elUFQhghiOEvCGzxDd1Ks7rj68F2L5QfFpcJCKL5mH4x4xcCdN15S7
5g/GCHSNh88hlzzxrsuuDKhpDxAoUSR/+3oL8wEBcZ9YB1AWFt/ow8dtb1Szp0/Mf8E7y+eu
assBY6kQJEvtC6Ua6w85E2JYQQBXytFICHHxQNFI6yP9U1w/53uMsgHAMxvujC6AmtgdJmiD
BQ5Dpz85ozwD6S5KLUG4RD1SmxBxQQDM5SipK3Bfk/rnhvnT9vVEJYElssyIa9GZYs1AIHKI
wpQN9HTXpBPOBr3pvbwwwKeTzA49QnLWNXgmYYuq7iqeO0B0VGRDb72AaJE6Idqx2kK0iN0Q
7VhvIVrEToh2LLcQbc07Idqx3kK0iJ0Q7VouEC1iJ0S7Q28TY3IHRM8Kx0G9EI5DdiEcx+NS
ONrthXC8lwuhG6JDuOtRkbsgOh4genQnzahfJnQnhYbW8NfQhJDjIut+AmDSP4bpiytHudsp
gdP/NF7uPA1DMRT+K4w3S9UkNy2MVIydYO2GGDohEQmJf48fx85D9oWJiiOf3Fw7n+1J26ls
HtJQucHVHXl7P3PFt38rjFv6sC9sIqsps2++vwOCL/cZPz+ZBE/lW1bHD/3fl0b/dD3/uXUw
82/bQV8E2PHuOK57HZayUVYJ7XTUXR6AklNEZcmBdylreDKRVBldBlkSKVYYVGX/4HGJbo/t
uX1t7+k0rDrU9U0P9DpvFq8Fq3Kz3hR63OxzR29bCz3jKnsgTTQ0z0w40tkr4Ky3ebTpSUaV
/76kE7ZiVtu98KYRLGbL+oPk7HagkdP5mAJW1RywcbQDVuUGYON4B6zKOWDjcAcsHp8DNo53
wKqcAzYJN8CqnAM2vXpNzHRYiHUgDqzVYaRRKI3NVU4q1EZSwyebnJhbziG3ch7am5zYW0lA
bpRE6G5y4m4VY4dvVExob3JibwUFuVFQsTvkzB31BrlRb6G7yYn7H3LaRIeBdqMj9lyZ5oU8
G9IVg9EvtNsKjwplbmRzdHJlYW0NZW5kb2JqDTEzIDAgb2JqDTw8IA0vVHlwZSAvUGFnZSAN
L1BhcmVudCAxMzcgMCBSIA0vUmVzb3VyY2VzIDE0IDAgUiANL0NvbnRlbnRzIDE1IDAgUiAN
L01lZGlhQm94IFsgMCAwIDU5NSA4NDIgXSANL0Nyb3BCb3ggWyAwIDAgNTk1IDg0MiBdIA0v
Um90YXRlIDAgDT4+IA1lbmRvYmoNMTQgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4
dCBdIA0vRm9udCA8PCAvVFQyIDE0OSAwIFIgL1RUOCAxMjQgMCBSIC9UVDEwIDEyNiAwIFIg
Pj4gDS9FeHRHU3RhdGUgPDwgL0dTMSAxNTggMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M1
IDE1MyAwIFIgPj4gDT4+IA1lbmRvYmoNMTUgMCBvYmoNPDwgL0xlbmd0aCAxNzIyIC9GaWx0
ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJhFfbcts2EH3XV+AR7IwQArz3zYndxJ3E
zkhs++DJgyLRjlpZ8oh0mvxIv7dnARCERUIezYiXAyx2z2LPgm/r2Zu6Vkyy+n5WiSpnMX76
popFnMY5K6pcFHmcsPpx9uZdm7F1qwfFrF3P3rxfSvbQzuYYHKuM1esZ3WW4+3d2xz9Fc6VE
xj9H81xI/nHJ5nRXcvbx0r5j9dWyZu8ulldLxqIv9e+zmM0LICqGkUttDl5Ywyo1hpcXMC0r
kfJlRAv8cfM+KkTC2fXN5fUFW97+Vv91sbhit5+vFhf19e3Nkt2x5fXy9otZA0GXJuiYFTCQ
xFIvptehJTiL6r/JFSlklucEmlcDXVJpFnCR4EpprpJMVMpwpSkhs8ZzuiPPUwbH4yzmxICM
RcHZ1Y+u2W+aDbvctuvD9+b4k/3HPjS73YF9ah+0v1f1TLItmykpRZlKLJSKHOsmIk3JR8WO
zex+9rb2vErjTKjyxKvTCAciAtlXqZA2+26GjHvuiJ40zftEpXoH6Mil3QKL5j6CH5z9ypbN
utP3W/1/2CNMJdKThBQiVbKAH9ZmMngsFDkALrR3YAFs5CUrpUhLhlXx39PwMhpZSJEpCkcq
t5k1FSameSlkGReT2e6DrX8xIaZDiHYzXu/XO0Qk+fOmaSNs7vWKLo3emfqFZKv9hil2r4cd
8erwGCWU+06/+YY9IXLesNVX5J/p2WsDbfX/YS9ONy75M06m8jKjVFm5EipdCSlbQjvBbg7R
XCcnmpcVeWAWgWcSEzw2TH0Xrr4LY6Nuojk2Im+7aI5g3q1gB1G19rWxBsplpeC1s3a2zAy1
2l042RmVaJ5aYywXcR4r35awRXbHr0BVwn9EBX8Ce6inXk5ejo6dTKnM+LBo2uddp12BpMS0
YV7ar5zDd/z2a4t1Mt4cv4eX0B5xz24uEpUlpxyEwu8jWjSPkcrA6MrQcPwnkomouCUDlVCm
cFiyvMioEuKTQngVLUuHJvkJLJUUSR6cTTBJkYWh11Rp3gCVKlGGV1dpAnlycFbBGR9P4gTK
E5xOcD4sDyVEb/BxtC0vutH0qvCDy1GqysdT7U9weprH/vSsQL/y8UxCxsLTX4G9tCkLqgSK
N87LBOzTPgH7tE7BHm0TsE/LBOzHNQG/rV/tNzm8z0uvg2auWkvbUSTEEnJOoqWqDJuQf6Dq
UBDcOZbnOxKfsr8c+tGPVDoJ9BjFVvEHtjW4fWatnb3vzHvWncxfGZzt+zf7kVh6nVANjb8y
bm+2R6jS7meEQoHirg/7CF2Hm3+jVx/pQJDhSJPyRZTTYqcC6q3gFrB6Djoy9DDY/rM5bu8j
EuKfEc5IOGN13yCKq85cmxdKeuL3qTjCb2oRGZGLNgul3+7hWgZr24NBzDM72sdn/dhFkjJy
ZNt2QiN1Zt2hzhKkCa4swQr0bvR1S2YTNE0cm3BtzKi1uXQG3JkLwlUUrl7Q9uuhadGmonUM
8wU3/455eEfMo20tQJKI5rSaMWWbAg5bWVGS/+CuyLyDCWP2YNJXbgY/8qDgGjQsuNOzneAa
+IzgTs93gmvgsOBOT3eCa+Cw4Aam94Jr4LDgTk93gmudDwpukHmTFznoLSwW6pT5aXxgdhof
qAvgjptpfAh+Gh+im8ZHB95eTjN9NrbnXaqB1JV3bqpBUenknpjWKDQqpm9agRrzIWIHPZKe
KGhmyh+MQKG822av76nkUXx2rHkHuZOl1urpc6V3uqI7+43UHdiKmVPWE6kw6SMUrYLZLQ7V
OV8bqUxQsAlcJrGEpB5XpG9QBciOLwGeVFqp6Sg4yVd7fWGd9hnSs9rtYLnUGqz4omUPesCR
nFDcjnrW757sFE/cfBkd8Wypeza0dFt8I3TsXou/ZezIup5z+8YM7gzV9t1Ws2zYffCaxOgM
Kgvv0ArRLiB2XXMkGlO+Wjdi4Gg4ivatBmfOgrIR+ngYN5uM61RX3ERRUruxXxd7/bwb46d9
yD9Bu+6g7FeWJjylLiGpHYBBoieH9tPz6ojEVZQ2eLJ4kf7x/kIjbrbfzVaJYr5h/b4xm30i
p9SwZFl6jD62uk4UkoAuRQeG11rFqEtklVbwQJewaLBLBGb3XcLC4S4RmN93CQsHu0Rget8l
LBzsEqHptktYONglAtP7LtE7H+oSYeb7vKROZauXmJIDNp4ZRLXTBj2b0dG6Dpw27dJt4PPp
Hhl34LRxtxcMfHYvjGw7cNq22ygGPrtRxrZ7MGC730UGPruLRrYdOG3bbTHLybktNrLtwGnb
r8DhLg8BMufbR1/MoTT/DwDUu6MUCmVuZHN0cmVhbQ1lbmRvYmoNMTYgMCBvYmoNPDwgDS9U
eXBlIC9QYWdlIA0vUGFyZW50IDEzNyAwIFIgDS9SZXNvdXJjZXMgMTcgMCBSIA0vQ29udGVu
dHMgMTggMCBSIA0vTWVkaWFCb3ggWyAwIDAgNTk1IDg0MiBdIA0vQ3JvcEJveCBbIDAgMCA1
OTUgODQyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag0xNyAwIG9iag08PCANL1Byb2NTZXQg
WyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9UVDIgMTQ5IDAgUiAvVFQ4IDEyNCAwIFIgL1RU
MTAgMTI2IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDE1OCAwIFIgPj4gDS9Db2xvclNw
YWNlIDw8IC9DczUgMTUzIDAgUiA+PiANPj4gDWVuZG9iag0xOCAwIG9iag08PCAvTGVuZ3Ro
IDE3MDYgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImsV8ty2zYU3esrsAQ7
FU08CJJLx3Yz7rhxxmKbhScLWaYTtY6kinKT/n3PxUvUA3Km7XhGpnR47wXOBc4B3rSjs7aV
TLD2adTkjWEF/uxDU+SFLgyrGpNXplCs/TI6u+hLNuvtSwXrZ6OztxPBPvWjMV4uZMna2Yie
Sjx9Hd3zX7KxlHnJ32djkwt+M2Fjeqo5u7n0v7H2atKyi/PJ1YSx7GP786hg4wqILJDk0qbD
KHxiqV3iyTlSiybXfJJRgV/fvc2qXHF2/e7y+pxNbn9qP5zfXbHb91d35+317bsJu2eT68nt
R1cDk67dpAtWIYEqhC1m61AJzrL29wE3Qtop45+UKq8kEaOrXGtHjB1lTdHj8EjDLBlGWZQF
p+kKkRvOJl3fz5cLdsba9XTRr5brjR3RVTsSbM5GUpe5kgLZiQMUNLkybCxyydbd6Gn0ph2M
RVXIWe+P5XAS9ckGq5KS2NgYIYpAD0qL0pjQC0XZ7/lNpvOGX4J8xd+zPjOYW5fhVe6e3ec8
A1d8uXDfWPdt7p429nf20G2+2rZ13YL5xyVzqSfZWPE7H7hZ+hIvKxDmUrDn6UP3jJyzz9PF
p24v2efuSx6XE4altYkN3u+tfUPKuonrrY7rTfr19pyzd8tsXOYS0eO6sb20+TETgYABTW4z
VHEzVC5H22VjTdRssjEmfzFFHrDQ+59dNiFz0Uj0a0v6XjuLg1Kidj2ZbNyW6la9S1ahr6ba
z3Ukjc2iw4CFcQO+ykqM7xtI1XzVzTbdI7vr+qzkL2if4s8bP+QiVzV2/F66Jo77nt8+IAzb
tFv/hSSDtgwCaAdicKjwQpkxROhOrcR3DH+8jb9Hgi+ZpIFPHRvrPzKhsKA8J9hntc413kbb
cuhJkWt0z37aDfYqWtcRVWYPFlJguyajCa51hKFxtBEHL0gt8zpdXWqVy215yGSxgytI4ony
BA/LF3KvvJYny2u5U95Ue+U1JOVEeYIH5U1jlW2Llwa/p6u/Aoe+FQ3syqMYb6H3OpPAI/MJ
PFKbwCN1KTxwk8Dj7BL4m/ZVITdVBWKckNstYZqwpZvGbUQBP0LTScNkU2Ix8vMFu4HWlvyO
vZAU1fith/aSmd5cQqkgTbBqAcWy8iL5MuY4Ln9BN2ejoRVOH//KakR3GXjg682cFKHmHcNu
FZRT4du6g3Lb16YL+48t3f/OFWt/QCan+y585eKms448wgctfQ5fCoaCFWPgKBpycAf3KPmP
GQiqecxqRxrZgv3aMc837AWvQzsQCvXq2ZSxvluRDwjSF6jLdNOhANYGzBAdJK4aaxKH3kOZ
40mm8CcZ8jU31Mo/u8+51Vg7fXjDE01BOZo0ptRNZ58d4tg4Lqm+C6HQLmH5ruFAMSshonpH
9xLKhWPFVFqRbf/WredPGZ29/s5IUDj1rCLB3diuwIGJXclXU8vO0Ir2RVupUMf4OvZgKGiW
jJYjGS4dmIhVxRc4b4AmNnXA2i3PLvjyoJkyulnh3QzOhVPD9OGZziCc2NOW9pI/MsevX4Zm
y6/eTSriAVf4A+52LQqillYJrcUdX8RcTGPPFlh5SomBn1sr2zoSKMLRMuU5Hk16TiI6eI6H
056TiA+e4+Gk5yTCg+eE8knPScQHz/Fw0nNS4d5zQnjKc9LUh8ZEy4GqHvB+AA5JPQCHlB2A
Qz4OwcFsD8DhXA5A+EfCNYoq3u+OH35lPPd6z/hA+05iD9FVrlvYf9BxzAondPvteTNfuahn
J4/SyqNw8qheOTpHkSz93nVn5NIrAeneIiOJsEpAwJqsqeH+Nbb79U8X8mJD5rvYo8N2jSCK
kvRH9weaS0UxdO7HPYPugHTRwGQxmfDD0r2GCdPBnm6mElcYkkd6rYO7zfudSspsr4x+qlB8
orFjrbVZwS+grQ3xRr4FqamsXQhrF5W1i8rahXZ20Xi7EM4u5NYumuE8/7365jQStXddwQVG
mvK/uod/ckRZJyH/tz+lXMROo9yy6HXZkSctebUjzzjyhCXPcPfsPok86cgrPXnSkVduySv/
f/K8QchcCcr2HQYhqhOXEo+mDeJ4dDQIB58wiOPx0SAcnDaI4+HRIHz5tEEcj48G4eC0QSTC
g0H48KRBJKl3jTHbU7uhjDtwWZZ5k3SXNEpd9eiJrh4vHfBE9tB1D5/q+vH8AU/kD6vCwydW
xfH0AU+kD6smDP/EqjmeP+CJ/GFVefjEqkqk93gqvV91IX161R1PH/BE+ldgd5cUxanLZKmx
4PxlsiBF4kGL/hkA8O66PQplbmRzdHJlYW0NZW5kb2JqDTE5IDAgb2JqDTw8IA0vVHlwZSAv
UGFnZSANL1BhcmVudCAxMzcgMCBSIA0vUmVzb3VyY2VzIDIwIDAgUiANL0NvbnRlbnRzIDIx
IDAgUiANL01lZGlhQm94IFsgMCAwIDU5NSA4NDIgXSANL0Nyb3BCb3ggWyAwIDAgNTk1IDg0
MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNMjAgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BE
RiAvVGV4dCBdIA0vRm9udCA8PCAvVFQyIDE0OSAwIFIgL1RUOCAxMjQgMCBSIC9UVDEwIDEy
NiAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSAxNTggMCBSID4+IA0vQ29sb3JTcGFjZSA8
PCAvQ3M1IDE1MyAwIFIgPj4gDT4+IA1lbmRvYmoNMjEgMCBvYmoNPDwgL0xlbmd0aCAxNjk3
IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJjFfNcts2EL7rKXAEOyOG+CFI
Hp3Yzbhx7IzETg+ZHGiZttk4tirSbdLH6KHP228XIEXJotzRDAViF/v77WL5tpy9KUstlChv
Z0VcOJHgx4siiRObOJEVLs5cYkT5bfbmXZuKVctMiWhXszfvl0rctbM5mBOdinI1o1WK1V+z
z/JjNNc6TuWnaO5iJS+WYk6rXIqL07AnyrNlKd6dLM+WQkRfyl9miZhnoOgEQk5ZHKwIgrX1
gpcnEK2K2MplRAp+vXwfZbGR4vzy9PxELK9+Ln87WZyJq09ni5Py/OpyKT6L5fny6ovXAadz
73QiMggwiWJlrIdUSBGVv5MpKlapc0T0W9twKc1RwJ/WSaw5ViaNC+1jReYqSwLn/ZIsdwKG
J2kiKQJKx1qKZR2l+G/b5ulRnD82XWThWFM9NH8zoQobT49s+1k5U6IRM21VnFsFpTZ2QhkT
W0v2arGpZ7ezt+XIQpNBUL5v4Z63cE0lR6GgbawCFMYBstb1qbLp1uMAgkV9y27Az1XHq4af
cPZfgdjHpneL9cAhpWKXC5jsBCTZfHBom7ZdA5UDL1uIiPZg3XdvnsVpkdhjKWV3tM6LAXn5
gDwdkPcQi8unaM4eRfO8gK3Sg8rEmcKBkXxfFtlQFpmXUdbRHDmTbRfNMyneVZATZ7IN216a
snGCzG2FHQWnjzhbCxs7X1v1uvWybFxkabEv64CYLWh55by9Z8hXJr+jwqxcI4n1jVjUbZTK
58ig6B66YDFilxc7JpOQYrD7s7y6xjHUa735E0L6ct89QKUI46DhmSTDRDSg3Kj/Yf58e55w
9y3SZHjlo7H5GikTFzLEBHjLUVbgdgWij1IhpI3w9io1zweqcXtkpVVs3ORpIlPtBrIyRZzs
MGiXoE4nz2unxsbZ/eNG0XryOJGLrXUKmSt2as2ibR9Rb7UZq3fZnnpbHFVP5JH6NEfPGpFT
uKOmY/cKeZQ23BaeCnNR+C8Sc4g+Dvwh+jiyh+jjyB2kF8fPj707RD/SBfs27dANs9EtZM22
JxtfhwqtSxcpQCjP0ZOlQEuWLQq8kGL95Bf+SYTrBzxqcYv7SqL1KdTURlRiXRFxEyVSPDFt
qg1yVZqhk4Yu2DxGDt1jxc00k98i3OdKrv1b1TXXfvXwI1I5Go/oGf2x2yiXzR0vn/m5QfOU
9Y3nERcRdVQaDrRchIovf/L6h2kiCXdydw9uB53ipmkhDFdulOD4HW9vvMd1LXAB0wZc91w1
c/m1fzbcEHu+UX8bXZF6iEQSIrGuNhV6laKWDZFWdvWG+iSSUZMow5YYtsqGtWcUjaeLKvwH
/puH2gsIYg53WjPqzGS/g1Qy4o/nqJCQVMhVzaklNwVbmAcWz+6fFe/c0ZkRTVThv65W91Fv
Q8hBogc05F7/5UmELpTKD61AOji6ghOeyw6uFjJsBvj94yEqGESIe8fjElATzvjtHZ1qiLsK
cYdHCduL+xH28wD5V4QhJ4PAe/9+ttk80bVMkL8Mq665hUPNyquzjElm3oGZHUX3I2LBibO7
t3uOxknluXN1cWqUP4g6tRm1FMnx0dDECb3gNC8jysgCqVEE92ef8o4iSCuynG6+rnuoRdPt
DgMvxpRh1ElDSvw8kvFgShMKRdVQVHtC97z2+wI1kjF6/X54ReWm+2FJhulCh+mi6rqai1/7
4ncSliINBoIbxoJlfLsheC9LaoBTEmyvvyNAEMilqGXt/wgl4rpafeU3IBt9U/qnryQ9VSrJ
8G2jw1jbNh01nlT2oEsZdCnDSUnvgYctzTv1EIX57mBp8qEdpvtIdhxzHjUpxRRfzQmp7ni3
f3+lv1XQfl03viv5piao3si+D/0cRqf3Jsxe4IDKpPAC+ayVJFARFtEgUoDRyoXP0k3dYUxs
ngJDy/PjM7+s7v1edSCVEzXAkSY890FRfRV01VdeUBwgcvWCHl4nkqqGpPbfKlTHqeSiTn2Z
I8o/CJyOMUhUEchr/wfd1Ik3VRf2N3vTMLqaJYCeYo5NjVGjIHOUR4MofaVNTppMnB40D54d
5kymHhkzD54epkymTg+ZBw8PM6ZXPT1iHjw9TJhMnR4wDx8uxqonx8upaHu9djtcKu326akd
jWcvTk9TKZOBeiSVE7p7hgnxfbID+Vi2JxT0DBMKejwE8hFATMjvGSbk95DpHTiCmQkFPcOE
gh5VgXwEVlPyi6MO9MAL5GnkTYjvGSbEv0LGp8HhD4LUYDpw4YOA2o9v7zv9UPa96L8BABzD
VRAKZW5kc3RyZWFtDWVuZG9iag0yMiAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQg
MTM3IDAgUiANL1Jlc291cmNlcyAyMyAwIFIgDS9Db250ZW50cyAyNCAwIFIgDS9NZWRpYUJv
eCBbIDAgMCA1OTUgODQyIF0gDS9Dcm9wQm94IFsgMCAwIDU5NSA4NDIgXSANL1JvdGF0ZSAw
IA0+PiANZW5kb2JqDTIzIDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0Zv
bnQgPDwgL1RUMiAxNDkgMCBSIC9UVDggMTI0IDAgUiAvVFQxMCAxMjYgMCBSIC9UVDEyIDEy
NyAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSAxNTggMCBSID4+IA0vQ29sb3JTcGFjZSA8
PCAvQ3M1IDE1MyAwIFIgPj4gDT4+IA1lbmRvYmoNMjQgMCBvYmoNPDwgL0xlbmd0aCAyODQx
IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ7Fddbxu5FX3Xr+DjTFFNhhwO
ydk3J1EX6sZ2YKlosUEetPLYVmtLgaUk3f6Q/b29H+TMSCJle9ssukARxOLw8ute3nvO4ev5
6NV8roQU85tRUzRGlPCPGk1ZlLo0wjamsKasxPxh9OrNthbLLQ0qxXY5evX9TIrb7WgMg0tV
i/lyhK0aWl9HH7LzfKxUUWfv87EpZPZuJsbYcpl499b3iflkNhdvzmaTmRD5x/mfR6UYW7Co
EhZ5S8vBKfzCSvPCszNYWjaFzmY5bvCXi+9zW1SZmF68nZ6J2eWf5n89u5qIy/eTq7P59PJi
Jj6I2XR2+ZH3AKcdO10KCwtUpaTNaB/cIhP5/O+D2EhFLsOPKpuidBgYbQutOTB4Ntng7HFo
4jGtgFOWdZlN16tdrosmWy3uV//K68JmC9+xWYvNjZjxl+9saYQ454G5hK4lte9gPZy0bsmN
yXwkxUqMVFUWxkk4EgZOyBrGGgFDlXhsRzej1/OBA5UzeO4DB449l+XJtKhq2LL3Xtvee8ve
X7U3cGidiVm73FFrRX/B418EBL3QfBmqkMZZPK6sjTl9D+N+sJKmwcE8pBzOhwTZ5WMNCbGA
LMt8u+XtbGGtlKIfHVmA/NAVHuNDNvmCt4gLYMqqbA1ZDW7Aqq4wGS8KdqcrPViVIuEXALer
7J+5zT5BJNrrLs/3R/NwCNv28/2OzmQLpVwjDgITOS9tZni3s+VutUGPNZy0guLwJ4RmrdUz
Fhv3h8FLfMgVpyHV6+M/clipybYiZKCDnWC0VRKTriy0E2P6S6n3pNW5zgpl36ihWRpZuPRs
aVSh+umytEW9N1+Z5tR8ZcvhfCsPplf65PaV3t++0gfzNTh0Yr62djjfYEEMzHBZXNTx2U+Y
B3FXzltVBbV7HNmYfRi5mH0Ymph96HrMPjx9zP56PsDoOAIZ5zpiooy1HUtUDEAXlxfil3yM
xcfZOv9DxyIeX6A4/zad5QgPc6jyCn4niLEquwjfCdQYh5085fk9Zy2Wnsq2WyxCB/OxCAHM
cTmXvckVsqFEAInBQFjOr7bcIH6tc/7fcmXzh2i3u8VP+HW/2t6hlbnhGrtOgRIdWRYQBcmb
TC+mczqSzaZnucRYvMulhBNOcckq+5G/IDBAM9lbgaymFGSvzA5RwDSugPAm6txbk3WemB3q
3JvTdZ6YH+o8bJ+q88T0UOdh+2SdJ+aHOvfmVJ2nQ8eBtX2ZG7zYw9DF7X1o4vbe97i99y1u
708ft0MhJ8pXHcgnx3lZG1vv5SWyDeZlhQoyh5xWmJeo+n7kLypYB3npBy0xT2W2W30BTeiQ
9jH9IY+vcmSwDRfofftdp6EMHgV8UDDKiLo8uN8jH5S08HPgBNNmBwiVL2EqfJM94q4mW6xJ
x20fcunAg9WOCwgwqrQAJoeK4AjSplD6MH+1IyG5IDyoCWSwW8CyDSy7JUC75b4BymgdlVfH
7F91bhi/8Xu6CY0yoGZ4+9JyU1zBGRrY7953HMW1biQWfK1PBxWogHRp3VQ+kg8DYUMtL//F
FUQRZPKypTsm7Cs7qIZDaLiho2AevSIWy2X7Cc8MYg6hFBv3uSSpuMKImsNA64y7OzrBaEnn
BnzysIVIYRhuCVPdgHoO9Va4jj0iKYN6po3YRUfis0TOgATCr59zRZ+b3d3A+iioQGz2Frww
eGe2O8DRJT/r2IFCGlaiQWp2pw1a//I9kp3LJhdiNiHq1KcY7jD3fCQi6chdEL2uwcTrxe7l
e89cE9bmF/kYOfvKf755MvjP2rKvRRIVYwi5jkmKF6gJFvaAnQ1eQ1qMv/DICRB6AoNW3LOX
7IZQpfao4ghVKkIV6tv3XnXZ63xpYZqq7Fr80LafGJhrECpfqLeFFZWE9WrImFvq2r+nVH7E
cy9kG7hX4cYWTgnOKSQBcA4qxFJJTx4fCfst1EniBdZ0EOG10QWVPZLJTY6vvdUyQIEkKGgy
cb695caHC/ATpEL2Q4609BFr1bAiqzupFCLWgVHpwWh5v9nmhqJDNQ21L3xHjiXNbf67opvY
rPPBAzQ87wAHXV3HSm2g0ipSYCmVxta0SovP7lQam0+otPj8TqX57ZMqLT69U2l++7RKi8/v
VBqbkyotGboQWB00nKwigTu2DsNybB16fWwd+nRsHZ752JpUZhoeVs3gYSXrruLqIdobQPsr
quEJ6jEJj5uaiGOsmhoVGRsDS9fM0gCcAROQZu6Dbe+ZdVCXew+2c6gBQg2d1DYRhPxtSDb2
wDw67z4bBYat2fM9JOJIN6hxrzy2MNi5bIo0FOX1sqG52dm7CICeZJlvyHQD7/4jovsvM0Dw
+PeL+xHKDFSAQGVtH8ge/zU8NXX0qYn4761J/E/MDvjvzWn8T8wP+B+2T+F/YnrA/7B9Ev8T
8wP+e3MK/9Oh48BaglSyOnpHHoQubu9DE7f3vsftvW9xe3/6uD3NBaXd5wLCBlVUVrshF2jg
giD88XlmOti3DPso8VRlUQbSswseXPdJzGcVKzsV64uSZGpzKFNlxt0sUy3J1JpkapMkiCOB
+ftjiV/xDDp+iL3wdfEbsMPz8R2Wb7Ie5HtRYbyoQMQ/52G39PnS5+j/nxtPPjfgPSn1E68N
Le0ptmFrmm3iszu2YfMJtonP79jGb59km/j0jm389mm2ic/v2IbNSbZJho4Da3o0N81h3CLG
PigRY+9yxNj7EzH2x40Yk9xSVQAfrueW52jes4TmdUQW2Zg1r2eU/WqraEhHLQzsEF4P7A3U
TJsjRlEd2OyOuj7T3x1UgMuuN19zZYBc1tSJ4IIDb/nrV4DLt6eaY3Z7AekweMjahsBJFTBw
lcNVa4BfTHyMG8ZHbCASFkKmJPzseIjHi/grxw4Oc0AoiZM/m1pe/u6Rw/STIf0qn34W0y8E
KfLO+hb0mPLB02bDP6EG6i6bXNVRlZJIVA3kxQLzQkHuErw/4JXVAO3AUAbuin6E/72jMS1P
ENu7z74fqEVKpAL/+xUVFzCTOMehSBpjvPnb1A3WXbrXfEDK6zq7Fp6OZKCjGhuP3syWT5vH
XSws0Tpabrhi+G+7BBblpnhGncJlHTf+J0Mc0up3EtigGgANKlfXsadppQcvlCOx4K1JsZCY
HcSCN6fFQmJ+EAth+5RYSEwPYiFsnxQLiflBLHhzSiykQxcCC11slQBoMHRoV5XCUyVmp614
Ld568lqie4cBieXDvXnz6XuLbhAGJDYIFxscOHWx0fXDgMT64eaDAydvPrpBGJDYIKSGN59K
jejyYUBi+SfMSWmnVIUNknZc4a/mc1kKoFgICr8ZDiUcgxi/gRCcdi0ios6+I1wBhJCgvUoN
hwH4AFGsILQnDyO1KxSdRuK99kKzMr0SNIxO0xux6M6p+Jxws7apYbXwFJQDtTJfPQAS83sJ
VnLZ5ee8ApDHs+776ozt1yhV9+RzvJCg553LlsvP3HjcitWam2LBv/7zZ8b+MOMGKATegQDr
9NmG0T/xjx/1Bd51O2/Z0Yx2+8fBpEOj+Lq6vxd+jdbvGNzykUEVakD+lN3lyWpPyeVjlLGg
gGAVQ2pnPgFtcxAcWxhURF1wat3di9J8L4v1NV3LuILjGFsfSgqvID1V4ebsGVCTeDfj1lV3
fBcuRZeUKMlLIYbEy0USb7LVbovpsR8EKOWm1IMYlCYsUxleJtB6A08HDslX0ncabhTJXTzk
quYUUkjH2wWPuuUf3y1875rYnNtbSLZ2K/zqd7RaGz4feV6YRsbtJz/TG/1QsfTd6zVwOfet
QlcRKu/fAwDb/M/HCmVuZHN0cmVhbQ1lbmRvYmoNMjUgMCBvYmoNPDwgDS9UeXBlIC9QYWdl
IA0vUGFyZW50IDEzNyAwIFIgDS9SZXNvdXJjZXMgMjYgMCBSIA0vQ29udGVudHMgMjcgMCBS
IA0vTWVkaWFCb3ggWyAwIDAgNTk1IDg0MiBdIA0vQ3JvcEJveCBbIDAgMCA1OTUgODQyIF0g
DS9Sb3RhdGUgMCANPj4gDWVuZG9iag0yNiAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9U
ZXh0IF0gDS9Gb250IDw8IC9UVDIgMTQ5IDAgUiAvVFQ4IDEyNCAwIFIgL1RUMTAgMTI2IDAg
UiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDE1OCAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9D
czUgMTUzIDAgUiA+PiANPj4gDWVuZG9iag0yNyAwIG9iag08PCAvTGVuZ3RoIDMwNjAgL0Zp
bHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImMV9ty2zgSfddX4BHcWjEECN4ePYl3
JrtJnLI0k4fUPMgSbXNGkV0incuPzPfu6W6QoiTCTqmKhNhAd6Mvp7t/Wc5eLZdWGbW8nVVx
lasEP15USZy4JFdFlcdFnqRq+WX26nWbqXXLmxLVrmevfl0YddfO5tic2Ewt1zNaZVh9m33W
76O5tXGmP0bzPDb63ULNaVVq9e6N/6aWl4ulen2xuFwoFf25/O8sUfMCFJuAyRtmBy08Y+uE
8eICrE0VO72ISMDvH36NijjV6u2HN28v1OLqP8tPF9eX6urj5fXF8u3Vh4X6rBZvF1d/igxc
upRLp3FuXKYKcEkTwxJZGMnRKlr+NZv7LXMTmyzPaYsQDpYzlg2Cl02qOMvJbGkWV1bMJtYx
wyWMXKJUuEOSJfr9qonmDurvojlO6W7lF8ef72BNsthv8rWOTFzorfzxrwe/5WIjR/5arWt/
eu2Z1S1b4HI5M6pRM5viWrmBvi7OlcnwLOmqVu3r2e3sl+XocmmZxaU7udypuQ6mDcSTdRAo
Z4cTJpEjCVvZubx3vSuIPRvQFGK26/o2yuB5tajXHa8afj7s1D8KboyzUx8nY9+d6stEm7hy
iLaKdujFNj7Qh8NEZ5U+6w8PZFjEHEuzcZkUCIdjOfqcBd8ldX0w5D6ilxzPBl5lpm2nXq/8
sh7LQcyXpjqVc3qfI2FG9F109WM0L3QrjIyJEfA/o/Fx9JJ5SOHL71EJfR/hhHqjrqMcLqij
JLa6hTsK/cTkbeelJTGiJ1PHXE02KP9ZX91QgGa47/4rkjnT9UY+DLBwei/viOu6fYo4Cbww
AFaV/bQvXM9F8uRLZBwQaiX/9tG8BOe/I9vbDYlTutjBqnlVxnB5Ao+oOT85ZV6kluVAtcUJ
2Rgbp3nwNJFLN5CrlDJrRLcJ0DUs3CZFbA/SiVtytCFFDD4jnsgj8SaxJ/Kdtc/JdzYdy8+h
zRG5onX4NMjVQbmsOBGeuRKoFDz+AnnkNlQZoUJdhMeZY6boY8tP0ceWnaKPLTdJH9lmij6+
3RQdQD6Nx3mObB0XKjOkuvOFygA2qKqguAAnkeHvuNgukO2lvlbImAIJj4xJdbNDJlIF84tW
rY7w8RRLzyr7b/V2y8AKgO8asKYiX+/Vt8gC6Lt74EzuEWH5LzmZDtDkK0S9Wt9HlLZqtfkr
mleaqyB9WP+IbEKsx1gKx5o0HSqOO1ScETYDLbnOGAAERTGwjhqPvWqjUt9Hhrg+PMl7y/uA
XoZ0val5T8cfV3t5y+nNBLRNoy2uj8Km7xlU+TLwx0qxtVQjiAtHr+vmq2xhJN4cG2ooOmR2
4npL+hrqGtDj4C4r+NKiGsKXCaR1bEaqryl27Xh9x08xLCKuN63zpj1G676QP1ei2NBVr5nx
Iff2NqrIeHA40lzXHAvgX1As1N/542Ozr+nm2Uk8CJ6zxSRkSvIMPKB4XYudHjv1QEIK3Yco
zrPbh5j0tkcQWqkIJLWTaryWf/eN/N3dUVuWk35C2Mp3/4KFjR2peWIQr/m5GT5Jk+yNsOMX
1N2u5N4doghGuogMRSSXS6Mp4nFxdgztZ8dMuUU6kUFm7q97+0AMfOmD0lwJ+5bdwPfSkJS6
bRu/dRdx19m0gXg+T/ONpHhNOQIr1V3tv6iT7sTEGaBxSIzBQIfMTGF08auPkZJihL5QFBtu
R2AkeZHFCsrCehOHlC0GZVOR8lEsupc0AbKRnzu1ksXGt2d/1PvmllPhR2RKsljI3UdeCLUl
yTBNpdnhsjk8cs++r9U7du8CY4ADCm8oVDKyqCUIgkVbinfZepYfIxsKhnAMpRxDEkGpT22f
2EbH4/vQQbkwZdDUjvVxbCcDSluP0u9gq4LnNwv1u3rPYG/EvpDuL0DrOhi9A9fc+0qiNI2H
OLVDnKYcp8j3G/n3Qzq9UBgc5jWfGG1NmhntZ6tG/t3xE0kp8wAAAkYpwLdZr7rGf5Otx24Y
/Jt4/75vPcOSIG214/dGrbcPQqjlxSh25tXzFOv2HKC5bh8ltXxZ5TCm+F37D7JLnujmm6PP
scRTMJaHxj6Lka+GrIcwdJmVCOA9o5a5gEOCPTETwy3x5NmhI2ZquCGePDz0w0x9ph2ePD10
w3I63AxPnh56YaYGW+Hps30nzNRwIxyytrjCHdpgk5uhU/T0DEmUl6HTYSp50lOfcWVAdr8h
wL53tic/4+0A/35DgH8fD578XEAEBPQbAgL6kOkFPBMzAQH9hoCAPqo8ORxWIfZ+Q4i9DzxP
fibyAvz7DQH+L5CDQ0yWuNgmMsSgjOUuG8HPMbQfKtOr5RJpq5aIK8ss8bKWGeXKFRXmKOF4
wNf5uHuuMBCZJEv0e0w7NPHccY9kqB6rRU1lZ9cybgIArcvYb66AzSCWmlPSyw43OyiRFmZC
iRPghfalaD9tEpdT9snZ4YRJ5IgvGq44zDq+Kl/Xt1EmF1h3vGr4+bBT/2BSQg8lpeAgfqIo
HCzLtre2rIayyv2mXmzj6VFAuq/PWqppqo+mx0k3nrdOdujgMn+rZU29MUohunc0AK9X1NsW
uvWfj8bBEyGhuUWsVoq2i04a9fqxPelfX9S4HzR9T+Zj65InOppznH6EJ+qNuqZhRz9F1KZt
Oy+mr75T45RwurqRWaHef61D86b0OvB9+0ScoSIa2yr7aYPLeQqeLzR1FTQrkTn2f1NXWWlv
lEMf4JyhLAgUlzCViounBotL4HRfOzw5WDsCx/vS4Mnh0hA43yN/fz6I/IHzPbB7cgjYQ6c9
bntyELcDx18gj9zmnKdC3dOiHqKPLT9FH1t2ij623CR9ZJsp+vh2U3Rg84tgmxALAVsBhmF6
cH7MMkAengHmNoFAq2l8SzH/0MB6rTD8FJI4KU0WjgaJlV+0mC7GMHiKHgPcGT8E/a+uH3mi
09vma0R8a9U1X2hKIyBQNLXxPOCgwX5iuDrMVvN+eCO+9Wp9H9HopB5rsKF5pMLESQVP1vJs
IqoXsnGMrFYw0fO3wyCKRGL2nwjyS03jjdU0e9Lrq7z2GHeBdjkM5mDG64iGXfhnXTd+BwyZ
asK64Eg3CPQuoRFLC1+n3+Aaqf5IhQFe8u83vyuZcPc0BqX6gW1Yygw2OZb2NY4HRgZxUsz6
tTwbjKElWYhFkSn/LUOdOfipois3sn/qOiJhX49ldPHxmCZw7Wu9GeZN4+fNt3Q1y3cpeJ7s
w4a0k8DJDgqlpNDRxDmEuPX3rb/zgPooM2/DkQ0N1bcI2ZTpBoKI/iD0J/7TKf/1eJy1Q0Xs
uy129WOnHm7JX7AbeY8aFfZfyf4ryH8U7sq/4b9zF837tBQBhY+G2z35nNOCBSAjHbHq7tEl
oEdo+UVdnd+wg8QK/vN/mcwPzyjuM37Ke0eNBS49LFi7wVc+M3Adk3kZnHL8ghzOsdb/322w
zRBcyH/V3j91kuRCeeDnt8iQervB4CTSlOWoafjSskCr7/C2Q0YNXU0ao+twA1JI9V/y3gL5
Cw1V/69Bw1LAmNaADWEF2gJFW1a8JsSAcW9q5HsVTNwzqJDAL33WI/D/qPcNxXOlf0i0xlPJ
+VxDd+6Ko/yRW/btJenwLqIecoFktgDwrt4jYipcCaidQ4FVh9Dn4E5HwT0/QCutco+sNDjM
YVYn3iTTS6SRg3cRGVLdyL8fFJfHGDfGniFxrE+c9ZYTDqELWGbdHNxKT9HOUY7vV0JoH2Wv
P4IIo/6tC/klHcXMmgGNtKUnetbGf0AeJAOKnWHTMUidNcIURhTA/y+8XI4QhmEg2g5HoomT
0ANt0AD9H9BvhYfxivPqY1uK8vSyIOP29lkkdg9DY3tjheIYYXaRp7aAzYJ7zILrZ3rOE2A+
eywCD7y53sGPjc2gMHuYt/559iHTgjlxrX1ZFFxd5Ny69C1sdZVT69K5oNXVhlmX3oWs4c2J
deldwOoq5dW1L3DVVU6r7LWjFOeXVbdjK5xLXYa+3MW8uWqVTLUpJckNAxIexU65qTaJDwMS
H/2QctcQJAEMSAK0DBI0PUMSwIAkQFelzNuKhU8DFj4bL+Wm80h8GJD4f+TYNKTbNGRXpjhi
05gGqY6gD5LLgQMKZW5kc3RyZWFtDWVuZG9iag0yOCAwIG9iag08PCANL1R5cGUgL1BhZ2Ug
DS9QYXJlbnQgMTM5IDAgUiANL1Jlc291cmNlcyAyOSAwIFIgDS9Db250ZW50cyAzMCAwIFIg
DS9NZWRpYUJveCBbIDAgMCA1OTUgODQyIF0gDS9Dcm9wQm94IFsgMCAwIDU5NSA4NDIgXSAN
L1JvdGF0ZSAwIA0+PiANZW5kb2JqDTI5IDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1Rl
eHQgXSANL0ZvbnQgPDwgL1RUMiAxNDkgMCBSIC9UVDggMTI0IDAgUiAvVFQxMCAxMjYgMCBS
IC9UVDEyIDEyNyAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSAxNTggMCBSID4+IA0vQ29s
b3JTcGFjZSA8PCAvQ3M1IDE1MyAwIFIgPj4gDT4+IA1lbmRvYmoNMzAgMCBvYmoNPDwgL0xl
bmd0aCA0MzUzIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ1FdNc9tIDr3r
V/SR3Box7Ob30WN7przlxClLmT2k5iBbtMNdRXJJcmbyR+b37gPQ3aQktpLarTmkVCV+PAKN
BtB4wM/zyZv53Cit5k+TJmlKleLHN02apHlaqqopk6pMMzX/PHlzuSvU444/StXucfLm15lW
z7vJFB+nplDzxwndFbj7Y/IxehtPjUmK6H08LRMd3c7UlO7qSN1e2Xdqfj2bq8uL2fVMqfj3
+T8nqZpWQEwKJVesDlZYxSYXxbMLqNZNkkezmBb48O7XuEqySN28u7q5ULO7X+b/uri/Vnfv
r+8v5jd372bqo5rdzO5+d2tUECO9WIGVk95IxfN/k0NqcQgs0YnODBviQestbdgJuOgmT9Ka
XJUVSWPEVWytIdVTd0uG61TF06JIo9vFQxuX0Uotu90+LhITbfHYxWn08CrP3WatFuuleov3
C+zSROvFM8l8jjXhdLve83au5xOtOjUxAMpaw5A8KZWuC0SO9mDUtp08TX6eD6zOU53k+bHV
R74IpITJvMSoz+CyzAWPk4I2nuhYI95s8KgbdZ3UrB7fVkM3Nr0bG3HjzXqJ7SdV9CIX97gm
1zVIL/YuXqzUFd5ociyedgJvGZJX4u2GvX3Jn27g68Zpkk/l1YpC4Z+wonM9Gw6vp0hIZbIa
/j5weu+dQ39mRWUderTjbBAG9u/U4NSkFevVuPF5692PxBrkbFGWzv954b2n7bG8b584w9Ss
fbS5xv9wwV/KJDh8bmscca3KukwymInsUtCU135rhxvSJb6gDZV1Rck1mlO9N6ZVUjRpPrT4
+JTxdoypG18LOBmi2SrhL0+2S76hfHu3wTmjisBbMeK9wae98w5USJZVvpBV4rF5G09xpCiB
plWkLhfxtKZ8sq9lEQ1L6+ZklcHWT5fStZg720s5bF92oqzCQS6r77CYteTOYF2KwdcIaBX9
iaKY44w87tulum93cRG9xhm8stpbk02iG1OrI3WNt/tjdPcAMZTYdvsFSlyFPnK6ZuOwwitp
hok4J03x3Q4XeUrMz7Ehwxfije1/Yo1SE1mfICHrPEHhUmWV4ahxJg7y8VtgXTvQVEeohiey
MiRLKJ1wQTUC3RwcBGOgPLiywZaMXxrclh7AGQpxeGlCB0ub9Gjp3JgzS+eo1P3SZUWVaYA2
dB+UbWgtL5sfyhYFamXQ6vOojxPqqLEoDEUlOIrFON57exzvHTqO9y4L4N4t43i/uXH8TMV3
DIoiCRf0BT/1rZOxNVpT+SpwYKYmzcEo0QXYE53TGhSE1698eZGPdvttu0BX0FC9Wy0e5C1q
ExgerNXtDorg0dk1vrlKbXO1WH6Ja1S1lglyu+92WAz9xlI9gDhAVRkocIrARttWLYYlIc+P
6jAvkInapRRkW5f/iBFFzdtBHY1zvPK7KPwuMtmFGezipPjYDcgi2/ax7YbmL5PD4gyzi6r2
VhpvZS0K0JY2zPtTMq9b89b3aMT4hvdQRyFLBob81m67p7iBBV9jHFodJaG6Phr+/z/aIT/9
uIHOTuPcQAwfRctDOuuDDL/lhRHuYfIZcEjegBGCPCFomCjGpT1TCHyGKsblPVcIHCaLcXHP
Fnb5MF2My3u+EDhIGAFpxxhWOkQZQce7sDjKKKktPkCLGgkblA2jFFKLng3pyMoODih3Ebfw
+YiPqHdwQL1LCAufTYgR7Q4OaHf54ow/my8j6h0cUO/SycLn0mlMuYVDym22OeVnsm1EuYMD
yr8Bn0w+jtiLqklMOhh8jgeaft71IjI0scj0kA1S1wyk2BsYKU2ju+2SqAn1ctvaO5p27Ttp
7tVVB5Lo7MtXuewxtRY05lqhS3cnwHaD8XbjdB+PtgW8mxlldEWXg+G231CWoWcvj3YUnv4C
DiwyHFaR/aGHwWJ0lf9tGIQujFN/9zDY0GlrfrhZsCioxAUpIYgyJQgapISAtK/5AsP+45pf
NlIXx+VNlUpdFLioj4u6qc8tT/Bg+SYLFO2AuK/KAoeqckjalV1re3W0eIFppTFB8W/APmpp
3yKMjIYhvPf7ON47dhzvPRfAvW/G8X534/h3jIaFJhOpRXd04Pv2rPSzYcmFZjAbUge/xuHM
QQc46HU0Q2OcRfeqk7fdvlvs253af+LHVu23C0F2aMVJSbfbdRvRbBXZpyfo09G5GfJ0BliM
NPa25V/I84ug9tLFNL3IkPDM/8rWbHm3+kpGYvJ6wsSSu9lii6nkl+tL9ZPq5P3IjDJ1E4/1
oZ19ur0iT5RkDnIKZcWaXJJ35B2bTGrtNy+C2ksXp2weKXnmf4VZB1vZi2Jlry2bGCiWPrbG
2kXbLcVnGUo2Pew5kjCXHnjnubgtt07KaVzNyGfYVccxZiWqfeabbbvbJYe01E9IbIbxZtRi
xvt4iqwkvTS8dWseDPdqITc84dVRYFO6HFDGb+0WsaFZ9SuFv4pCjAbBnM0QKjSWa+EIjaT5
RBmO0VStMEE2CAjF46GVJ4QJfpd3Ly8dv1uLwLNcRizlZQqfF7X1/yfEGk1O9KWVq3pgCzgn
KsnmisOeUoh37nFPjqqihFoBl4YnfNoPo7YNOJpIC/BQnQe5StAwV41Le64S+AxXjct7rhI4
zFXj4p6rBA5z1bi45yqBg1wVkHZcZW0PclXQ8S4snqrGBsMAPnTsGD703Bg+dM0oPtj8GD7c
3RgeHGJQGqiRl/59tEoZW348A91Q/c2ivvTcxg0oiCaLeypJ62Hx2o9WKCUqXEVDPT7HOCcV
i4rsUXmSp419IvoR8qmkfNbuQpW8ieTrZ/5X7Z98xRy1+0msRfGRL6jIsmXzfwwaXjalEVPe
fphR3fKU4EivJtZ5jambXfP/vlspz5SNVP0atPPEDM7F19rfRExFTXSwtKn9pGjr5XKDBcnK
dUx0uYuJqfbbdoESqcme21gT+85iKlf3wuydfIaseGy7LyzYskuWP6mH9olKaEFm4CgiUgcW
ZLUv2akNBFYyzKsaGqQcFzAHZwHOpX+151ef+AHsyNPJdUx1+hKLw6CFfL5UL4sdTy3y/01V
p+zvDLMBsl6yHjficQ2P7zfyQmJNul75+iKvd+JCEFgZHTEpjK+0/nuY1IwQaQUiNSlUJWeY
NG28GVrE0SIa2p/duuatc6rVdP4ouLat0tFny9SLEG32KZ9Z9UsZ0jZy4aSX3ggDW0wHwDqw
Jr23fNCpQa2lOhxkVN8EuKS2edlwwKgXWrq0bGhFQ2flMC3zPi11n5YZp6WxaVlwLkFJLV1C
zXnHN0uvbNonOd2VVtkLBbWmU025i8Z5/YzMaeUR/R51BXl0GUhIUw3i+hrXUpDIY3QQMzR8
FAx3aAsXadtP9AnX9xMnrUReoqwGWwmLBluJgLRrJSwcbiUC8q6VsHCwlQiIu1bCwsFWIiDu
WgkLh1qJkLRtJZztoVYi7HgXFu2puDnAsqbqsRPJMEoBtejZgJ6s68CAahdtC5+P9olyBwaU
u1Sw8NlUONHtwIBulycWPpsnJ7odGNDtksjC55LoVLUFQ6pthjmXnMuwE90ODOj+BhzsBLO6
SsradoJSaKjOvJnPMaChBiFLDEvh4mUqEJ0RmQjlNHMiVsIkOB5+Vjwt1FdoYaYlSvOUeBf8
Tp0Q9VIt/y+YNkAlBKgP691m1T0y0snH8tmSxNXt4kEeV+qqO1DWxbT/6OFVXnabtXrLwIb1
L1suuSioWttsqpAYyhQFhwU9lHfdqDfIC3V65I50MPtZp9QiGHB/SSfUuvLIjcwqxtTNIedH
s1XCX540EymzzsfoHbN8Fh2014NP+zCfEr9lLtwVlURr3lJjU1KkpqC+S1Ai8dl/qa+a3rht
IPpXdNQebIj6XB6DND0ZKLAGesnJ6Sruoluvs1KK9N93PkiKlGboDdJLDjYkvZ3hcDicN29y
n92sBD2sG/brVaJMbJfiyvhYPs48U4yvbk4YeNdvR0xeWh8wlD0F/IHGzW80UL6Of8zjsTiM
064DIkYGPs8J2a682Yi4f/s00QwxXv8Zj8oAx4NSCQt8RccQYX8P09rN+Wb7j+AARgGM+4mT
cf1rZxqcrQpfpp4mOptRsjpKJMKoSiKKdeAJhk0L417SFGtgjow9wpH9YFbmodvL5qHbM6x2
e8U8NHSGtYauWfuezXCHXTbtuzZO7bYtZ+Ho1BrftCHcqt2ei4THeZfwOLESHmdOxKPcSHi8
Ownn1plvgDXWBjdAvhBdUB4dX0ODN6KDC3RXw9gPEuEBrrYlddGCupgvDp/GF7quR/dOQgif
RlQQLTCEez+REk1+fOK3Z/qf9M27dUvDyDgwlHrlZwhmIFlUXkn+gGiYTxcmOGiPFB4Ij/OZ
VFFLcdvyMBWkoUDzoiBlB6BIyzmROVtlS7JyDxIRlrJlMX6LVSwQ5WmG3H/hV1a44zTfp10a
qsqgClPFHkhagzkiTdtydiyEBqHiw6g1w9CLa9eLSYoiF8MPMR/g7Og+8dsz/Z92bVm4L5Sq
RJ31tXdrXRIeHjGwBrNIdIS+7zBgcA53pi4VXYYUEdr77+P19Bk0Z4PJtCjrYvZpOFVe0AWS
Ydt32J2BS/BQTUWnit36QOpuojGjcKIW55UKIpQYhLcXKNc6yn2gTfWYPdjNgAWMr2eqJP/x
RCV2TN6e0+KJyYyya6Fc9zQCwRkYKljcOBds547Ilvd4YUyZ8ORSMxlR2jSw/1qlH0Z1+pGt
A/0wnKEf2T7QD8M6/cjmgX4Y1ulHNg/0w7BKP4q1px+GdfpRE8/H0i3s01f4HMP10GmWCoRL
IpQ5SnlFj0t+/Tkjljtk2bPHJc++AhDLHL/s2OOSY18biGUKQ3bsccmxrxrE9JJR/Dpc9Ovq
CbFMMcmOPS45zmGq+Kx7oNt6Iz6Tti0MzvwJmtxaMW2lam2GZYXAUHf+kcYLCBRmi7aqWJii
bAA2QWqe5uv49De2eqAl0I+/jO7laYc9/+VI8pOV5/UESpNE5mUrLWvTwxnW3UC1F0vLWE9i
Aa9j/k49WVegIX5IT0Zs+Zae9D9VTu6H9KS5H9phvchGTsYrqXISEtTY/Q0B/09yMvZ2k5yM
U56Rk7ek+7vlJNTZfa0KEx2lu86oSgKKdejzDBu4G6tWX9ucPcKRvd0rDV0xDz3bmWttWzEP
nZlhrTlr1r7/MgwNIV28a7Epq+ZvwOHUYCIMcqzGLr86Fxlf8i7jS2JlfMmcgofcyPiyOxm/
QU6aocIm+nPISQyvD4qpjeb0nub0huf01s3pbZjT25J/VLgfQ3qmVwYSfBppO/ghEQZ1E2nJ
wYnIgUVkk4rIhkTkgCIy6cwkBxrcBqlFjO6KpOmE3QBi0Xk/OvJgubWHH5J23ZeoJntSH4qc
bLtA1sYd3uUF5VYHUgj17b87qA7a/pev/B0aM6rBmeBxh+gRJVpNJ4zy8rCjtZN0rMTdRrhB
oPBSfIKt7XE/bUlPz/AHUmkRSsQzS2Yo8sAnXts9Hgrkug4iIvVWQVOe/3Rfil8/4ATSl+81
tcgdngrahesK01Bh+rI0VJY9laXlsjRclpbKEpa68Ef+dsZDKV31m1V+AodXrnAwIVgUnHl6
nCC7TYnsCOmGmCHdSOeH3YA5qsL4EMvJJpWTjt5XmtIMdplGNxzkUJWDFGvPQQ7WOUix9xzk
YJWDFHPPQd5c4yDF3HOQgzUO0qwdBzlY5SA98f5Ymn4rEjxsKCWasYrSmTKaPVNp6YDL3sOZ
M5w/c8l/wGX/oSYYztaE5D7gsvtQM859rmYk9wGX3YeaYjhXU6J3jyvefc0xnK05yX3AZfdv
wKoANZXFB1mAJmoT+tF/AwBUe6a/CmVuZHN0cmVhbQ1lbmRvYmoNMzEgMCBvYmoNPDwgDS9U
eXBlIC9QYWdlIA0vUGFyZW50IDEzOSAwIFIgDS9SZXNvdXJjZXMgMzIgMCBSIA0vQ29udGVu
dHMgMzMgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNTk1IDg0MiBdIA0vQ3JvcEJveCBbIDAgMCA1
OTUgODQyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag0zMiAwIG9iag08PCANL1Byb2NTZXQg
WyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9UVDIgMTQ5IDAgUiAvVFQ4IDEyNCAwIFIgPj4g
DS9FeHRHU3RhdGUgPDwgL0dTMSAxNTggMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M1IDE1
MyAwIFIgPj4gDT4+IA1lbmRvYmoNMzMgMCBvYmoNPDwgL0xlbmd0aCAyNzk5IC9GaWx0ZXIg
L0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ5FdNc9s4Er3rV+BIbq0YEgRB8ujE3llvOR9l
aWcOqTnQFq1oo8guknEy/377AwApCaAzM7uX3XKVSeqhG0B3ox/e6/Xi1XotRSbWD4s6qbVI
4Y9e6jRJVapFWeuk1Gku1l8Wr970hbjvaVAq+vvFq59Wmdj2iyUMTmUh1vcLfCvg7dviY/Q2
XkqZFNGHeKmTLLpZiSW+VZG4uTS/ifXVai3eXKyuVkLEv67/sUjFsgREpuDkktzBKoxjqdjx
6gJcZ3WiolWME/zz3U9xmeSRuH53eX0hVu//tv7l4vZKvP9wdXuxvn7/biU+itX16v2vPEcm
aQfwcNssKtg1bzOl6XimLE0KES9VmkZvHg992z03w+65FTfNXbsXt+3QHvrd40G8fdy05Ppq
vcjETiyyrEoqlYHjMtFKZFWRFFIss0SKrl08LF6vJ6vIU5Xk+mQZkYjX/8L8VLP5UWUi0xML
k9GU5pNV7SJZ49ai1T6hkYRnhdYOLxH/GL17jJcFxpO2NC5BJlVagvMkq3DoJYfKO60dwaVR
utIoOa7rFoKa6Kgf4mUZiTdNvKySMurNz6cTZ1kCGz2dmHL08uxZxbtaDVxz7VPP/iGQeV2J
4xhkrtoyU21XcZHU0XeoMB09tfdDu4HE9/CjjL7GOZTffoASkXmWQ8je3zEClQLjzDSqyuqz
WGfjFsDdV3QCG4HTVhdysqblOPgjDPwSywIC1fBWus8xzFpHZkNQfJVKFIwuFYSxEilMLZb0
n6ruRbSqHCrLEzjLJFRp0BphqniGs0xTxY8DpKzn7BGe2NfViXkuqzlzhKfmOZ6SCa4kVm/Q
XMk8kePmNZyqI7jG97A1wPW4NjzFR+aFqqehPTV/AZ5kTRoQVpuq87R44GnUPfA0qh54GjUf
PAmLB57uywO/Xr/c3uDk68r0ZTwIynGBNh0aWxV2jKVMVQUn7yLGbhFt+PfnWANNQFvJ4KB2
w65vDSD2zR2/GXAvzPcuhtMXHcjQDN7x15b+97EyDcr0QzzZSo0dRLoOUvEam66FHQ8NuCmx
N2ywywENPvKTf93/FgOlQdPdPcRQP5EYPvFo+7ulx5f61TdoEdFuT/tRvPkU7b9SBzPtacOY
GB7Ny0OMk5ivjnw0nR1FU6//woGXE358au4/xxj1dkDHVZTgZJWxMG07T1RRVsckQ55ydgJ3
AeTyLl7mNtZlNIiGXzaGi35uO4qMiiAgFc7RwB4nQZmkgKqEmz9PMcQKXH2KszRqBfRQyBz0
UAl5fnraEXZAbIv/eopTcsoR0wyfxfxt88ShMo8d+M4psRqcjnEfy0CPOfDvQVZ2klSOZXTX
gjXufkv/Ian46LnKN5DOQJlIt+TULPkB9soZz03GNWYcy67C1QmTW0251bB4yq1dr2E12CYV
/CUwV6EKOeFl4rMJJUlYkQ6SDqNh0vFbO9JheIZ0/PaOdBgOk47f3JGOMQ+Sjt/ckQ7DQdIJ
WFvSYThMOsHAc1rSkXN0mpTyCNYFN2a/cRjFiQ06k1P/1BYPeLc5N/Bczv3+LR7wb2vCwDM1
4Xdv8YB7WzPWfbhm/O4tHnBva8rA4ZoKeDd4yLupOQPP1JzfvcUD7l+A4cLgvyboAgdN5Ft0
LnBOhcK5CNRwtVbp5LKhHY2k2ulBbfTgze6u7Zr9vBQ0KlBLlaTAIoWGygipQFkWKOVO1nEu
dGYvTBr0gFb/VT04qkA7NBDxP6P9RsU3nWQSiPOZ/h91noY4ZTLYnoMoHTJGg+05YO3aL8Ph
9huwd+2V4WB7DZi79mnMQ+0zYO7aI8Oh9hiytu2P4aI8mbxQ2BCD5i/ALmvQZJSVSxI77Ele
/PgYdz8+BtaPj5EL4C42fnzcnR//AbkHMiGRCm+oX8yByO0pzXOn9zS1oqnei0AJkJ5DCPqI
RD0F93xovwWeIfx+YtQ8djFeZQ8xHrIt/e/j/LTFnRzlfJQV9hLdtfft7jmuSWahityAkMLs
opqBWokeSWzAxb8RT23biRtEq2gVYz+9hV5Tnqgr1y7T/Ew8YpuEbtO1W3ptYpRa3Wbf4v08
j/i/eKSb/YlqGwMpSycTc9JEFLPBPGPYs446Yb9hwTjVKsZN3IpdPyLWPQVEF9Z/XbD/Q4t9
XUXfByQPkCqfgEWghAtMAT3Fg/0FgpWRbDRjP2Hwish4OA6Q20hqNtJsnmGNuHbcdTfsemrk
ECiIPaaCv7c0iDRMeUwykP0qz1zDdsQg1USfFqxPS9an2upTzfoUFvlMXxTAPGKpmrNULc+k
6qSoVOX44WP0BXOiSZnWpEwLmBeVKQk+evQxhuRMnU6lniM2dnoRE2Pt8UDIlIRvysIXKgrD
QgEC4sVK8y/SkKWt+TMJmxwx4Gg7asIzOVhUJd4KA9xk0CA3BawtNxk4zE0Be8tNBg5yU8Dc
cpM1D3FTwNxyk4FD3BSyNtxk4CA3hQNv0yJt89Y10tQRDOUcZq4wSjlldDanvqkd7vfucs7w
fM59/h3u9+9qguHZmvC5d7jfvasZ436uZnzuHe5372qK4bma8nq3eMC7rTmGZ2vO597hfvcv
wEE5WKSVE0F/XA6qCnpxNZGD+Uj/uZODpZWDlx+Y+MX1pj0M0P/hngFsgXwAZNT1wBcb8a79
Poi/Pz6Ji82ma/vxPm+Voqqw2EVW1zB3SCnmQGuFPF3i71SKqoSFyf8BpQhhztLqPyMVVVKX
Rf0DK7bC8d7xo5WQJUlIdSQhSUDmJCC9PEk+6gnHsrwspvLyPOYkFmdF5Wy8f7fYVHByVaj3
B0Fs/QwGO7/f1jZ2RjNdnDQXCWKhCs4sy5oaH6OqTtKzthue2jZlRoM92W9sWy6joY4bsDUN
ldFgP/Ubz6MuTzjIqrMcesFpLvz4GG0/PgbUj48xC+AuLn583Jwf/wF1qXINIRgbunTnNzXn
Nxtl5S/YyDQoEbxutwd6oPahT8HfqDgKOO74PsAJh+bPA6DBP3Ut6bAs2vEAcc9Yw7bbiQcQ
bhPfMwo0dSpLGpWF8qwmeaZAnoHihbsMdBuNXgfUjd2ufaZPUia8B/oU++YO9+iQvWg2/MOR
AQqq1gAnms8ppVpPNV9hNF8dCfvDtxja9KgBtdGAsO0H1n51ZBHYA2pNYVyQFNSR8SNurs3w
1/BUyDQP1tA6El97O3rHPg7s41hHOraxZE7pUrgO7NXdt1hiN2y6DeokaI9b+v9X9AXT3rUn
41sBaTQytIrYZMPYkQPRiKfm/jO9t0NyTGJ5Aod3ZF0n5WQ1kaI1blVhZaEClVaKSpaiVfQj
Iu7nFiVqzRK1xmUF+A8Nc8dzlpgp+AqSU+KOxU2MLlZwBGR0y2JyyxBHfuhjhZlpQlTmKgnP
JM5gilNxFQJ1igeIWI47z2GqRwap3m1NazqXmosFbb7TxxBn7kJicq+0u8lZ5j5gMtFSgndI
PdYq/wRnmXIN7ZFqFI9Ee+Quc6vPzOqRvCVvPgfXJbjZYMoUpgy/tvQf113Suqki6NVWhLkj
jAUBR1IVcnK1IVqfsLOC3FdBBmY0TMF+a8fBDM+QsN/esTDDYRr2mzseZjhMxH5zx8QMB6k4
YG25mOEwGQcDb9PilA90BnWE5vAsdMg2jGJKDTqbUs/MFg44txk38HzGPe4tHHBvC8LAswXh
8W7hgHdbLwaerRePdwsHvNtyMvBcOfmcGzjk3FSbgWerzePdwgHvL8BwefJfmfKygARNBOZU
TChFDTyyjejfAwB90lsMCmVuZHN0cmVhbQ1lbmRvYmoNMzQgMCBvYmoNPDwgDS9UeXBlIC9Q
YWdlIA0vUGFyZW50IDEzOSAwIFIgDS9SZXNvdXJjZXMgMzUgMCBSIA0vQ29udGVudHMgMzYg
MCBSIA0vTWVkaWFCb3ggWyAwIDAgNTk1IDg0MiBdIA0vQ3JvcEJveCBbIDAgMCA1OTUgODQy
IF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag0zNSAwIG9iag08PCANL1Byb2NTZXQgWyAvUERG
IC9UZXh0IF0gDS9Gb250IDw8IC9UVDIgMTQ5IDAgUiAvVFQ4IDEyNCAwIFIgL1RUMTAgMTI2
IDAgUiAvVFQxMiAxMjcgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgMTU4IDAgUiA+PiAN
L0NvbG9yU3BhY2UgPDwgL0NzNSAxNTMgMCBSID4+IA0+PiANZW5kb2JqDTM2IDAgb2JqDTw8
IC9MZW5ndGggNDg2MSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiaxX23Lb
OBJ991fgkdyyGAIkQXLfMo5nki0nmbIUz4MzD7ZE29q1pcSUcvmR/d493Q2ClEQomZotV5kU
G0CjLzjn4JfZyYvZzCitZncndVJbleKPX+o0SfPUqrK2SWnTTM2eTl6ctYWatzwoVe385MVv
U63u25MJBqemULP5Cb0VePt6ch29jSfGJEX0ezyxiY4upmpCb1WkLl65b2p2Pp2ps5fT86lS
8Z+zf52kalLCYlIs8oqXwy7cwiaXhacvsbSukzyaxuTgw7vf4jLJIvXm3as3L9X0/a+zP15e
nqv3v59fvpy9ef9uqq7V9M30/Z/iA0FXEnSqSiyQpZqdsR9yEal49u9BbrThkPEweZlUnBi8
5LkkhuNPS9lmUdAbbVNrdbFef1IxPkWvmk0z3yzXK97B+exEq6U6MRZR5BqrUcyqrBLEONGJ
Uc/Nyd3JL7OB6wwebbXnemTPOj1a0KygVXiyTEnJoS6s7RKecyU5KO1K+TGKtUlMdBmnSR01
d3GBH2qKiPhtyf/XK/VfZZLqYyyDD5NNjvLc/myyuz3buk5M6gKmVGd+g/QquU60iid5mkav
kfKz9Xa1UbOLKzVRFze3zaO6bD5vm3aj3rb3ypdAVyimxvooKjZZZ8hrMP0aMVb7uzmMojqW
fVv1pesLZob5GRQCDeQ6X9cS5rs1YkQFNo36ZxcFr40gyhzBKFMkmVHIDbx2QQSbQiOmzNK+
yiKpTZ9hpMG3gDt0H+IsKaM2rqJGrakBcHpf8zfKd1zRC5IuhllscR4v+P8VegZnfsmWFQ5u
YoEAbKLKyAQpDxZ3C7yNCR7ow726/e6GT2XypfrK7h7kZ7NSsgidtUUjC0hn6ki8ojPlhRZU
zermVmY0i2S/SSfAg9yYnVIEW5UrZkxVe6yqaWw0fUzGj5aAhNSxIMTa847Tk5ZYPNEVDXW+
R912IwR8Sw++DnxmDXWKjdpNPCkjdXYTTyhnrfu871ijq9LM7nsOR73jXlcS1nQjsN58asUB
yKPKtNpraw/oXW+doxp19A0gbqNPKF2zQEO0DCpbtFgRPW5wuE2mM+Ts/a1YmucvGMduAKIV
jsh+snUfApbb0iIIBHuqCzPY06QffI2BTzHOUBndSCjP/4nhtY5ajxpVnuQYba0m0Ejhmo4b
/vNx+6G1qrzVlHtmDdzMbHA2mRmvxKzBAzjEgwHG4qiFvRt8Nr17Wybpjj0z1TH3ZB64B1ru
esexOeY9N9med7Njruk9PLsmSPPmYj/0Iq+AYMHpPzAPqpY7I3ab5odlGTEPsz5iHmZ1xDzM
2ph5kJYR8zCuEbOA/3FKoqpWPfRntidX68iVDl8KTyaaAXMNjsVDXBP0AnlzwvFY48QQmNMv
uP68FXuLI22A6fwZB8tAszU8WCzyX6bfyxR+V28/QNnVQPwCp79zKkfQYeRQSxCUeATUThIs
V1i8jOaPW34uCPgybPlGsUKIbbSWT2KX0ZuYtqjIYw7+0incXp2q5V1MclNtHnhU47XqHuIY
L1Ur2cRrBvoq+iQPCBN52YLQDHxaTg+JKrUQS0Osho2wWpRPMkwtW1AXv97ciuGxcZMSFIiW
5211WI6mTaEtPJYnXi1BfXNkz5IAZMpGGwqOSkpbtrThjiV2dBs3RpF1C1ZuRYoLGgzJhAQQ
hkEODVQ/8Bsp3F9tkDRTdYtR+mixmxX4vYoW6qp5Ruax1SL6HhvO0pBWBgGO3hOoigU3q5Vm
lbzlkuMseqROlS9bGQKBGAjZL+6U2BNp3AoNPKGGuYe+YEJfxWk0B+Niq4/yZbug7iWX9NGN
h3ICu5TUgbB94v8j6fnbyXbE2CfKQt0UZkDtTIkDVssIrIK8JdYwb43P9rwl5iO8NT7f85aY
w7w1Pt3zlpjDvDU+3fOW9z7OW4HZHW+JOcxbwcRLWcqetpCs0uwnftzeJ3bc3mdu3N6nJmD3
wY/b++jG7eCncVYqbOmvqXwKcn8AS8dKhkGMOr0jpzekcevojk+BUhfTy1M6dRiiWM0VePn1
nAaZ6EzRkSVlt7p/lnmNjGnbblbrvqwWzpWfccBEO1LSs0DmAA3IytCOe0zFfDchOrul1RkZ
6BdfUeXLVkYDjIAyFYl4RASQ4c+ntAdiA9xlP0wF4jpcnP0jILCZC63jQitcmA+4kJZYy0cZ
IeOJDTPHholmPoyucPsyRbRkKjxCEYVHrcJRoQQn2FUw6NFTnXVfHJqBxr7cUAVygtCcyZIY
oJFvSrvhCVWt2OM85Kkoq/8X5+3A8EFAf3XjwxL9JdJL9llPZ1nHennu5Zoe0B6xwwMtQlV+
jfYB11ChK0c6qNxWzCt5bOLCK6zAtZX3nQ2oFQ1RE9+QMqF8OrVlRW0R+TXueeqDHyXTr7Gm
DDkO3cjjAVSqHnYY0jGrfOOs08CRFryOpBI9C2MxR8HcQIbap95lyb53fsSSRVkmOsiSzhpk
ycDsjiWdOcySgfkdSzpzkCUD0zuWdOYgSwamdyzZex9lydBsx5LOHGTJcOKlLBBxR1gyZO8T
O27vMzdu71MTsPvgx+19dOP2MEumFmP7u5upPapoOVnZgB0ZVCxdz+bN8ksslKeBODfgJUYM
XMToFqcu+VpGRlzkeFwbExESIRm5vdHPe7aFuNBhrztD1xG7Lwl/ydWaVwJkAvewBu6LdMgz
XpmIhxDrublxo07dMN5njmsh4D6iXWbRLrIcovRSoHjFUDzfheeFA3CH0C1trXbi/OeYinU3
xl7wdfVKJqpbN+47XRLsHvJrX6Pak3MFGJ0/N0+C94182DjDPf8nqqJno+QJOJ+vt/zqhseG
M/WxW3DH7bASWAlOuj7gLkioD0QLUFLXVAqqCWVdisEqwODF1eDqYyxFWexVwMdXuR4kGVWK
iCI/rdqI0li7D91vAL6oMDhb8eObswgN0NhP7snkr/fIvxCC9DrM7yTTQw1gRAPklCcSPqwC
6KUJ0J/2TaWLgZ4qfMkyKhl92DQTUKIRgUVyc1gCYRTemjGdJqJhrpSaGmklj018oOqMvwcS
HdNsOsN0aIm/H7f8o1GsI7L9qth6UP8vDWWv4qNIzpbStnffxTcxo3fuRAcumcYW/lj3oiMd
iA7DrF2z5uAuqQhRECAwJSYBycBScr8VBC08tI1LhJsfUR8+cOMChywm4UGyuMbxsAQD0CBt
s+L3TUxNtSbmL/ncWM7MUQmycurgWycqdpXHLT/4PO8dLN9kpm8NaQzsseLG4JNcYqOym/JH
e/kZ0XMoX/oS/VC+0JUhLF/EGpYv47O9fBHzEfkyPt/LFzGH5cv4dC9fxByWL+PTvXzx3sfl
S2B2J1/EHJYvwcR3Zck9/aPB9+VLwD5M7Jh9mLkx+zA1o/ZB8GP2YXRj9qB8yTOLjhvIl4NL
Ud7Llz+o7030wLekRi5LwolVz2X8g2lkIQhkGB5rr2q0M38+UC3HL69v5RA6hXCvnJDoBEGn
B9z1r9McrXIf/rakOB1edg8Q8lBTfI1NgfEiFZZzearmmyiNplm0cQeOIirmaxENdzGh1lI0
h8gL0IQhObhQx2HridDR5QBAqo5cwXZou793pZ6wh3ytha8zglYrbG3pVovUWcqkHbsBSh09
c1RuRZfvrMu3dflGtjO6yu6v5pI8Gq+Ly8W0uu/urcrFDclJQoAwfJg3XVUDLn66oQ5HKb4x
gVa75CI+r6Obx0ems5wKm1OKKYZb+fQY6wC/hfc4oA/H8GiHUmvP8GXP8I50L4T81lAri4YI
G9w9d89FIvKQ6b/cFVKuILRUbv2quMV1q2bQ83SduJTrRBtXfPkgrbmSKwtlkfU5WeS6kvFG
AnrN9tz3qtlgl+jd/9FeNUtqG0H4VXSEqg2RRhpplKsrVXaV10ntbnzxiQUtprJGBITtPEfy
wOlfScC08CUXJNTTPTP98/XX2ALVOdfM8AMmE3HuF0CJEkpm2W3lG7NEGH2yQKNPTqMPfetk
yTkj6GEscz3hrgimsOoINQq4yIk+UnUBlWySFmvPM0Wg1WOjRTa4LhsFxEMyYHUyxQpIsQJG
hD7+ldwfiXFt5lRHSA7pZf3jAVofwM9IR5HbUTQanALzPh4b/rqALCzPGUm5qDNf/QgjgSNA
i7IYiUhNRmJoKyMRsc1IDH1lJCI2GYmhroxExCYjMdSVkQy7RxmJpS2MRMQmI7Edz2HxEACR
hnTh3Zk4L/2Esi3FmIp0IqbxrVVuWNeYi3gq5nH7Kjfsa06IeCIn4uZVbpjXnBHxRM7Ezavc
MK85NZzeyCnDusgt65JzIp7Iubh5lRvmb4hNlpl7P7BMhKAZgc8Z9vGnn5+eXALgCmnkyA48
eis5XM4NXDUdkDIVpES6CXy1SNPZW8DMNy1wjOTp/cfkp+T9Egno/XK/3+42AMobxkkAwCyT
iLt6AflaB3IaWtJbDWfJHebm5WFGqCqXCHwJwx0wlmYl615em3ziXKi1HyDVAYc9vi5GPht1
2rRimvGhZV6h8A+DaJaMlg5uh2YHjDu/Ileu0qbphW88NUzQjsBZgKm+WSIFhv4rn4VDQjOu
0+Jyr5E/NMqXG3KX/jR77LiFN/uj8qGiPjM4MAp8K/h0vxIB+E5kYc8M46HB9o59HRnCawe5
kJUBRpzZb88saQ5fm7X6yPvCXfkzG04P5k5oBO4AVD5Pxw4dsZhPsPALsv0KaSHe5PAn0CMc
VvokU0TOykVZmHhtSgmvWWritaHd4zGLszxc4rHPGLHi+s47RiwWhxrRYgyYxaR6Xpyr+wu4
LuA+E6dH8ej0pbvYHRFvSh3EI/UoIE4c/oZ4FLZM4RDwHYrhKjAx+djxMfnYszH52HVR+cg3
Mfn4djE5IN8tKHMhB8eAgmByHgZMDoLJCY5XBfLUdy9zQGjk10CUPU0qSLKJRTsYQbCCHmjg
Tba0AqlzMUuaDa08NPyff+/mKZLttzQ1ItiTYotcHgEAFXb0y5txJWJvrq5qPnfDqWVe+Aqq
DsoZ57rXOdbyib40yf0fc+T8eNpsRiMXWn9uABsEEC+hK+2BFVCXrP8Osx9cAQaPHCedHQxf
1azD2QBf1oLkH5sDzEI4S/yNg48OplctoCiGkUGwsaPT0bQAkwg5qVInVegknBROLN7xg1Ui
I2wqHlnyBCvz7Gme6kyrcJpiskHKZ3nee/Y6H9BlGWhp9LFRr1orYNf9zvXODBqqkkIFC6vZ
64n+Ncn2mGR40gBjEaSEOi9cNqsSmqHP7bnIAQPE/h/HZJGamGxoKyaL2MZkQ18xWcQmJhvq
ismqbmGyoa6YLGITky11wWQRm5hse57j4gZIhomhcpeej8sHz8blg+vi8sE3hry/fFw+3C4u
N0m0g8GiKJg1UkF5r5UQPFeCo9LC0ukRF4EmzF7mCIoAu8DbAlQeMH4uXgDXL0hV8tmS/+7F
hD63rAKUWd6OWGdQ88+yQMwM647yZSe76a5tfzgbiItsQLKM77Q/tPvlBiEqgzPiNRAeADj4
SkvuHl5kwPFJykSfXnesKyZ6fDNw//44R7q4IbCHiKyaLbeChlrBOnlBOzVCd4btBngfOvaz
NIfdaO13eu+oeSS8AKBuvL/rsUzBsWuxCWDkkhM99tgi0OuegNHh1s0SdoWr7JvmcId748JG
1PRvDMgXNE3gPp8xGmQdfpMV4zh/O2HgqP9MIP6WPx0RWiGHfhnPHmdj3eUscI3ndY/nEvF3
2PNKukkJeyE/qMH44xxR/AGBvZdA7tYA+nCqbCbvz3gUmCUOSctvl9ZuJECz3oximHA68J8u
aSX6GCRKkPdIaEohAw/ASyC/15wUy62sGW9Y+CHBpWi/zV1F7TDDqmyPRGOEFNVgGYYhIkWY
BESN1m2yk8WYhJ46t8N0OLwwk2oPcIK8D4hmW09DUqEh/+DyQB05l1+6EG7SrA441FCJ74g1
dP9ybgJBoeSsODkxC0r0DiR6ocnZ17nsneZ9lGW23GN0IHQQKIjoNzxvNdtSlHJmRLkEDbCp
S9a8vOUHxTojF6P8DtOwwmjgqR4JCR5iyRglY2TMz07EvY4dFP2x6XhrOF/Cz5YzfC+Jvmq1
JlAo/A2SBGqhExHTj9ziMRFm9NwIPxYSe2gSQT/EcOSitXAjZsfMllh6QakxAyEvmSnzigXz
5Z6iAqx4X9ysUf4EYbRezjw8ZUCvuuqxr6fCOVNhz4EPSoUDU2HI7a9ShgS6zIo9s+JasiT8
z5CnUHcGH0M1p/4sho5j6DGGhBUeimYpIgwVA0w5O8TKhE1RHnaS4hv6XUiiGzhrel+4+Sjm
YZHT2LaCjYDyOlcO7H9EfnPIOZv8stQmv3HtnvyyeIL8xvV78stim/zG1XvyK+om+Y2r9+SX
xTb5NdSV/LLYJr+m5zUuhZLHrCAPjOVhStkUYkzD7ZBGN9YFceMa8vADEY+a1wVx85oR4XZC
RK3rgrh1TZhwO1+i1nVB3LrmU7idTnHrssCwLukWbmdb1LouiFuflv43AECgOCsKZW5kc3Ry
ZWFtDWVuZG9iag0zNyAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMTM5IDAgUiAN
L1Jlc291cmNlcyAzOCAwIFIgDS9Db250ZW50cyAzOSAwIFIgDS9NZWRpYUJveCBbIDAgMCA1
OTUgODQyIF0gDS9Dcm9wQm94IFsgMCAwIDU5NSA4NDIgXSANL1JvdGF0ZSAwIA0+PiANZW5k
b2JqDTM4IDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL1RU
MiAxNDkgMCBSIC9UVDggMTI0IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDE1OCAwIFIg
Pj4gDS9Db2xvclNwYWNlIDw8IC9DczUgMTUzIDAgUiA+PiANPj4gDWVuZG9iag0zOSAwIG9i
ag08PCAvTGVuZ3RoIDQxODIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImk
V9ty2zgSffdX4JHcihgC4PXRk3imvOUkU5Y2++DKAyPTsndkSaOLk/mN+eLtG0BKBpTUbqmK
InHQjUajcbr7l9nF29nMKK1mDxdt1lYqhx+9tHmWF3ml6rbK6iq3avZ88fbdrlTzHU3K1W5+
8fa3qVaL3cUEJuemVLP5Bb6V8Pbt4i75kE6Mycrk93RSZTq5maoJvjWJunkvY2p2NZ2pd5fT
q6lS6ZfZPy9yNakBMTkoeU/qwApRbApWPL0E1brNimSa4gL/+vhbWmc2Udcf319fqumnX2f/
vry9Up9+v7q9nF1/+jhVd2p6Pf30hdeATTe8aZM1eW1UbbKi0a1bURu3om54xRmsV8BKj7CO
SXp1k7ZZBatb2MNtWgKinlOTJwfCd2kBu9ynOmsT9bSisfm2pxk9f+7V3uly29aZLqvK2WAL
tIE8m8u2H1Pc8nqj5usDva7ouYfVwJPbft4/vdBIDyuXyb16SDUoTbYpqGmTNaxvYEVcmWbx
yrN/0HqF9utpzeutUp2DeJ+i1Hf+2NPW1CN/gS1fe1qlSdbgIlhl26vNdr3pFjyjI2GWeqKn
aBVcMST6jpxRFOQMNEk3DZ0I2/W8g6VKULuAfzjBJINAQxNYWhfKZkVZNz6AGh9AhjVA9LUQ
L+AYC46CE8Ko3KuOX+7TCWpXL/TV477AiU8PaQOT/0p1g8cKTiQ0cHzkRB+0rRwe+sckG3qq
eTqp8Ujo67Da44oQvy8djy/5+5DmuDyOwJYhRpOjI7PlECJy5eQ0DGrGmwGn0WGUYDR0AqHH
DcVIlWwDDnch4P1NEaw5guHWtRzDEAsCLOiZ8fmHwhl1ATD7D1rOL1ezC62e1EVTZEWuVV0D
pcAdVBN6bvuLhx9ATcOQqU8wDSFhq7AcYk3BmLYNEt0INSUEUWRFU0Icy5IN+NOMQVvEBW0x
Eiyz/AgswPqYrYg5WytzsmIB/BwVBMwJlvXJHsuiiZp6DnOHUdHeGa3aE4+HQO/UEOgdFwK9
c4Kgc0AI9BsJgb/MIqmuajW+UKqj69UO10susVVwrXLQbpJruk0VE1hF3NxSYkBnIO3BXVwS
pD50m80Tva5o1oKe6sMO7k3pvngCD/Edktx0SiylZ5amEp5GGkFbgEYK1PVVvok7gN94eLVQ
OxlZuZny7xSojbxskSCHcTfcsfhC/kValCoZPU4rQ1ZhY8lBBeUFLS6qBxfVlB4oOYiDKv54
k0quqClXgKfpDxLQeLXc1yBGCHG+RiotgUor3Dc9MTELvZe4JQ32LHlCr4jirMzf7dGXKN/z
NKZ9nLftdzxnuY9wqPFVRC5VxPpBznqVNr4k0Ein+LmX4QU9MZJyqjEKqjFwqb9JfAf1BuS6
+YHmbbdOHDwapN9gOvpjxbnnW6pr3D4nHEk29wQt5EvxTIh3PKmfymNnI4CPvO+2dNQ9BYLU
KjXXKlZqFdjlZtu/4DQODsxqcDTwzaGhwtHklg/uHErHhkTI8s1oN09sPdwTmSNJdwGprR2K
iwZIvLC+uGh9yOlRcWG4uCi4uGhdcdFycQGx/LnniqLCiqJNMmIWW4Eg15pYE+H8p53ilzUL
bkR+Lt8HAmURyulsaJvlyI+ncZBrZ64Vc18gnFp0h8FLUBKLfUuNBU88LZcY/xUVgYCfd+xh
dRJUKyhflDhVokcC5HEobI51+vsrN+ZmeqseOzQB4l4x0THt2CR27Qp/7YQfpTJuqDLOuRbi
69XAvnEAIudnL87/ED4nbvN7bIWjHiBUyBjyHpjzzEmEvYWBMMmZglCrWsnLd4HlSsKMjfxj
vHoihqK1hUsIHjR1jduqsrwura/vEuUKMpfj83zImq9rLkbjZVdY2ldeDJ8pvsLyvv5iOF6C
hcV9FSbi0UIsLO5rMYbj5VhE3FVkDMeLsqjn3bnAQTLaGnx/5fkQPvZsCB+7LoSPfRPER5sP
4ePdhfBoQVa2ELuGC7LgXSw4CQ01Gd0jS8QjmWkrQ8I2dLMa94XzhJGGy9sNmApT2nEKPFur
+c6zEUIjs2oprBqXMrVr/WrOxEjrOTVpNKZ4F9p97w4yS4SJaIwUYFhCoaw3Htch8yuHnKXx
n0nwxwkRwk9bc9I64ls7JEROh8b1kpQO8eVeCtEX+uqR6ZqEM2NDmRFkKDeaitwE1GctngS8
VeBynwcG/qrgakfIC6Eoc4XkHG0hFueskKQjLMSibBUSdFRFgjGeCgk6kkIsylBBQaEnxKLc
FPEqO7wetVl5BhdhDJdFlUVloyAeF4NnDiy8rsPDut2RMnruUMPaHR7W7o6d0TMHH1bu8LBy
FxqiPB4cYeUODyt34cPomQCKKBc8olxCjNEzQRZW7vCw8vNoPL0Aj1hJL/moHMJq6KgO5KG3
sxnULWoGEWRIGfx5VRBTpsBWRzLVUMjmUuQBDVvgrCLPgQ8pJXVc1u0foReY79dbNbv5rCbq
psNq9Lb/89BD+/lht1Ce4LRu2Isg34IxLXB6gZYav9XBNgsNVNGcGHe6T9hUw5uK+ChHR7KP
Tt1APjKmaY9boWS6zF77kPAa8bvk43rcJkqjMppKWkgFpDXgePsqr5raubes2b2zHhNJlewg
Q0HCfNdhjQyZUoYlV9ms0a09XWvkD1zImvLVgrph06d7aYc2O1ZZZbXG3HC0Ue1zKmRHMu+K
Gqvv1LRu4LT7ezjhHQxiO2shCpZ7hW0f3Iwm+fSVkX77AvPESWCVfeVQPZgP6g6oBDZRZqXN
xx4ddX53MPE5NSX4puOtbP9IwS/YXp3k0aKlaxoh7jiKzC1olLoj0o6bBda2OGEhU9Tn5BEe
yVP9eEyg1TlxhEfiTX7Kgebs6o5BBY5SaExcOFLgKElGxH8Aj46tcCRp7KsmIoaPHR/Cx54N
4WPXBfGRb0L4eHchHKjvR1xWVFBpVsL3cCEs3wc99A8f16u0TSZIzzW0CkZTq6DxkiwA6NW8
23Rfl/0b9evVO7jLNlr9hwthKX4X9JSCGFigQKKip7pJoWJIpqlNboECoMp9xhK4BZKoqc7H
SfsU7VKibL48jAvpXnVsE7NvUXhzLLHzxBE12rPp9imy42Pacg2Of8BONIgJSbqHG+yabPI5
RYPV+iGFUeDUJc3rUwN9BUou6HmkUr8ZW3PUGnmObKpRa1RKawS9yp531PHwE3+t3P9CyZtM
wx4IbBNh6neaZKVuprcK2kI05l6wN5gawHyRf0gNNRbSE6FFhfeUZtOW5Pj1eqPu+z29s5dq
MKvgdg6doHPUyseJTK/maxokh7m5Cxw54GOLBQC0pveZT09lWRgF/oNM4EneOkeZeuinsEsC
+zGk4OJBP7V/pJdeCQpuw83KMJcYmHZrloseS+GPRVIXBIHBK3CTYgRQyoCTn5AT8GgsnMWe
vx+5A7XUZ1bicFgLDyESlIOrc1nvGtxxmeqCGtkWxO/BeOwINVrxF97KMslcWmxt22ADmmtq
QOHQG1P6rHiXQPGk4XL6rneU3mr4L6IJjNF4AgtL+wTG8JkEFpb3CYzheAILi/sExnA8gYXF
fQJjOJ7AIuIugTEcT2BRz/O52CF/Bbq6GD54NowPrgvjg28iuN98GB92F8ajfUiR26we5SUi
xsQEauihMAaiOnk5ulrRJua1nFCepYo6ueu++NFhtf9D9zkriWpl3a9fzu5XMizkwspUnhqN
p8ZcqPH6gUgYWK8hMtz28/7phT+Ak5BMbji9d/RJrRYwZCXwnweeu6N6fR9gSV85CMF82JE4
1gdvUlj6gdVvkX5tspYqQnVYWagDPDaQ95P/sl82PW7bQBj+KzzKQGKYpGRJPfcSIGmKFNge
ih4cS4gNuHa3dpD9+Z13ZkhZXo2VovWtJ4kckSLn8xlZdKGCSp/2G/3qzagKhZBv12iFpHIC
TrlQyaLCuJcRzoo/IPPXXDBRVVgFoci9JZ0HfQbffl08OZq7/tkq5/2g5ZgyboNczxWkJF2+
p3FDbAIU+OT2Z3dkAVcVKtc8eMtrGFoCygNyNbGTbDBdAnw7NDHKVz/M+f7gOVKl1frv0cl4
OiKU+wkKJ8Xi1l/FKGc27kXIatN1VKzxKhMidKdvi4A7HGWJe9c5kZ/EoiOt6dkV9nAE0lbN
GPYzKCPAGGlubIpGTEE1Fb4BeYfT4p9feQizVmzq9fBTqdHZ7ZuoIMeVNgorkUecBW7WAke0
Xp8n/S6Nd4tVKuPkKkd9eUmrdun7tL/THxzG2xGMjQ64yuQbVS3fYIdY7EkVCCynT3EqPnco
Pgtc9HinqOyfFTY+nL/wx0sAsy+m3GjwoAnPUXLaZprKiQJuwHFSX6eKmnNBI6kCzLHhoaSK
JHx2HPiRAh8rxoGbr59AWwLXszUbDVzPFqalMjjhdqQZ+A3/MUgI+xu/WYvfVMXTTbZ4lQtz
EtSM9wvhZygk2znOOL6QdKfZjgDP8dEidxV4djgVtHOSeWp9TpJiRwbPLN8mXqacEMWxWuFD
jHfO0x0CCLwV3G/ZhwLDfpUcuAXsY3RMT4b9imOXH4B9GE8WM+yXBPsE+hxSHU8v8ZcxWXty
qHVTz/rMf1dkH03wOSc8lNsTJPw7Wv/+mP1ffXazc+XD/6TboRAIdrcjUrvbmV6dux0R3+l2
ptfnbkfEdrczvTx3OyK2u53p5bnbEbHd7RjLU7cjYrvbMTUvdgkE/yoNlLpv9D4lHbQ6JR2U
NiUddDIpzVeekg43mpKa/Y1v18vQDP1N9EMYKB5ER9G2KgFMvyKmWiKTFixw5EeqzTy18PRV
R7jL1bmiOMeEVmdwJo+fJQC0b7jBgVXGgRATxQNSqRgTqJT0lz2njVqpGoHJ6SQUaT6nk4h0
grLM9RmAjVM+3a+PD699bswG1znit49AgKb4HRdqJnEKPJuP7MuMcFUBkl0X+608Xf/Cz23f
d2CIwDiFmV5YltWGU8l3Rjs1qCfovzaHAyu3xF9V9xGAiKnDwnOeP/RHbb2kl8Lsjt+XqqKs
g5takzqIoYHI/QPWnU5/uh8XkQEmMLVx1t/qs1uOoaJZUtGI+TIPrFYjzU06llStmm6Ci3Dd
qrluTeOYuhzVreQ3f0AFTfLFl3GP+FA7aXmjxOdj1uY9E3W9YZjXaiqrdPK60koJTQGydwsk
kR6a0pJ91sGx45CqivO4ijdD+mpUDY6PFbLnSJpq2XMqPSA9uxuPXOZ25CdSI+mGCn9NN9lv
N5c9z5Dm2CaUeCnwo2jRitmQIQaW4hbgJP0NZUVH7Yo0GWum/hKOhTNue0H6m9bqWn2rkI8b
cm9R0ZGkfwvcv9F67uACd3A0yj1cGLdH5ZVRy5R+Fw3dTDqyzVFeOtf9Rfq874EX8STkG480
feYm58tr96JOKlIeHIJ1vSRniFeZgVPDQExhVQ1V7hUxqdQkJmN1IiYV28RkrE/EpGKTmIzl
iZhUbBKTsTwRk4pNYrKWKzGp2CQmW/PJLqFRaRuIMUZifxe3bCmM6mcw2Pp1khu7J6P7OUy2
9k9yY//kFH4Go63tk9zYPjmNn8Fsa/skN7ZPTuVnMNzcXuXW9up0fgbTre2T3Nh+RmxD8SqS
jysUIwkJmYxyb5Ey0t8DANaFsS8KZW5kc3RyZWFtDWVuZG9iag00MCAwIG9iag08PCANL1R5
cGUgL1BhZ2UgDS9QYXJlbnQgMTM5IDAgUiANL1Jlc291cmNlcyA0MSAwIFIgDS9Db250ZW50
cyA0MiAwIFIgDS9NZWRpYUJveCBbIDAgMCA1OTUgODQyIF0gDS9Dcm9wQm94IFsgMCAwIDU5
NSA4NDIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTQxIDAgb2JqDTw8IA0vUHJvY1NldCBb
IC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL1RUMiAxNDkgMCBSIC9UVDggMTI0IDAgUiA+PiAN
L0V4dEdTdGF0ZSA8PCAvR1MxIDE1OCAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczUgMTUz
IDAgUiA+PiANPj4gDWVuZG9iag00MiAwIG9iag08PCAvTGVuZ3RoIDMwNzYgL0ZpbHRlciAv
RmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSInUV0tv4zgSvvtX8DbSoq0WKUqi9taP7CCLpDuI
3dlD0AfFVpzspG3DdtI9/37rRZq2pQQD7B42AWSJ9SBZj6+qPk5H76dTo7Sa3o+arKlUDv/0
0uRZbvNK1U2V1VVeqOmP0ftP21LNtsSUq+1s9P73iVaL7WgMzLkp1XQ2wrcS3n6ObpPLdGxM
ViZX6bjKdHIxUWN8c4m6+Cxrano2mapPHyZnE6XS79N/jnI1roFiclDymdTBKUSxsax48gFU
6yazySTFDb59+T2tsyJR518+n39Qk6//mP7rw/WZ+np1dv1hev71y0Tdqsn55Ot33kMbugH8
hGuWDm7N16Tb5Npvim+4qdaZVenY5jlcSOdZnbQpsOpk96BuutlutVHTixs1VhftXfekLtv1
+nG5UJfbBW96Nh1p9ahGWrvMWQ1b1llllcmLTFdqrDOjNt3ofvRxGp2vMCVbID5gTkfDUyUq
nf4bfehe9aGtM5OzbJAQr+dZoYuCtjeuCSZvcItk8pQRO1qkNsSly6oKXDVy3SZfVum4RPOz
cUFVXWsV8ZIy1mRONHHw1CF4ajb3tANbZ1Wy3aXjOlGfwNgObL6VZdmryJxuiuO9ItvgRtZW
Jxtqx2ef7DgQu/WWVdrM2IPDI3OIQC0ReJaWWZP8gqirkjU4v5ur624LiyZ5TgsIyacdxIq2
4GOXfL1jSrd5AT7apcnAs6cG1fvTg7pnVAJ3KLOyyOMzRRF6C4w/UogSCke8yeaPFMzSJNsQ
ds5mFrhrC4ZzKs+sU2N6Ury9SXUuUE19RNbaZEU1KI1kinUma1dgXEYMBuDFDe9uGojc/fa2
yfIDemGr17ZHcrS9y7PSxHQL93lFHMmReGWOxSHBXhMHciQOoXB499K61+7+BjlymxGiKSDf
T/3SQ47N3kOOzdpDjs3WR47M0kOO79VD/jh9G88AYioXgXVpfX46yU8NyQd4DRgwNjlsaJLz
dNxAktxDwQCkula3/H2RFsnk+jt/qEcEFwAZkMYyhWCDdWU5F3VCB1jf8dtDmgMCCBsgP7/c
CbusPzGvusRPlwjTWpjWJ7opbyFxACmVxy9BCLooAxhfFHIfOOHEiEQLqEsJHA31ACabRK03
q3VLyy1cHGoV0Tp6V626SCFOrNCgaqV8Tixd9LpESdbas5Gv14cgVgQMu0023ax7fEkb2BGY
krm658q5QQMXyQqUkqF3D8ijloHzF7ztAEjhNEhardVupVqkq2d4gM0KOEoFR2GuTdd6XXSq
6d9Ge5SnN8MnWnfd5h3uh57olvTz973MUfUQNSbEF/YiqOacLgI2VNdwCowcOA0ZSSPQQ1SU
yWaROgwCNWvX7d1Th+fHhbl69NIi/EDrLUmRHmYEFxZ4w3A8DvZwJ+fkThRBjqyKains6uQF
9BkMqxLWVsLzvH3ihT/R9YWPcXD1jtdVy98SzLUEs/NaRRyuqotEWPwB/K/sCaFMXJBOBk5C
SROfJQ6gKMZ1EZwmvQC5qwBLPqeSOZylNsMoMeJ9smjk34L9C3d83KnLb5MpFmTEhEdenj2x
ujmrA/8MRLRuwoEk666wGTHoMT4bhKVvAWETaEoAV8AVRXKTvRlboW3Oyzi2DGWFg4jolKQR
fRDgzDnSCvnETNDybGllETGr2WpJn5gqcOhH/mJ2DsoyOYoxE2JM8uZ5+ceS/WaSn6nG2y9B
OzjxwS+v5VfNMCq8m6EhWhJYlsk7tpqSzweS75hZlF0zSFbJNwyVJkGngWMbgeZS+GSHJ157
nstOousQAk6c16q/7L7DGD1yZH7SXJ7Wo+Pq8yBFYKs8/G+YQ0rGC3lOSsJKWCh3cYFyt47q
k1Qj1f4PCpHYMQ8hYZwvPRrhGi4PubiFKlOxC/Ab4BodyNBO64dOCQbSAqiYipYzG+MZgxVr
ks9sc5DZljPbHmZ2IZltJbMtZ3a1z2y/exg2EGpCPlse6AzHRH0QE5YjQic3CN44eSrhCtlZ
s/dQAaVnTglI39j+F/KUPRYx/wAQmoD0ufH1dL3a7DBzrWQuWBhOhsE/oYp9JRHwQDSom7PV
M70y846GE/XIXzMwLyvr3vWiH0VzFTzfyDFmaC4NCUynb/lruej4RRH8Y6ry5QggjACEEYBw
AhDGAwRKqHsuYWUg/cBIBwjz8GMYfmqCH1Yvsp564OnChH7Jm/AP8B4K4xN7JDDDz9RgJ8Fr
7xS4vFWzB/pqeXFBT2xNwLQEzw33MJp6GNj1LbXYv/i/A6itonYp3JLvaBHtkgyAwY+7gNQa
xiHDQ6rHohiGovA5zdgrxBg6uYWTQxBgZu4wkPBlLhk7UATjg950G0qDAqGIOueDKhcKHL9A
ma7LRkEqwvFQX8+Be6D0SEvvSz+YeDwQrNh0qvtFr4+ELPg4DPe4+/hr4NBrLF3WkbGmF6lB
e9+kugRvMnT32AtSooBuAAuPK0tUVWV5XRbMQSxn0zD3QfmH6/ZMhc4FKsxph+QwFvZLI5km
ViZrVxyNrGFu7Jc3DSTmfnvbZPkBPcyV/eJIjrZ3AAQmpoe5s18cyZF4ZY7F/Vw6IA7kSLys
j+4e5tZBy7NfoHA7P9aWBpUcmX6AYW/bAYa99QYY9vYZYggWGGDY33GA4eN01OBHDv/0Ahpz
CyBmS+ioLA5/PwZql1HYyllsvLjDLaXDdXGH66hpbaCESllr6RNmU255K1mACZVr2IKLoBBZ
mGsaP5l9Eanm3INIz2tzgnIn2U8tRS0tRc0tBfTdcyVt5AAwvPPtgVSpt0HEF4RC+yNU0rBi
mwfldKee1wjg0OnvNljmqa8rUWeJhbKU1g6r4TccHR21z5rsc8eSJABm599Yy/b5aadWzHWf
Yts01JWcDCztfC4zBY8dNNa65LdUWz9lqAsumtik2ITp6nyOVfG1KeeKhwGeaYSxD3KpGWdj
ZgSUvlJSzSn/+xWRS3cTofwLdT+O2gKMW2iCUMX9nxzGrEMq4V4PIJZjg94ixGuIycC8B3tb
QbSYIbAX6iDYD0h7sBfyMNgPyHuwF/Ig2A+Ie7AX8iDYD4h7sBfyINgPiQvYC3kQ7Ict7/1i
rFDLutfyffTYsn302HR99Ng2vfTo8n30+HZ99GGUzwG9XITyTcACwariGOUrQfkmznCcGzWP
SZpAUhNQlPJs4XsR2BSLtySxpPcVwptOGB8MkWST18A9ZL/2XSwhNZ0PTnfFUwmCDasL+IyT
G9cWjXMUzaaAtTBY0cSaMJ1X/cTqjiaRaj+JSJd6+Q0EEBIRsKc0vsCV7nBaXbe7lBvYBg34
Qj9wFlqEA63uEVVgFnmiFRxMaho0KhpV8CyRuD4sMGUoME6Hea6mAQoHGhzGLJeqGlEM35f+
d6Guf+Piqi4m1+oc4dMiTpJoJgPgwbBSZLZqmv97CM5hzBnst4U6DMH90gGCmfwKBPfLBwhm
8jAE94sHCGbyMAT3iwcIZvIwBA+Iewhm8jAED1re+8X4ThXuk/dYvo8eW7aPHpuujx7bppce
Xb6PHt+ujz4IwUVZQEViCOZ0Dp22k4yyFP+YNAGKYSWnxk4jRu4wqTTAA/aiHWIooNlFyy93
Ii3rT8yLjaUjqKXVtTD530fmAnyARrTwstutsC/8JsK3hZNhki1XIi8nUkeb79W+AuvcMI/j
KoRlhMoKbIKwCHieYj+M/eZ6s1q3C1psiWGHiCuliXtkXJXi1Mgna+Qniy0i5p5WmX0TemUn
vfIzWwwqHcEsgVXjL8ygCz9oRMDvd2jzkvyFrOiv0nOKv6z4K6w/MS/6q6aqSat+1/90XwYr
CAMxEP0dT0W6rbQf4U0/QUTx/8/d7GxSwZl4FOylh9eZwibsJP5+4Kter6G4ulds6hWb6LRN
ovR8batGaTW2iLR9aWnb0sGO1x6drzXOVlO+bia9R8K2b36bXv+xQJRTGeT+ACizi2s9ukB1
cnG1BxeozC0u9tgClanFxR5aoDKzhLhHFqhMLHnaKMW4bxRvM7fj47yP5J9iSVshQZNK8l8H
5+5RauCs1tw/OPePZgBOuoHbB+f20S7ASb9w++DcPhoKOOkoYe9c2HvLASc9x+2Dc/svWE4h
4zrXoawvgnb71Cvn8rQbZwOj6g5XCmVuZHN0cmVhbQ1lbmRvYmoNNDMgMCBvYmoNPDwgDS9U
eXBlIC9QYWdlIA0vUGFyZW50IDEzOSAwIFIgDS9SZXNvdXJjZXMgNDQgMCBSIA0vQ29udGVu
dHMgNDUgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNTk1IDg0MiBdIA0vQ3JvcEJveCBbIDAgMCA1
OTUgODQyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag00NCAwIG9iag08PCANL1Byb2NTZXQg
WyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9UVDIgMTQ5IDAgUiAvVFQ4IDEyNCAwIFIgL1RU
MTAgMTI2IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDE1OCAwIFIgPj4gDS9Db2xvclNw
YWNlIDw8IC9DczUgMTUzIDAgUiA+PiANPj4gDWVuZG9iag00NSAwIG9iag08PCAvTGVuZ3Ro
IDI3NTQgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImsV9ty2zgSfddX4BHc
WjHEhbfHxFamvOVcKtJkHjx5kGXa0Y4iuUg6mfzIfu/2BQQpCVD2YctVpsiDbgCN7nMab1az
V6uVFkqsHmd1Whcigz/6UWdpZrNClHWRlkVmxOrb7NVVl4tNR4My0W1mr35bKvHUzeYwONO5
WG1m+CuHXz9md/JdMtc6zeXHZF6kSt4uxRx/VVLcXrtvYrVYrsTV6+ViKUTyZfWvWSbmJSA6
AyfX5A5W4Rxry46Xr8G1qlMrlwlO8Pv735IyNVLcvL++eS2WH96u/nj9aSE+fFx8er26+fB+
Ke7E8mb54QvPAZuueNOZKMGByRRNRvPgFFIkq39PYqM0bRkeulCpKjAwtkyt5cBMV5nb2q0S
Rr9NlIJVLiAQ8LgSSZ5ncnX7mVaxWM2U2IqZrjSEWIFH3LfIVVqIuUq1aJvZ4+zNajK7MTY1
Z7OfL7u6eKQmT4uKbb2FylxAUp0bsHCxt3SodL7Kneqn5jHJUy3Fstn09GtL/w978R9hUpuq
kxiXaV5n1vk8Weu8TCtrLO5X5UWBQ05jn1EwVFH7fKjRiVzuUhqZTY0JLxG/k+8PyTzHrKD1
6LTKSnA5DiUv5y44mUufzCVve9Ukc5sWsuuTeSnF1TqZV2kpO/eZJ1F5cJbJhs+nUhUvd9lz
STTPHTuzaV3mtTjenPLFoFyaLSD6tfwbCqCQz3AkzYP41HR0JC+JgerY9SKZm6K0sNwP94w0
7XcYx2vOzo6AoqjGlYO/F/QC6y9SgwlysgcejLnxLdE5zLPmvbR/JcrA6tyOIOMrm1oYXWoF
OS+y1FZiTv8p2X+JVpVHdXkCK6WhOKLWCFfWw7B+LIrJAF3UcHpRe11CbYzT2zrNjnADhHRh
eoSn02dQFno6wMKGLtgjPLEv9Kk5lPcl8zqbmuflyeZzW13a/C/gybnpyqHaAN2cn0wIn0Y+
hE9DG8KnoQvik9iE8OnuQvib1S9Jtagqr5NEIL5Os0EOoAp1BjNpeQuyIK8TBZUBOgiJIEWX
FFSwFVbx86Ht+YPov9KnRjDEXxtxeEygboHboN5QYRjd9dvnXXPEdydVrbxID3T+dnEFjACa
3OyweNFps09wTT1SBUi0eExq5Hckuly2uCSEG3EL32ssdQiYvG92PPHqH8wJPgC17wYqGLfG
DdfyGQRcu/9b5un9k3BjOtbLJ3EgfJ9kcsdjfiaQSkqmybw+oVzIMGW036fy+3TTf27a7SNE
qUIfuB88DrCAnaxgFuRw3JeiUOOzS5AwG0H7riXbQrwVbpqHYLwZhagfkfb/IexbfhWHId4c
59ZHmZLLO9ZD09U9QY7ktHz00ok9vZMYgnfxzD/AHSZOSxsyctuDcDCSYvRzeawOx+HNSLOK
NCutm1bc4DSwn6SA0wCHsGp83zrqd7pxKn6FF5k7+b3h1GhhZRgPlwUuO1wqHO3e2rE7cVV2
2GNhWMgXDOLPhBrQFFdHn09StPY56rLk8YVUGCsRRvBaFFYcJiYfv+Kcd5mkKJMma1L1ZEsb
PDoYvqfHE/1vIJtP5bCogRZsTPAcGhW8iPUgeA6OC17EfhA8B0cFL2I+CN4wfVTwIvaD4Dk4
Kngxcyd4Do4KXjz0fDDlqHfgoziNfBAeAxuEx8AF4TEuYdjvOwiP+wrCIGURATOZvxUQn1Re
wDQnsx4F7A+sSSDu3YPYrNsHgWyGhOjYTKFi7Ykwe1I2K7/S2+GFHmB2fy5T1hbxK98LeCmI
1KAYiaigmA/83BO2g2rEjhyJE99RnrBQFZDHPQ9s+G0nfiQaiIUoqpDOG5S6wc6VMPHK30aP
mVx7Ine3IXBhsKZRDpo1cjeq9Tv+8ZRUkn+lZ2qVKR1v6lmtala8Gnd1olaK1AqngvXmtBd8
fWjX9A7rbxu3HuwXTrVpGmvrY13w5MDZPYUWgnjPT4ocuF0/8/tut+VTgCF+7Hq3i0RNGb/B
cqp/fKIg5Wt+8n9S3FJutmu8zOB5wBvv0ByT7XgcmK7ol84Ud7xb09IrXnrJh25gxq0bQmnC
HVYxxggcgwoQUR/YfrdzPwb7BIWBjZ/YxflceEiopbfUl31Oj8UUmg2FwnlNEpqbyR2RLlkT
YbCQWNGbkEPjwhC29sLA8AVhCNt7YWA4Lgxhcy8Mbvq4MITtvTAwHBeGiPkgDAzHhSEaejoY
UwNdjvR6FvoI7kMbwX3sIriPTQwfNh/B/e4ieFQfcujqSj3qwzltGEcDU5VATgKVcAhqhfsJ
9c9iQb14syeR6LlGoWsEJjlhHipTKy/fbvyaVOHbwRK7QWLRnKYF2inHtltz241zb/nHOIaZ
1ki851RjETsKP5maKBzuJsbUMQqHyFQW8w1jZGpTU7983AnmlU51rN4ZjJZ72HaodkbjxR62
Hmqd0Wiph42HSndTRws9bD3UOaPRMo8YuypnNFrk0XDzWQCZDyjkJaT8SbzD+BjRMD4GLYyP
YYngfudhfNxcGI/XOJyvzsYaR7HeeAHHpLZjdX/EOxC1TRrLFFMdeqq/oYZKriGo8oWrspyr
rIQqu1i/VER38obrBq+qdpii5CkMTwG+d+SyoFtVIfsEL53cBOGlN2NT8Sd3E+Dkz+Syv4nR
pImZNkr55GZHPUEuN8hOQB5N313u8Hw3rfQxPeRMD/Wkw7vBjVXyYbuBBgg7OFjSWjy3DY+n
BVfEiPhc92fdnQsp3XEz33oZd4bfsE/OsTWG3Jc93FGR7Rp+7aiL6923QCTIqfGJUbh+bs1s
DfSOVOceEGjqiajR64Yf4g4/wxzug3Cj3eujc/Wy6yPd5Lgl7WYnVSlZK2CGnno7A6HZHhjh
d/HluA8zKdBx9b/0YXlejXJ5zsuMxok5bO2ZmeEL1By299zMcJycw+aend30cXoO23t+ZjhO
0BHzgaEZjlN0NPTDwQwUZ3N0cRb5ADwNbACeBi4AT+MSgif7DsDTfQXgODlnQFoFkzMVofW3
xtJ1Oznkf3bUgv2O6W/k/q/9wWE/sPorKAjkLQFEjTSu5RV2O8DU2O1gB/aZDS+x9fnla7j1
uAtWh5y6fuCr0Xf+Rpenzt2o2p+4GJjlvfvQb/nqhcy3dd/cNe1dx5etFHlq6JvCvZgloqYY
qdyxLW2qSVCq2i2Qm4ZLnkLC+5lo7ULG7LvkVpTGHJ7FQ7M5PLAFxAyl7Ikfgod85bdGvCW7
BW3wKqn8Gs95mdaoxjWqMXpIX7e4sJyWbOU/4ZwU0P/9oe0Ti06f28MGVAHVlP9v6TstTvHi
lPSXWToez5eZ40vgd4x7I0Cd0T+KTA22dBjrPT0fBH9tYEdWum/Qt6K8r73/+XEmGKdueKB4
WnyguT/QgsKIx0oHSj96911s+y4mOD7VXXN9e402JTYhqsD9grQrjQJQ0pLp0VLKw466LWfz
037NyI7f3cOh+yfh4H2SyYj22IlILNr20KakFIOigNaUeJ5TRTkXE0w8GxUTRuNiErb2YsLw
BTEJ23sxYTguJmFzLyZu+riYhO29mDAcF5OI+SAmDMfFJBp6PhhomAuHFvURZq0esTPLOIpH
6tALRxqYdwAjrofzdvCl8w44H8CI8yEZHHwhGQK+BzDie8iUYeEXMiXgfAAjzoc0cvCFNAr5
dmDMt8sxB1/IsYDvAYz4/gUcbQqsMXBQ7sbGZOO45r8DAEHKAfgKZW5kc3RyZWFtDWVuZG9i
ag00NiAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMTM5IDAgUiANL1Jlc291cmNl
cyA0NyAwIFIgDS9Db250ZW50cyA0OCAwIFIgDS9NZWRpYUJveCBbIDAgMCA1OTUgODQyIF0g
DS9Dcm9wQm94IFsgMCAwIDU5NSA4NDIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTQ3IDAg
b2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL1RUMiAxNDkgMCBS
IC9UVDggMTI0IDAgUiAvVFQxMCAxMjYgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgMTU4
IDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNSAxNTMgMCBSID4+IA0+PiANZW5kb2JqDTQ4
IDAgb2JqDTw8IC9MZW5ndGggMzE0NyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFt
DQpIidxXTW/bSBK961f0aUEuRgzZ/D46iTPwwnEMS+M5GDnIEm1rRpEMUUomP2P2sL93X1V1
tyiJLQ0WWWCxMGBSrO6uz36v6u148GY81ipR46dBHdWFivHHL3UcxVlcqLIuorKIUzX+Mnjz
rs3VtOVFsWqngzc/jxL13A6GWBzrXI2nA3rL8fZt8BB8DIdaR3lwGw6LKAmuR2pIb1Wgrt+b
b2p8ORqrdxejy5FS4efxPwaxGpaQ6BiHvOfjYIU5WGdy8OgCRyd1lAWjkBT8cvNzWEZpoK5u
3l9dqNGnD+NfL+4u1afby7uL8dWnm5F6UKOr0afPoiPR7AEeOi9EQ5lXcFv8ZFWiM88qUZmk
6nry2IQ5zF+oMM/jYHx9H2aRDlo+83I8SNRcDXRZRkWc4EA8M1UkUaWGSaTVuhk8Dd6OO8rT
FC4cKWfFpDRQ4fg3SlB1MkFZGelY9sqOmPQleVFQAN0hSSynxJHOUxxigpuVpI8TmJTi6l3z
BDezQI2a6Ybf5vx/tVT/UmkElyWKQzmqo6zHdm21pknKa3VS1C6zNW0IRouIl5MVpd4/kVax
iQ/BzSoc5pRl1o4gINTqQLnoHeqjg6RES1eixtdxEw6zqAjaTTgsA/VuEg6rqAxa89mWS5Tl
ZXWoq+MoKcqy4khhUonpo42Ue/PaypE5agTVvO9o4go9MYV+icDXwR8o7iJ4RTaambprWnzU
wTZMUfmLjcIlq2LUQPDpUSTN+ivWieVxVKBAjiKa7OzHeVs6BV7kUZ5CdOCDLKay+BLqHMGZ
iC/r38MkhXXGI9R/laGcUfk6AWSoOMLdGfJ/Lv2z0qpyUl0eiBPkIC28u0lcZU4M++mKdBbo
oo4qv3ZdopZ36rM6ivfkKcDmhHoSd9UjHbnuLsjg0In9JO7sL/Thdlz2U9sh7mwH8Ow7DxA7
5fwZcSdvujJSnQJ8jjPTJ+9Gvk/eDW2fvBu6XnknNn3yrnd98rfjsxBbVJXjwNhe0dTwAi5D
QHcwhh4dXD3hrgJINi9hETTqOqyYpBLckzv1LYTejO4P/V5ixSaMCW3s8sXkkY5rZMFCfcVX
s3qxpRVYuRKFdOVQ84C5I9BxKFKLiTgz0XQo6iJQcwHRZRgHs67gtftjuSeitRuDvSsWPMEj
eLndX7fGDyQjWMja7yFKIwmswmdlvtsPv4sX478LEj1YHea0qTxelqLSbJYfz+bs3QlRnAhQ
cQjKRE58YL5Wt7e3Sv0tTLj3uAwLAOcmhKlV8EIfgcshJW/Nq5fdT2aZ+syiCMm1SpNcoo+M
FnXtgg9CNNGvTIWgOLISfVAdjFEmCVRSztlJjU5odKe2rfnVUq4R12fze2meCGwNBpgLKU3N
VjYji+oyr48AXruWyfQvXFrkQyM6FgrWwIc8oBotgntHGFWWdokJ/VFpnBK+Y6rYoX1RI06Z
D8+N1Ivnnt0Wz43Yj+ee/RbPjdiL557tFs+tei+ee/ZbPDdiL577ths8N2IvnvtDL4kpd3Ce
FRSBg9D3y3eh7ZfvYtcv38XGI3fO98t33vXLAdgemM6064QdDgb6sAE2qBnvmjQHmOjg+LJc
0FXRuK+EZh/R+NONKwhI6YEbxK2XogGAF8rd2dFIfKopFiF1i+ayGpy4v2X4TIIrNW/VomkN
LUyIKBTzjKZ/Q2YYJor5pnVD055CqwvIePZlzx7p+ByGpda2d3tGcRe45AcbhigV8iDjMjaO
gN5n3vQv2rhnWs9ws2+sNj09OLgSBiYyIRJl0kHHutnyO1NqgQS+UvpK+9vsUC3zdAnzpy9u
75LfnmXFvO0ST8+AOqflBRGsjE8Jdk0naN/lgzJyMZKY/34IFE6DR7MBgXviD7K1WZiNERiE
9u8xUFLKcIWAZFGp8/oQrHs4YjcrHZVjlu4mQpt+zBpFcCsEcqXakIk5ZLJfbUND+jk3FFQT
j41aY2ZEuFhkVmKWDHrqwVNyv+EsysqWy6zdzJ+4tOYUQ0mCKUBTj3MKGa/Arc0kZIWbFk2m
tFMTm2JBGVOcZ3RMxfXyum6mzWwu35/5v3pERngUc6d5rG7FmJXoFtudJeZaNJREgEbbbKSd
I1ksz4iwpWv08WU5maN3TOY/LEWnUeHHpujoZv+/JCutXbJsS07J0pwsjAwICodxHlJ31yz4
MVNfQjSNJcwCyQWUT2paSUS5O86RbfamrgFkIKKYUE9L/1dkL7rJZqYev4c6phBxJNEVKgrk
/Kv8CEm09qQly3a1l7m8JJRRNppUbOV3CyBGSVHPDJvpVxNq9oO/yWMl6AtCJqNIvHdlE+dT
YnyCySWbTFnOKEPEmkv+OKMWGQPJOvJmxbW4levcdz3ucXubw7jK296K1N/e9u927a2IT7S3
/ftdeytif3vbv921t0a9v73t3+/aWxH721vPdtveitjf3npDbxOjjTCp897Q98m7oe2Td2PX
J+/Gplfecb5P3vWuT+5tb3HP0e0ftrfpqfaWB9LCXVdt2tvRRtogeWxbIAwQbswQc83/7w8a
WoQ8TUtz6MF9GhrhIXofYRENnJpZSRDncr1erdXD5WdCbPRUsAatjTwEgghyYYDvJp9rD4/b
yh9qWOyHGNOZVbiX2UFj5u/JTAs7dW0t50pIAVoFxUuCOGKdVlrRJ0HaCS/YTBbG+L32VLv2
tJJDb1bSyglj18EcvencfKPOFNXwsX2Wl4l8mInURzxORWxUTBcrgmcKJ1OMppc1E7gORPK6
Wm98/WDqIgqabgjUwYEt2VjDwkPO3e+N9I6ftA1iAYYg7kkDpiotfVDFvAqvJrOv8pk4uDZf
V7JkzawElT2RPZo9JLIlR7bqxLU0AwQIEviSQEMKPTJOcFNfUl2cYSxcU8Dmab7KcijTPr4y
Ui9feXZbvjJiP1959lu+MmIvX3m2W76y6r185dlv+cqIvXzl2274yoi9fOUPvU0MxkMD+HEa
AZiPYt+7oBvc3gXd8PUu6Manf0EnAr0Luj72LvDSVpqhf44PaSv7n6KtDpLFjh10hx0yZoeC
4ewDX2i00d9CTb3mZD2TD+rhw2caG+idecMNDSxNzLOnqz6eG3wv5yjvv+tC3HWhQ3KlTp3y
I0hUQO9SE7+SGdSxv3ACG/WfgKXo7rBnJ3dZukN+O+Ixv5npdrWV5wJTLuN/yXMJKFQL2Jcc
kRJPRARTEgYUK/ARVWHdNZPdhhxIoTGmwYSUq6V5+cPI1AudqYNX/v8TUZqaiwimkK6JbFji
kO8wjmalvZHIsW1i2HbSgreIzTLhLXpM55MNfOAUY7jkqUnzwFcyG9sT2Y08s0dWZqZjo9Pg
KxqLwv5Y8o8NnU+hg/2JDGAknMvn5bNqzevzciKihfw2D7N+Zrb/tfbONAW2mqlIUEamiArT
yZSuiAoqIS6giuOSwu5n+oKS9oy19U79bL16fW1m0R777ur8BP2mJ8fF9My46Nlt6Tc9Ny56
9lv6Tc+Mi57tln7Tc+OiZ7+l3/TMuOjbbug3PTMu+kNvE2O5uU6iWh9HvkfcDWyPuBu4HnE3
Ln3ijt894q5fPWIv4eqMbN4R7jFa5AIQAGYdZ9SP/4oLgw8GGZYCFBPcHh0bTHnmbz9JR6wM
wmyAVrXdFSLmwE+LLxNzyo1dSxjfGTUyHjVKxyaG/w/nIWe6mSom6/W8ofGhIAPlZRNS+zzZ
bMMqMCKCiBQfr2U6uo/2KWtfSeL40s4L+5SVGieJOf9E05EHv8DxJPgnv/OMuHqS941dR3Zk
bFnOlpWR2JYdE1iXTXYOp7oLdjU8oUTddym5MF0FP92HPaJw46Tlw/mSYXJGaWjEXAAyKmra
zL/KD0qkpkSuzsw67XzRCFFvFt8JaOHc7N+Fl8EOgkAMRH+FI95cIgG/R40hQQ9G/98unTFh
06kXDj53gLbh7bq/l4NZ+4JtxbTVxZW/k07rzkd1Xa2TnYdO/T0y4+fp1nzZtaocavUfoc2G
XTfWQb6uXnGMLb9X9Aey8tTQ4+biqSaN/XrrljfnCWqwd5xKczKDyBo/DKNtWqUfQKUfxGr6
AVj7QaynH4ClH8Ry+oG3l34Q6+kHYOkHtRx+AJZ+0KX3xti/AK1aZdjRMp8Tt2hamwqaNDW8
M7EIZ8+Bs56H8cQiniMBnIxEmE4s0jkxfPhkYsJ4YhHPgQJOBipOB1bpmDfgZN7CdGKR/gdL
65fZGkbr+9YUX54vKpPEKQplbmRzdHJlYW0NZW5kb2JqDTQ5IDAgb2JqDTw8IA0vVHlwZSAv
UGFnZSANL1BhcmVudCAxMzkgMCBSIA0vUmVzb3VyY2VzIDUwIDAgUiANL0NvbnRlbnRzIDUx
IDAgUiANL01lZGlhQm94IFsgMCAwIDU5NSA4NDIgXSANL0Nyb3BCb3ggWyAwIDAgNTk1IDg0
MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNNTAgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BE
RiAvVGV4dCBdIA0vRm9udCA8PCAvVFQyIDE0OSAwIFIgL1RUOCAxMjQgMCBSIC9UVDEwIDEy
NiAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSAxNTggMCBSID4+IA0vQ29sb3JTcGFjZSA8
PCAvQ3M1IDE1MyAwIFIgPj4gDT4+IA1lbmRvYmoNNTEgMCBvYmoNPDwgL0xlbmd0aCA0MjM0
IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJtFdbb9s4Fn73r+CjtFixvOlW
LBZo48wgi7QNanf3oZ0HN1YS7zh2YDlt92/sL95zISVZET07wAwMWBI/8hzy8PB8H98uZ6+W
SyO0WN7NalkXQsGPXmollVOFKOtCloWyYvk4e3XR5uK2pU5KtLezVz8vtLhvZxl0ViYXy9sZ
vuXw9n32OXmXZsbIPLlJs0Lq5HohMnyrEnE9921ieblYios3i8uFEOkvy3/MlMhKQIwCI3My
B7Pwho1jw4s3YFrX0iWLFB18ev9zWkqbiKv386s3YvHhp+W/3ny8FB9uLj++WV59eL8Qn8Xi
avHhF/YBi6540UqUYMAqTc7ID7pIRLr8N05FS50XBYLcpA2tHR7GWukoQjaXteEIJdpRtz6q
WlbQH8ZTjFQXI+Vj9H5/3NylWQmr2EC4ZJncro6b/U68a9p2dd/QfC+XMy02YmbyHHZFg0sn
C6FVAY5xjkYcmtnd7O1ysLJ+prbQsKOjmY7XGtl946T2u5+MV9Y56HprJctgH9do0UkWXnG5
GuyJNHNKJe9W2ztMgjLZHx5TbWH/mhTgZE3poTWmh3/OeZu7YOhKVhgHBTkgtDZyFIbhNumJ
yY0W30dtOgxFXWEET8OgVUihQZbgWl3RLVsXvOyPzV2aY4K+FutDWkmTrLjhSP9ZquB/Q+9N
iknA7XcD9DG1sk6eIO8h7bcEtGQp44/1Uwb5wON+DGwIwd2aW/5mL5Bgr4WVuYSo4Y6cnorl
X6ZC5PcdJqOtpXibqu4OaY0DksVWUndcfWnsODSqxF6Y9WlGkyPHsMWmLLUY9CVjbMm8sMTl
puzKTclBXjaQWLJI2iOcp0RcrNKsgjC0vtn7srLStR37GqwUHTnYw7FDXfHcF0cuXc1Tyyad
NO5k8n7jeXba16xLiHsNO1PCVJ5gM5q1+Ni00GiSZ9jaPNke4WBol5dQID98ZaQ5fIN+5KWW
1uQvA6r72YO5ZzQCa8i5po1WwJ0xGx9Tk0NoVrySw694/OrErwcOWOWkg95FCTVOKOkqkdE/
na/fAqsqgKYcoXhUoRxFxiKKx5pRXVk8gwPcABdVUc+mLqXpXLtaqhPYuuKMa0R715WSuRnC
DlYSH4xoP7gw48FQRs4MBrQfDLt/uubcVWfWfB7tNsogTzBqLJS08WZM4324p/E+otN4H7QI
3sVlGu8XN42f0F2kcDsYpbhw0xEounNZ+9Ks4dAZKg+ZUQ4r5fUc+diibNFIT+IKXhScj3Xo
usHqVSe7FGzC55E/H/izwbKTI3XxcG/tEz+EePAdVvwIRn3rwfsKPto0g0HPu193e9/xe6pR
Q42c77tl4BGGcwRFc1wsdKc+tFcfx4cUlUcDAb1tNt/4Aw275PBXsT+IzVFssBQBFf9K6I7+
91hSc5gK6IPat4mvz/TsR5z0PYrOWdB5vtD62Zlucjy361TjPOap5r2o0OTVWqzQOlR5+kfj
ye1mheX0639So7ATOKr6NcFris0H8R2rnks2hIdeg8kMa6WtwnSKys8HNSvVSQEsXEu0m2EV
9Y+Dn+LdntHwfXzYtGIwuPX923bje+6Ark0ivTZmmoJc0FDM4FjnZTWq4DQ/H6UbyheD3hyu
bUc0Q8HGl6n1kUbJe964PBxgp3vBO9gTx4RxAQoCNMO6kYHx6jKvBZQPBRIr7J/rtK0/WlfH
/+IeatgrSMyV+AnknYW8V5gOq61o2PH0BF0vojyDgo4h9aKTe06NHT9WJA63hDT0zrmAb+JI
zQ/cM5Z6pemcOcPO3q5YVQlIQ0y0eVrgTQYTcHrC9qXYXRCHH1OYIv49pzWJtgKz4IKEQB9S
kFxZr5DIoJc1i2a3Zp0MIXyLSYVLzvCwh/ZrMEaFBrUhZ0RIJJRyk3eoq7lgFeYSvIHgBm/o
6sFtO5hmcWrDvLi8rHYplTBxu93juiD+dKz6Ux6WZbt0++wFWR0OALiylPzeGxwaUDqiAv52
FqNbgADMLStCStOBQAGar6qoCGE0rkKmR3cyhOEzOmR6fCdEGI4rkenhnRRhOK5Fpod3YoTh
uBqJDA9yhOG4HolGPuxL0CO1eak4puFhXCfgYdwm4GFcpuDBuifg4bomYNAa0wojdxDuqr/z
5n0ZML4MmF5aLOlsOqxHyGoNVhdLRxdvKDfi6bA/Qq3c3+63WDK/+W5wPwBCxntcDRWQWA8u
s1j/EBbYxKDwTb4D2hKMPDPw9LQ/YCubXL9QC0M+tt1x95WICdYxddL0A8XSJF+qBmQ7ejxT
F3KORM2ffacd8wtIHZx0pMD2AsFUnXop8JIEcaIn1j/g4ZZrWEU1zKD1AXpPH77DkYQDv4s7
KKJ1QA6iM9427djiacV+wclrvlY90+IOnpLvfTy8NezAgGja4+ort2w3LfP2Y6rx7tp4Opcx
VfD7BMCQ2c8IgCENF70CqJGu/lwBMJxgz8naBAEAZw0OgKNw0qp3/EAJYEECINLQe5AAqLiP
1P7AXWOKKM/7g5sHDbAWN3QiMWXoTNLua5P8E0xWdIqK5HDCkn+QDtCd/nTVUAdgBFAF1HyD
wAMTWoezcHUfvZrHU20hzYwrwResL4oiZpPYNqiuChhfBVg1lKwaBpqhpNMB8V7xc82NkXCb
TueEKHkNYYOGKPHscUOKeobf+X9D5Wu/o25yrBtKM9INnOZj8ZDnSBgx8eDRqHiIjA7iwcNx
8RAZH8SDh6PiITI8iAcPR8VDZHgQDx6OiofYcC8ePBwVD/HI874UvbSotazNOPLTeB/ZabwP
3TTexyaCd4ufxvvVTeNRDeFyUNwDDeH6UqR9KbKnGkLDk+oZCu2bOZyGKvlE/6gojK+CBZfH
nIsllFyqQ34c8J3Ga+eGGpstPdaCP1EzaL48QeXbC/5+TI3F+s19+V98Sf4mtPuSvpAS/rDT
Mrrbh69FUDA0URZMxaKfLGcBoI3/F1tuW2Fxq7uu96lCJscmAa5969/xVgR2HnFJVRjzY8Mm
fOszDPWvAkkT+XbOF6hP/h7lfXoHu3s/r4cvqXck8b5yysWjlb5UA7+HoIfMO0nQobz/Fi1r
a4Mh3ekm3TMJsI7BCo0sJpBPCuYTxXzifJDQ+vzTxAyznjLxrfJpek2hcxw6NPIgFv5txYj/
em5Pr6d/DMuEi+qfxS0AFHX9/3CLKxwd9Wlu8WiUWyKjA7d4OM4tkfGBWzwc5ZbI8MAtHo5y
S2R44BYPR7klNtxzi4ej3BKPfNgXF2ozrEeNYDjVLjo2BtKWEnh2R6f8dvik7W7DCT2/31PW
O3zSepcOhJ7NhinjHT5pvEsWQs/mypTxDp803qUSoWczadJ4wKeNh0Qj9GyeTRnv8Enj59G4
QlBQiY1XCFh1Eqo3r5ZLI4BmIFMMDYJHGGJroK6Ch3xOtJMGJIRTKnm32t5BLU72B2BDS3eY
Coj/en6DwgDq/ju4oq7uGyp8UNE0TBXjYWsHloW2ChUNcEEva3rvBtKoLEbuu8lWPNnpNVpI
70KNRmjFQyIXU9ZI/rb5sblLka7Fa7E+pCiVVtxwpP8sVVTdmeENcgu93w3QRwhGnTwBYwMF
bAloyVLGH+unTBWSx/0Y2BCCuzW3/M1e9juYipW5hFhJzUzSb5lilsZA6qLu7lt1TyqLraQ4
4CrxTjMKgSpZBDBVWs+BtSxqUJ+Drn2+ZOaFoeyUMHNPv8sGebpI2iOmirhYoRYok9Y3ewkE
QlPDiJEvz4jk8H+8V01v3DYQ/Ss8SoCzECmtPoCkh6YpUCBFiyY+JT3IXmWziLtr7Mqt/e87
jzOkpDVn3UtqwCtST8OPGXLeG8vEeT4hV7ekREYoD5sN96ewelevrbJ6ot910567wVZR38hB
eJdDEjzm0Bv3FJJhY/4YTvmaJCD0690Y5lqXxWIujDH5/1P22w1ZQWMf/6YxWAWxe89D4VUf
ncDTA0anxTa81vRGUBM0zTOv8Cg4yKS0sYWevXP8RheVzqX4aFIZZU3RbjW+0lEQlqAqYynW
gZIEtuvz5Evxu2QPeGb/LHeXrr1kDnhm3rUKryjmgTi02QMzaOZCDQKr3KCYvwDPwuYEpHqL
Uu6zuCTgudsT8NytCXjuthQ8c0sCnu8rARNBvJj7y5o8QgaU+7m0iAVBKxLe+rIXWe6VKyok
24/UslTOombxdQdVjb/iGbvEY9zYBpxtnrgMvJchA7iTnIf0T0nvYf9tf5BP/smJBS3VHphs
JeWmUvHSqpEVpzTy8WvurF+VBdfuuXeFRcwrlylBhDom1leF1Fe/fMl9LclVDCUmkHWOHMG/
Pa2vzraM+TZ2TLM62rND/34ws78dm5nXi/qpaiZuFT4oHjFxk7W0FvOZnO57oLmKpvMdeWcO
x81wNJ+u8yr709zwJ6P/NW9M8Tk383KyqpK8saD76BOtsRzqf3XcD2/mu5nrk+/lQ3KiJScy
Afs7T5rMMSstiQSt0vLcv9NmsP8jjniV7fY0WJeNcAcag7aLWYn77ng8HFmQkPB3dEOT5PZC
6PyiyuibQm63H/zKwKsduQQO6eiK7f1vn3s5RhR884S7U/kwAhniueWs4WLWcDzuNaRRl8Wb
7PgmO3+TW8kXNWcAG/KFlXxhs9RRxQYm8VmI5sBpIZGXPfHlptPywUuHMa+wA3480KKRX3y2
eUuPLjtsBtPv/ftNIgjRSbfRc5jtNOy9xtlAIJBGNb2BCkR73H3xwmd32487eccfL+44KzDf
EleNB3iV+JG8evJn7YDD4mjVeEknh9gyux1Wy4w1u7UhDGUXxoauDd7BFikRQu0hKOz8mtMv
ut75aGwDTrdMCUARA+1a8cjujnxS03LHuyeEmPLzhsfZUahJPN32R3kxcIKX3goba6N67sqO
qMqu1pVzmI4qu2Y9uwbGb3Wmwaj2I+GpqSxGdZWVto4qi+ELKittH1UWw7rKSptHlcWwrrLS
5lFlKbNHOaGYB5XFsK6yVM9zXNaTyLLlM7+n0MmrKXRyWgqdfJJE45ZT6LSjFEr6Ka2aLAXG
+ewQVFO81K1cC+ezXnuumugiQzc5TnyNv4rt1JU82EgeJPy9NPbbEbeGZBfU0trzJ10fECt3
DzLhIU6siqRE5XbXH7c+ew1XRFFobJDHfPHG2amiXBpaxMh/gZz9ugvaEz7Df89dGYo7i+zn
YkYthJyHxxw5Y6QkgiflhhKO8OxobgYvAnxGxOvFNywpwEXB1hygNmbAgqTqKE46ESe3cL4f
3CLF7kdOTD2/3nFvH55b8/4nFqwg9RpSJTTk/bXo2YVGKFdV3XXfQSKszySCohAQ5ej1IIl+
7sf+zgxkhkmb7GhOO0QNlNV45n8F7UXUz7i2BjuJLdkNlIKcS8rELKyIecyP/cZLP3/M/W+f
47utfOA7Z6oiHtO24sH5NpR8G7Cur+aDtHpGpPdwMm/5JlQ4Lv4ptiuO7oJ2KDdZUPzLrOOK
RikhwTqCqqyjWAfWEVhnHcU+sI7AKuso5oF1BFZZRzEPrKPNHlKwZi6sI7DKOrrnQ1ycgERP
xRK1NZ1bp9nqKGIq6MWYJmYOsDJ4CLnAl0OeGD7AyvDhRAh88UQkRg+wMno4MAJfPDCJ0QOs
jB7Ok7b2+XlKjS6wNrocN4EvHrfE6AFWRn8B1hXF2q7qqqigKP5jTbfQ5i9/Tins3wEALYxq
JwplbmRzdHJlYW0NZW5kb2JqDTUyIDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCAx
MzkgMCBSIA0vUmVzb3VyY2VzIDUzIDAgUiANL0NvbnRlbnRzIDU0IDAgUiANL01lZGlhQm94
IFsgMCAwIDU5NSA4NDIgXSANL0Nyb3BCb3ggWyAwIDAgNTk1IDg0MiBdIA0vUm90YXRlIDAg
DT4+IA1lbmRvYmoNNTMgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9u
dCA8PCAvVFQyIDE0OSAwIFIgL1RUOCAxMjQgMCBSIC9UVDEwIDEyNiAwIFIgPj4gDS9FeHRH
U3RhdGUgPDwgL0dTMSAxNTggMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M1IDE1MyAwIFIg
Pj4gDT4+IA1lbmRvYmoNNTQgMCBvYmoNPDwgL0xlbmd0aCAyNTE5IC9GaWx0ZXIgL0ZsYXRl
RGVjb2RlID4+IA1zdHJlYW0NCkiJvFddb+M2Fn33r+Ajtag1IvVd7C6QmckUKTJJEWvSh2Ae
HFtxvHXswHI603+/516SkqyITtEtFgFiSZeXvN/n8H01eVdVWihRPUzKsMxEhD9+KKMwSqJM
5GUW5lkUi+pp8u5Dk4pFw4si0Swm736aKbFqJlMsjnQqqsWEnlI8fZvcyc/BVOswlb8E0yxU
8nImpvRUSHH50X4T1fmsEh/OZuczIYKv1c+TSExzSHSETT7ydrDCbqwTs/HsDFurMkzkLKAD
vlz9FORhLMXF1ceLMzG7/lT9enZzLq5/Ob85qy6ur2biTswuZtdfzRlKswf4ad1MC3ht3KST
VExnTt0jHaqSMBbBNIki+WX723b3jTxI5RZO4kfs9kFKDn3mn3mgYM/mIZimYS6t7CmgPWTN
L0tRXd6yNefVRIm1mChVhEWiYEseZolQaYwwiKkKtdjXk4fJ+6pnuM4VGTywnANF5koRVP+h
5KroZHaTPNSRUTYqER2o0ixz0U+SLhI2/Df1g/H1R9EEhawXB35d8//dFp/jEI+hhuXsIewo
jBnVP8aMtBUYhbGKY/ZYZWWb/pIU5GwT8nKyJNfx0Mwop1V38mpHIUcp8MFlmJUFju6W8l5m
I/1qI1PHeVvHufG3qpH2MJPNIZjmUnyYB9MCWW3sZ1dTYamgMTir5ygdFKNLhgeqwpg+O5ie
qJ8bs2UaFrBQHDuq2m5w6ThH3Ev5HR2QyWcko16Km7rBRy1fAmRCbg6oWx1nCs/X90ZS73/H
OmN5FGpdlK8iqjr7sd8L7QIv0jCNIRr4YBZTaTwFmkp+bnzZ/xaoGNZZj1DqRRImWJ1rhbki
ojApxJT/c42/KS2KVqrzgVghB/DSp01i7i8jVin6VvcX6Cw9pU/inn42VI91cUqdxD31shio
J/DnhDqJT52eoKdPqUPcU8eIwRjoydME1vkj/4a4lzZdWKmOMWNeJ2ZM3g/8mLwf2TF5P3Sj
8l5sxuR978bk76veCBufpFlRtDjJHZG1Y6S0Y0QBszRag5oxwolaVgyQibwEWuTyFtMFL+Ky
pvmSye2KBoJ8FGv6aYJpTDOXv+3sVu5XbOjr3Ojt8VHJVQAzcmn3+pHkpge1mSpT/6CiIU2D
UDsPosIOQuxMAwX2Rtj0VtTfA/LjUG/5d0k2FpImDED+vv4j0Ag8WUmfj9aIwyO/1sLpit1D
gJD2JGwujOF4pomzprBzb0Hx4t2VQty2BxrHPHno89q8bd3vSjzRKEooIiRvGrtwZT+EFCmE
X7TnDuOiuEoTgaGPih3MPnqKlbEM5IaGKmUCjSHXW57QB/KMHuqW6QygNu4OPN/vd3uDeFkI
1IiHMBC3MGDL69P8MN+IGnrG471o1iumRVv+P6eCyOSmXhq5z4i0w3vL4+6RR01Ad2DoeKTs
p/Di/RwkhqOvqSQAgKhhTu4bmbu0IecKJ1sexew4e/btpREfXH6X9neQLl+yUEpxWYCJJFnJ
XCID3KexwX9e0YERSEIIbumBGyv1wo1H28GNFfvhxqPv4MaKvXDjUXdwY8VeuPGoO7jxne5G
qk/dwo0Ve+HGH3mTl7xDG2LFw8CPiru4joq7uI2Ku7iMi1u/R8WdX6NiAIkHPmL0ZtGHjxY9
TMtomvQD6CDQuAwIQG6JbeUMDkR+/6BmVPKZdbhfMFbXRtbQfQV980J3GF7wLVCEO9sgkgJd
haVu80d8suok/YGFQxBJklEQeT1YVDdY7JwUFw8BehoDA5aj2cxoAQO2YyUzYyXlsZJIu4in
kQbVhUsJw01Ovv9TRN+NeoGZLO7sXmbNyrzYb93QILuyzq7M2LXbL+u9uPsSEHX9Ku7pZkMz
iS8W0VfvzMGnwUPUD9FIYI4AdyRCbYD+9/j8+1//pwApGyAHlzA0TYhM/C146crtz+BlvzT/
Sj46v+1Niw75AQyh4csWRS7nyKE98G8eUNcBYIVBTDUAwmFP227tdZn4Yhp5tDfHW76fKZ22
jM1C9+wwP7yATqWoArqPiQ/4KeRuWYv5lr8vxfzYyqilfbE2m1zt6CzQvPUD/E7lejE/rO23
reF63wLQZS3Xm424N4Ka5oySntSpsqUvNrZEGkEqgojpCrIfGMqxoyrIuQrMEqY3Cldb+rg3
02xRh2N0ZpzXqqI9W/d5bSnpoMJ2F70zz9XguWs6mrmh6PNDqpG8K5LceVIw/ySNDf+v4UvB
NYKMHXoCLhOEb7nfPT/XS+uEpS69vum4i3WnX+jDIfxWWUctH9O2nX+l6ss4e6CMGRcc/d9R
geJCUR+5rNoCUfZewBmyXD7nQtkfs3dVFK3xd/IJGKSISa74+lIMSNxf6NR2otiEXoD4Uh2x
B2Q/WSjXTd8PleY9myp0FZXVbaBSAJ29qJ3sref9blGbtrLNxTeX1DuvdHslJKCnLfasT5OT
5zduQCiRxG6Uj14U/nQ4e/Q2wUzPvPTWSP30dly7pbdGfILejuu39NaI/fR2XL2lt0bsp7fj
6i299Zze0jyPuqO3Ruynt97Ic17iEqTPSlUWhaUehN63oI2tb0EbPd+CNj7eBS4CvgWtj74F
XrKLG1moLdl13bBoO4RKOqbBkx/TXUUD85L74lbczjcv3DkgOY14ClSJ/sPdkTjR5iEozOjK
mVFIK66NeGkkISFH/prO9hiravtV2X4FzKXMkohR8bDLpcEnatZ9vajXv5uXYMqEBmhhpHPz
wagsCcJiMIXGMKZ2h/7AiTvaFWUdThGoEuvDpNLEGO5fAsRfEvXDTgugOr2a/zuDjla2rBeE
++btkRcYqBtueTTse4OGgw4zw2N+h9GVleXfRO964dctR4hajpBhvNKwzKThNaX9ZthMCTZz
BM4nCSJ6TMWxOy3uyLc77oKiqOSh3j/v6wNo3ZwOQ8bnJuoKE7cccJye/VGLGNoixnprjF3D
c3oAh3ZPoqmNkMszdUtXRmFnPiKA8RFcjrKZGwYjV4sFmAhdEbb8vOL/whKbGSKZ2/UhdYeW
A3qj2tZ07ObT/DDfiBrRpGyiw0Szpl1jPiE2hZ4RCzby44S8vuHc2+vK8Ibzeb7hD/YCtNs/
0bqSuZR2eR5C7AlM9yTpdY+bKud2NOyZnm2jgj0Tdw69N0BL3YowKpL4mLlZ0tbBcpJjlnlh
2Uq9sOzRdrBsxX5Y9ug7WLZiLyx71B0sW7EXlj3qDpZ9pztQ8qlbWLZiLyz7I+/yoh2glRqY
dSSOC1xvEp+yX0pJtdKTSR072sk9u7ukW/HppI/t7+Se/V1RWPHJohjb3sk927uiseKTRTO2
vZN7tndF5bO+X1Sj21u5b3tbdFZ8sujGtndyz/ZviL0kK84BVZklWW9dC6UbTf8dALQMOdcK
ZW5kc3RyZWFtDWVuZG9iag01NSAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMTM5
IDAgUiANL1Jlc291cmNlcyA1NiAwIFIgDS9Db250ZW50cyA1NyAwIFIgDS9NZWRpYUJveCBb
IDAgMCA1OTUgODQyIF0gDS9Dcm9wQm94IFsgMCAwIDU5NSA4NDIgXSANL1JvdGF0ZSAwIA0+
PiANZW5kb2JqDTU2IDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQg
PDwgL1RUMiAxNDkgMCBSIC9UVDggMTI0IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDE1
OCAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczUgMTUzIDAgUiA+PiANPj4gDWVuZG9iag01
NyAwIG9iag08PCAvTGVuZ3RoIDUzODIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVh
bQ0KSInMl81y2zgSx+96ChzBrYghQIIfe3MSZ8pbTpyyFO8hlYMiMRrNKLKLpCczj7F7mOfd
/gBASgI0tVU5TKViUvyjG0AD/UPj1XL2crnUQonl11mTNqXI4B+9NFmaFVkpqqZMqzLLxfLb
7OXr3oh1T40y0a9nL39aKLHtZ3NonGkjlusZvhl4+z77JN8lc61TIz8k8zJV8nYh5vhWS3H7
xn4Ty+vFUry+WlwvhEg+L/81y8S8AkVn4OQNuYNRWMe6YMeLK3CtmrSQiwQ7+Pj+p6RKcylu
3r+5uRKLu7fLf1/dX4u7D9f3V8ubu/cL8UksbhZ3n7kPmHTNk85EBQ7yTFFn1A92IUWy/GUS
G6VpyvDwcSmqtKw5LlIVaeEsrGMNXzI/gwY9z90rTuH947D7muRpI3frpEgruaK/w+7xIN61
9N73/G2bqAzatW7odkx1akrugh0XLkqZjZL4U2BYCrDM4e+h7VZ7sWz7Qbxe9W1P7q6XMyV2
YqZUndaFgmmVaV4KrXJYAgGOYSt07ezr7NVyEoQ8VyCcRCEQvTq0s5QubQhzM4bwJODzPIVF
gRGoVOu6OQ6kXOxTao8Tr3SOrVRRlL5Vha0wxsnc4LagqcJ2KZtGTJqSL3akzxzxnq78nq44
qMs2mRdpKfshmVcSIpnMa1wr+5m7UrD6pqpP+5oEBzvKIWNOO1Q1D30xcH60Tz27xJjVWhxP
VPnMUHbNrxMDW+V3WPZSPrXrod2Ie1hqk2r5DLvAyP0gICvrrIIvd19YabvfoB2PPEtLWNSz
iKpx/ODvGb3ALAynzskcuPEnaPgt0Ya2Ns2l+zVRuOHtjGDr1ZA30LrKYbfBDkmLGrcc/KUt
95dqXXtVVyeygjXIy6g1yrTfWVawj2FrThroMkvreO+6hI05dm/qNDvSc6DThe5RnnYPy2H0
tEEBE7pgj/LEvtSn5oCpS+YgT8zN6eRNUV+a/F/Ift00pLdV4Rxo9OnKhPUx8mF9DG1YH0MX
0X1swvo4u7D+ahlFmz8csgx2B5ONUqLQLlErzYmq4ACDRhKzETIb3jDlMUNttthfz71Y0lnX
yFs4DbR8QNA0UuxY7xPoALjzLVHIH2t82Fj3x84e7dcOoWXkH5yPztUhUXg2U3JCduBQEQOm
PE1tfMuVO8dsD3CaIXR26xWcYXYUBCPxrt/SS4rdKIdImEQGJ83YwQi0PM3yqmT/D20HnmHF
cbQNwATKhHllTMGxy8GH9zkhSgZN48xgNc6MsLVnBssXmBG298xgOc6MsLlnhu0+zoywvWcG
y3FmRMwdM+zoo8yIht4tjPZJBQtdnIc+pE9DG9KnsQvp09gE9cnkQ/p0diEdoBBGQVmN9TNl
kCcBuKEdrrFIqScguEqUgnR84u+UTfhySEpOaAVZsCcqwPkLVKgh7R56JEDjZMiVGgufL2za
8lexYx/r/TM9N1bduBGEM38sqWjYOQ+bfIHPFT+pR/BhS64Oc73kHnLuH7DzggeUy2eyGWjM
CDn6CYXpV5hMIa2P/d6+fE90gUk+/EztWh7o8h88Mn/t0Pba0Q+rAT0iHMmOQ6UpVI18eMFx
MDB2wSWiIXxh7B2+DPGQGtEYc+trS9+AZHjtOCYZbGAo6X40ycoaVqqIkcyqUZJFrB3JrBwn
WcTekczKUZJFzB3JXPdRkkXsHcmsHCVZzNySzI0+RrJ46HlhzMi5vMDL2Enow/oY2rA+xi6s
j7GJ6H7yYX2cXViPk6wAhugJyc6QkLvrliPZjWWET1yXmhWlU25TExKzga0Piekb/odA8DaB
Ekz+l94dOnaD2PUXUeVrFN1YILSDGCipoRpR/HyBKYy1D5YttR0i3LcsERpb0NQTIjREBEVE
QJD0cKGqiAjwzY3JUimnexzXTJbzA8yYSjCNCf+lBdgR5+2XDiiHl7JVt2k3aQAt+Q9Hi4Es
jpKFxDhYgraeK6RewErQ2lOF1DhUgsaeKdx1HClBa08UUuNACRs7nvC4oziJhZvXIoPkukCT
iD5GNKyPQQvrY1giup95WB8nF9bjNMlKuF2NNFGNy1plbxbFyJHbBK4tuVxAwtXynmoXcL9u
d79BijZQXmSQjMad6APlgruKHKgJXEKowZZ/neKjKDw+tMdHZvEBaKghfVaDWK+6bteiJyx8
BL8MAKlaItewlRXXjxtbpmSnfFK+YFHGl1KwXbFYQkLsEsQBjp0/b+kvdIezogIQoiyH1V60
XffINt05MDLlaxFfctrIQmBNqUsqHhU6w8A2FFhA8nr/iJMoZcsPRGPtii6oE6vGnMYsKz1y
CxuzjurCUvZUxtqaruC6ECu/tf3Arfhvu7akdZ9jEaz9hDR3tzoQqzewK/btCsdd8PDh3Fjt
92K/+tLuPaAJy0XhnFR2zG+vk3ktX+NBQ1HZ8VgPm5Pf2x7qvwpdc8wx+/NC5GlhqhrHWKZZ
ZXJyj56RxstfpuBVgOPo7dSqcfSGrT17Wb4A37C9py/LcfyGzT1/bfdxAIftPYFZjiM4Yu4Y
bEcfhXA09LwwsOHd7a4w6OMk9GF9DG1YH2MX1sfYRHQ/+bA+zi6sRylsYOC6gEuspbD2SZHZ
0sIcVXNUiBEPC6zmkhLolxMbn+kbfqGaLgeSEFxqW9axxbdE40UQm23Z2c3mUi1XGF9GOVj2
hNmf0TfUTs/83CeG77NYUGFtNdAH22rFv8QjVFxUfB2prbjFz418Q8fLBxxkThe+mi581Oj4
ypl73FX+iEB2whExdLstvfPfFodUyq7dINdcKQxVbC8O9PLI3+n+Oak1K8ky3TSr0E3zh5eD
pmzGI/yMSlaNUili7ahk5TiVIvaOSlaOUili7qjkuo9SKWLvqGTlKJVi5pZKbvQxKsVD7xbG
30MDtWFMn4Y2pE9jF9KnsQnqk8mH9OnsQnqcShrSMxtrQ+0LGHeXKk+opC2VNFEJihSqyhrL
JS35myWTLXtKTyZtyWSbbdmha/xHorH4fGovVY1/M1CdlUx/A2RNCtIfhizYTf68O0cWq3Fk
ha09sli+gKywvUcWy3Fkhc09smz3cWSF7T2yWI4jK2LukGVHH0VWNPRuYSa3Qai1zyIfkKeB
DcjTwAXkaVxC8mTeAXk6r4AcZRW61ZN7bOYrKG23doXJgXcZR6y7J/5i84ZvPwVe7BAKe2Fl
+7tbfcOM0JyXRg5t1+Odxtp+RwbUTtzYvnbs8lJplflrqDYTIiBm3pNvwxkOPY85bmisQBka
E6KnIPTQt1XXin8eFUpaeXA33If6LK5/J14N7YGeG7xVNbLdiMXAuGYOV47AJePayIcj33nt
ietOBf1Z3JN9myhwOcDgjHwGqtSyO9ADennXJ3h329Jv6gLb3jJwH6iaPepH+cNH2W7yZA6A
kZ9x4ND4voVRV2DcHeiB3ERdfIDrJNL6I/VS0LnT4LEzZbQ7Qya3RbwsngH8vDK/ShRdR6mO
pkMK1uDRldoJ/uzOanHxUjytcEtRHc6tcEdh3X4E7DJtdFX9f8BGezhAq8Ycjf5kahDX2MtR
SAKBiNnh3Iq8EFhnKGxYplll6MjDcUELOJg0fDgd1o8bEW1EitIneQ/ZCNyUX+EobMbd9El+
TOYlLtmvB8gmpSF5Fe7FQ5Id7TllKre3lTuul7eJxlx7SJTBukCVtOo5Jv9TggvQ4n6oz87I
ogExeOPFM9Kq0TMyYu3OSCvHz8iIvTsjrRw9IyPm7ox03UfPyIi9OyOtHD0jY+b2jHSjj52R
8dC7hdHuBFXKYAjOYh9sMA1usME0fMEG0/iEG0wiEGwwnWOwQfTEzKsCLjuT6v6MbPV4Vi6e
CWfrdYuIwv+QU1i7iz8925h4/yO/2nZdt43or+hRBhLDEnXNW4EToEXTNG2B9Fnb1vF2a9iu
rL3R9EPyvZ01M6RunH2ApEAL9MWWuDgUOSTXWnNhDpPfTkgx6U7vgjGtA7qDtMncer40BFJk
JaiXy2RiN9KlFmPAjEIdaxrLqyPapAPUsaEb+dyhfjhL24Jdl9wu7MpPhcWu6oHz9Pt7cnzl
D3c3/jvzb4+0OFZ+vMK0czOXQzmXQ47LIbRK254GzQ7MKvRUUQowwIo+XDP5oQ17CGiSRzzW
c4egNnXEoz1zCGoSRzzY84Z+2qSNeLRnDUFN0jCClTN03hZlmOmWvSDB9yjZvkOxznccnzIa
x6ekxfEpLQYeVh7Hp8XFcZsqStrsw0QVRRY8X6ZXsp244vd03cj59I+ErFFJj9cdfNiFf99h
gMgZquOrtJmMUA73uYP7G+BNudtD0IH84jf8tCEK79vU2x6D32WxZr/XpDDULTET0VLy7TCw
hc7oM9/rkxjsamawMzbYRBd/eJ7l4WdpnnvGBUkFe+py+fgfQUJNeqSr3z+fwkx5Ko2YSP8c
uxdpvF6er9xO7JGLF0fzVyDJnDqD4MqVHQ6kmLWhbKiRWXL/NPqNX+6wwK2WCS2XCTUTFS0E
S258jyHx4RrJPNZoX+00XrpRXHW7nMyhDpl3Mpm/72Cw6Awga8Rm3fXyLk2JNnGlRHst+XZS
Mjmsmenv2d+4vzYnXBTV2MPFh0PW88ZLAzLHYzYqDe1sXxvtsMdnGm+WvRxQtVNnmZ6nqPtT
c/eUskvtX9JJ6w1uHlMWpdgWF5PGmPIy8+5TIJ8w8dF4apyvPKr0M92YgiZCm8LiwwUQ2V1o
z1Pfbye+a47uGne7nRMNeKXCo/Zhxoy3Beovq0t5Zwk6XrWrgL15o8J6nQsnvOQjNA7djR+f
D9wUJ1bAYeFY1Ti7cS6VnsvLE85rpkOzhtPWERFe+w667PCdV26dPVy7l/4axpJ9KWc7+sKZ
LiXTjc/89H5+7lGN+svsCyaadVaU0YppZgFIPqrG9ACC2iYgHh1cgMAf2IB4fPABAttGIB4e
nIB+3rYC8fjgBQS2zYAR7t2Azt60A2bq/cZ4Oa3abdrX2Dyla2yerzU2z8UGmy10jc1XscZM
zadNXZQHRT5pvipcdoBzLYtcRb+cRL9k0W9Z3VsR/TyIfqnNJPqOJd8Fyc9F8tsg+e1/UfK3
xHQIVz3ly+mFg5bAWflfEw5PccdAe6IbdDghHSTp/UDn4NiTOtcsEHAoeDrzrxCfQ1FXrDIy
+0IeVPigKkw7m3F1AwfRiJWBnQD5SzNzasOHgtkcj4I87sMYS70K0DGIEj5EtSSblQNXU5VU
l/SLSpNsAMYttQ4tJ3bnGJlA6QXItDLqPJj7F9blmuj7ZZfRZi78ykXezvyL5DmUeXPKJ49c
1s2S8vVkrXg/bzO79BPQZP14rCd9QW3Oj0d7yhfUZPx4sCd8/bTJ9/FoT/eCmmxvBCvZ67wt
rjfTLXtxmEqnosQQq3zH8SmjcXxKWhyf0mLgYeVxfFpcHLdlwJW02ZMM5IFNDsomZJiDCvyl
xx1uU/mlSyhXkIjkz3QTKr6oRfo38qdpf6RaAmLhqP2ESqcmnWj4eqHTMF5klB5kggsrI40b
PZgRhGuDSB3aQEU5DX0/9cnPqj9Qh1bFCbTBxdXihQgDHZKelGNY8sN/yA3v1Q1/euPX4SJd
BZRqB9T0HQ3Zpp/Annn6g/r6MJ9gkJUMvevFd2lF+L1Q0Xa9/EumJADKSi0qa/nU0oR/6P27
k6zsXSYIJpS96nWRvSxk9IvWTGiYBiS3ebgsOqRRisySN+VpKIGqIZ4KmdgbLadi8arS7njs
H2P3cu0TnKFcqlmnKFewhWpblV6kC803x7mTtzNDe52tUSSK/W9CWabi9yPqjlKqqho1CVE+
FIk9xuefIL6Uf9oEGo0+9ZsdlvqZNKRFHVeyni1CtZCrfTnR+MFu569QTZCuaiDqudyHLzzB
Wkk3kt0dx8u7KvKjJ1sgmtz3J5HlZLwv655piFL94HPskNoME5czML720sJLwIOcUIx828H6
JEPIFuBRX3+CiWyXVZubGaDHcD/2pzdyMEgSF2u4syTx7DCYa7DBrXm0XTlRhZ7tke5njgFh
VZgCSiaEjD0Jg3tKMJ1L8Aj47pX7UMI66Se/F+76LhjtaxW1klE/w5nXJdA5kD/DqbSzfLCH
gml9PuQkeMMLYi3ScWU+qGde11+oN/Oi2NeVaTwEtZ1HPDpYD4E/8B7x+GA+BLbdRzw82A/9
vO0/4vHBgAhsOxAj3FsQnb3pQczU+43JfTXaHDCFTepj+Dy1MXyeuxg+z00Uny0+hs9XF8NN
E0Lu4ksmJP9/MiFZUOWZBVEDUk8GBHqn5qNh81FB19h6pMnvxoT7HI+knOnwTKC5KT9fEIee
S8KfPusy+e53nIxPQpg/sFrl7Ds48QvnAbXi5j2ynK00lTiqalu7YtV6V6rdYiGev6qUNcSx
Dccrm+pZLuTEo8GTcUXruRkyc3/0QzfeRThbEU42c4udC4yfedG5Q/mo24v8s1UpOIs1+4IW
haxgA3sUOpwnjdF26SQrXMvENplIVoevkPe5vnFShn6faCqPgoyaRtI2fKNOIUxxJc2CA8r0
PGLqjbcOBVsHeRp3ML3dMMpcm6U66xbwYXPBXVTeXfQiaeIgWnYQuTqIWhJXqoOoxUHwPj+k
r7Zq5DH4LPydpPFtOdAepzZPl8I5mb9JOFmCN+qZVe4D9VTUVE8j2qunwrZ6GvFePRU21dMI
9+rpP2+qpxHv1VNhUz2tcFVPP3tLPe3U+40J6lO127xvwHlSN+A8ZRtwno8tOFvtBpyvZQOa
QonTdZh0sqiCEqFgYqF0k1D+lhx4iyuBIudKF9ThKnDFIxoFK4tWoh24yH4HERuSb//Jd4LO
+j8ocQ0LUpPziXD0l9PBIH+Jqf41uW0nm9UNrWY12+kiPfQe/SkS2Tg6Mdt1HgID5UoWl0Fq
SLq/3/BiwAVU6aJ2eqKsTNgvNylno4aM+V5clBLNjL6LH4hkM2vBOMyUVMqxKYfsPPtFT6Lu
kB+Xl7P81JTcL2TH1cXerdc4ZedsZ8fVxGKRU5AF3c7Ujgj7ZmDfr11VF1wsfl2Rl+HKVCev
96WdmbUNjwlo0lg81rOYoDaJxaM9hwlqUlg82DOYftoksHi05y9BTfoygpW9dN4WeZnp5r1w
e4/R9fS+WUE6YnakCWIXBbR3MfpVj8ZH9nss6Ad7HB3bo/Gx/QkQ1D4B0aE9Gh/anw+dtn0+
omN7ND62Pz2C2qcnPrSixtB6tjQj5tmKDu3R+NAfo/8eABjhlxwKZW5kc3RyZWFtDWVuZG9i
ag01OCAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMTQwIDAgUiANL1Jlc291cmNl
cyA1OSAwIFIgDS9Db250ZW50cyA2MCAwIFIgDS9NZWRpYUJveCBbIDAgMCA1OTUgODQyIF0g
DS9Dcm9wQm94IFsgMCAwIDU5NSA4NDIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTU5IDAg
b2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL1RUMiAxNDkgMCBS
IC9UVDggMTI0IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDE1OCAwIFIgPj4gDS9Db2xv
clNwYWNlIDw8IC9DczUgMTUzIDAgUiA+PiANPj4gDWVuZG9iag02MCAwIG9iag08PCAvTGVu
Z3RoIDUwMjAgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSInMV0tz2zgSvvtX
4AhuRQwBkiA5N8/YO/FW4qQiZeaQyoGhaFspWXJRdCaeH7K/d/sF6GEiM7Wbw1YckUSjgX4A
X3/98+Ls5WJhlVGLm7MmbZzK4B+9NFmaFZlTVePSymW5WtyfvfxlV6puR5MytevOXv46N+p2
dzaDyZkt1aI7w7cS3v44+6jfJDNr01K/S2YuNfr1XM3wrdbq9YWMqcXlfKF+OZ9fzpVKPi3+
dZapWQUSm8EiF7QcWCEL24IXnp/D0qZJCz1PcIMP178mVZprdXV9cXWu5m//ufj9/P2levvu
8v354urt9Vx9VPOr+dtPvAc4XbPTNq2zyqrKpkVtGr+jyf2OpuIdL4dhm8yKtNKDupa3cXWT
NHrVteNKRjZsxZvdLb2kYCSMBr9MakrnwibBLSNu/Y4xKfQdKDvdb+ihRvlU63aXlKnVI7gM
m7zq1+utOk+MTRu9xP0L/SWZNbBh24ly95SYJliw+EcknDdJDSuCDyWsMah2kzjc+TV4d5FA
bg1msIE4q12/261kosxa7dSSB3p0N9frfuxl5AUcAHgcBqAoKAB0YjLrLcktW7IDw0s4IEuM
hCXn8RP2uE9MDdvtkhwWvKVRCG+Ok2h1U6RNljsF4rKqw9Gpgq857/BbP6zQ30I/4YpwFmEV
UISFrsmxnPKKE3xmcQydhTjeYzxLsKKAsVsaIx8hH91aprKwZ7PAzqopD1PPnocDlotd5GkF
auPQbuh194BBoLzgY8AUOz2GHDgyqzxNrwkuG1m6xcNQ6aUa+nVPhwjNo3NVHb6s28/9Opar
km83r/gZMm0gDiu0qdab5cn37Q5yU+OBodUuF2dGrdRZDWc0M6qqAD7gvqkZ/Q792c1fiOqa
RbY6kRk4/bmb1kNZXbDMFBWC2oHUugyu/rSmdSa1smVZp9mRMIcTENsSZWHLrEpLeygtwPyY
Jsq8prOnigDGUUWQecXy1MmyqKNOfk/ms+EatISlRYmLH0c9Ig+xjchDCCPyEKiY3McjIg+u
ReQ/L2LFDlAkq7nYTdcBw0Bf8AOww5SFBex4JRVgvRTJAkQIyavE6vvEIoj2iKUOAPbyG5WH
B56KM4be6/0UNO9oEkAf/KlWSgvdJylaB6DyIwqUR9DDVcHB0lkHN5kKjdO44NgPEMeuX31l
C8F+XpcXZUBBywEIGx3DQQLlUADgjlF8IVRG7wjebwGELcJrhigN8MrDBFgoEajEV5Y8bIfx
CAqxvnWh5lF9SaCSJhlBuKP/KygoRm83hPiq5WeASqy77Xp9XD+f1RQwyHkE5RpApdDqtZLv
VWKkYlZ6KUP8xUWEa0YqicAbnRdYylxDnMSlWVXmAYA1UKXFF4RVf1FtnpYuipwsjYPntHbA
TxZ/B0Kn9QOKsjgOpNPqAUtl+zicTusHRGVxHFQj6h5XxfootEZD7xMDXgsCOXx/Fvop+WFo
p+SHsZuSH8ZmUn7g/JT80LspeRRBncM07RG0INpADMJIVwDPAJvzxBFxtETt6tTI74qYLtxK
g3dVvU+QqfG0L9xC9N1Ic/ql+rd6036Tme8u4D7X+gP9xtCSrAnQYwR61kSaLaEYsmwD4HVH
7wSTtcf0UkYBlnsB3RpAl5XlkynkIfbWmicoLAZ032vZKYALRQmOnNhVGbYL1A2Wjw4c559H
sm1AilXAUjPyfCnTjoQrpMgAPLfAGlGTmSPN29C8Cbrn4bgLEI1WEFwBEx9X7Xr1pyfGVvNw
iiQYXLlCt8EYRZAoYM0vRJ2dbjGWRn+jUUV9Ra4vPsR6pGCHsYdZ4tjV1AtxPmAxFvTcsbCc
Qg/JXLXQk0AhTbArUY8k4+lt1/UPY/t53R/n4X/sTY5LKpD0ypg9l2782nUjXQmuiaVphjYN
lCKL2cMQ3zxh7bUHnco5+XGTGAoBTTpRpXxXe27e+MXgKIjGXSKkhIJ3z43kjruZ2xd4fr5f
vE3wwphQBwEmsWR2I5EDfH/oe74c8NEvMQNwPsbtcbT3RKD00R5bzJ1Bj5B/jBDvnkfIN3zh
01zTKaT7LnNFPMonhK+MH/X8oK95GLZdv3xM6P4YapOAETTAB4h+UIow741v77Jnnd1zT7wZ
4g+bis1dzXiBj+Bk1LUjXlMGXiOYmr7DNMLtQiMRRB2BaA76X+lGIulxmpMhvkDu+cGEqtT9
X+XkB3riOY5LG1tVf4fjOJgWITgoirKbKT1PbVAW5zVTmp7UoCzKaKYUPZ2hLaNcZkrTExmU
RVnMpKJQGLI1xl8iYeWIu337VGf4fhLZafk+ftPyfZim5ftgROTB52n53rVpeZS8lLU7Ji/5
nrwI1TfumLxYYiVYhStCz4qQthTqkjN1cTIJqEvFxIVpy2vE3AquEwo/92sYj1EWrhsu1A3p
Zwasnw1eSDhRgO09v6R44ZwGvmIRxe5WeBXBPCVyUZPHliqE859q4wdGVhPtGzDT+I+OF5KN
jyd69Q0WlZzasxnQqv9LnvOsl5O27ITn5NK7pVwemecUWoXOj8XS9nFPJ4rMPfg9wnL2XMN6
LsqNZM0rVtBIYqvrZG3rh4HRKB5+pF/oVJGl4OuS9dlCKyylIY5SyyLkzClVKVJnkLRLjQ8n
zhTCVPoBuC2StickdNURKyEKwdIRCs3Qdz3xAAcJshREfL+lX0VswfmqM80x8jrcwExCs33o
h3ZMkIdvmXUivWgwVkgvKkrLoVh97o+q53OfVmwXG06UsdAD8nTsTZb8rWScJ+2N5+8WD2eu
V+tHGh76dOLARaoqdhUV9Ro5J5w4zo+ptZD26SNni0AhBEqYFYC/KfU5OeIGHXJP5/idGMRR
OJ9RdOHhTPYKInv8xmy9HUYOX33KOPIQGxc4Nx5j71hDjllhehUzvVKYXsVMDwFIPfBcGRXN
jueKypIHH48XSoXb/5ccpcSqMs1RUBTlKFN6nqOgLM5RpjQ9R0FZlKNMKXqOQltGOcqUpuco
KItylElF4Shka4yjRMLKES+/y1Fi8n38puX7ME3L98GIyIPP0/K9a9PyOEfJymOOUu45ijQD
pjrmKAXRD+xPa+oNairj2AIySymZpdQy7QvegZp5Cpaa5Yzbz2uClK16JTiFc9c0hX+x4MJa
vH6Mx3ic6AJ2eAhExEZUoFrVDwPhba25d7RaPscVVl6gGh2XZhzjCQoBG3YvqL7RiMi77pG+
h12MBeSh/lZsEFXPiqpqrgfiBDlVzRy7T0YjnMACJRNOSIMXU52t9JVMpoqcT3aQHo+7gNGE
zLRaobGA7x8yuKGu9MCoMPTAXy13skMrej1/Q33eKQqmN8npkzoZGJpphG32tEbDyWhgDaCw
DeTtIsFSCT0oYO/VkoXMTSo4C342o77R7XjczT4rRdjFYg+LmjnY1RGFUn8kFinNarwL5Itr
EtWtJKPDx4orOKMGjzdN/Lgd1Ce139Tvl4dkI9d0nGhM8z6eDqPJCT5OrxfcgEsVR/AkfvtK
76nLO6w1jb74oNByuFrtEoopv7cJEgisk1Dd2g2NYYOQgf8XCV4s0YYAs+c2BPLZgS72mCAu
bvsdsy688cSMNJKkiq4NVtSW2D2PdfR+hzPRFHg84SS41Q9D/5UWeMRfWRIBISdAMAAFuAD/
0i6RU25C0o1P+vKLNDNdvyEa1xHDLPULpA94bjHDLKIz5jkk0H+coFi0ZdFILNUIULDoiG2Y
ug6F/KO+3yFkEr+eYeGlS2uesWPoawBX7b4ja0JHJnfkN0RPPI4zJDgDNSEW+xNc/OaJofSQ
M5dEKnGrkSedqBK5w4HNkvqqxi8GzY5o3CUZExuchjzfUi/6H/arZMdtI4j+Co8SYAtiN9ej
geQ2dgAjcA45aTKERogwmtHiJD+S702t3aRYxfiWIMhhRiRfVy/V3a/eI6uyf4eCUA2QrbLn
J5XEIPkPPWvwcJZjycjr6Wwdv/dysVJmWZv2KuFQmZLMuhNZMFcqDGORNddXUOI8fQWQr6+M
uKSvAFvQV0Zk0leA+frKCEz6Cof09ZURmfQVYL6+sgJVX+FcXX1lp5UzXmV9UobGSK3TIGfQ
aZAz5TTICfEapIU7DfICnQauzIptt6mbZZnV/S+zlmSWurpt0hGxzAUXJn+D9fRUdPF3T/9z
4SXTS5+kwbT8JniDGqFcFVOihsNZxpgILgm8rQi8L8MZlsiVbUulITNyiZqDQBBJcE5+GQ5f
SSeBqli90NOe/r/DkgQlVNiyVwFgs2zOQ5BaQbKrVGrFxwuJtp7FXY81oIIpXUfyrl9xy82U
PvNQf+dRYweUVXk0KqjLpE60kqnAPp868UqpArus6oQrserwLrc68UqvArsM64ULyersPZ71
U88bA7NWoxsrfL5LvY3n1Np4zp2N59w4eFq8jefV2bjPsVVEK1stcWx/z7HPTKU3/mHufDqB
NWjpajDPfmR23Mvrn8WPJJ2CRjMtC4VOXnbF98CJZ49XHUL7JIx0JTvQJNockdjHy35CV7Zw
D3UiKsnAD6/DeXeFGQHvom9Dn9AwazVMQPVqiiFDYYLwP385HrV98Xgedr8SZAhz1m6JK5uo
NDWwziwevgMTAvRYsSqlvLGs2yAzosstUNuhp5zQMYTUbadjlOVYIH54wZ6i5xTm3D38Tux7
HZiLnzCjLRTQwpOjIW1YLRt2ue6AWlFxl7CY24UOCKrnhzVO/os3ly7NJYhQJk0Mqvtxav7K
1LKUlgesn1Aljzf6fWJqh1lfT9N62WikVIn9gfPzdRADuJPf8XixTXdH0wQ7jQYtovzocWeg
pJVskNAYnJ0juG1He3ODdLRUcdrV4biDerg7egenpolDbp9vV5b8bFgakiz4+9uacvwyqZL9
JgQ0T9pL2u5Ojt+HNVbjsKHtqtRbBSyOPXrAi7yLP8IyTc3YH+ET+qNWw5yt3aabF+p8qWvk
GNJCIV3qmlxow/cOuZXUELINfnuH2a1JE3BTBgfvbG7TemO6bkAUraoCfERVgMfyxD9ncbgj
rRRX3NJZXNmm0yiD7PA0tqsnoOgjnhM8YOT1Wh5aH467x+E4PZ91PTogj5TzmnOePGp+3182
6D/rO7cH8y+R7hfdXoTvnkwByNcoRlwSKIAtqBMjMkkTwHxdYgQmUYJD+orEiExyBDBfi1iB
KkRwrq4KsdPKGQ8jn7QF1q7uU+s0yBl0GuRMOQ1yQrwGaeFOg7xAp4GrREIEJtkuur2w/U8r
ES3Ud7yRyKmc+KYeBAjs551tCmSb+rFraomOA3nHSH4R6jyRC3xHZtQyZlumkCzsViwsKp0V
0lVHHiywBOqSB+uYvBARAu0opYi8ns7XSdEMVeq+EV2wxvKyJdpu6A88HyTphP3Acnf8m2gT
Whe743HS6zaRbYgjnydsyrV8QOERVsdC3g9rrMxcZ5/kE7/t6T+mKt57PjjYTd9/i+cLVY/E
5ZCpoC6fOtFKqQL7rOrEK7EK7HKrE670qsO7DOvEK8kK7PKsFy5Uq7P32NZPPW9Mt1HLVDXY
8C7zJpwTa8I5cSac82LDad0mnNdlwi7Fln3Eh0SxMWTBKgoZZHqi2E+n4ny6gW4NwKwRaGIQ
7kRx9UzfgT8avPn6u3uhz8Xu6SvjFMcgad5udf6DjZJHqlNBFoTzXtYivlBhkRocacFW4ALH
b9iOkBI7XECf8afrGmh20hoMWUmEcpBoW4vHLiepU1WPor4CMsPldit+G4A/gEqvQBM1LxYT
UTwgKQdwgYiCkCO4+EwFhkPebtSLdMrxmzUx6qQuwHkkJyOFp6tGGvABDAlwUiQxWNFs+P2I
itsUpe+z2f159XlAsVit3lgp3mDf6pV8u8AsoZp56rlOBaILWiDAnyJ1v0fHsS+eyS1BzXBn
kfxWrUWAxgaRfy1ecUoNKu4GkoU7PnqdyuJ5Lb5K3S1I0UP4BQ1DR3SOSzTKsLrHZpReKbmQ
Tyq67bRiwplqyxJXg3qijxXnFCpAVZdd6nhUC7YjdTSvBYz6tcCOTrWA4YVaYMenWsCwXwvs
8FQLZHi/FtjxqRYw7NcCJ1xrgczerQVu6nVjtpWgTT/P+wwcJ3UGjlM2A8f5mIOj1c7A8Vpm
oM/+AQ58s8z+4V/B/olQQpfZPzD7dyKr+xH/d9Jgw2MUS3J6rjf5bsPNLeFyB7IISVHjeiNM
95kkJ65zVaD8BehGn/DLleRp8Tio4u6If7GnpyVlXcXscESlnsizIGvXOJmA5QnmRmsvgXbO
WlBaKCiIYkGRcoKqGT+9TfV1cg+qrusN62s0I5DNNXZWDLvz8TCcN4UyXcvJSN5E9C7chDLG
b9G70CwfzhnHCepynBOtHCewz3FOvHKcwC7HOeHKcTq8y3FOvHKcwC7HeeHCcTp7j+P81PPG
wLAqG2OFz3ept/GcWhvPubPxnBsHT4u38bw6G3eJrwNFE5Z5L/5jvDdSmts68V6dea9m3qtZ
9WLvifdqaUC8ByzwE8osnCR+HBgjwuhgOigQkTA4cOC3Y/F5eOMvM9IczYy1EByq2DaeIIIM
tnVdYR6EPue6pzdNGPIBIC4XGFHKA/2S5zXi9P73C17XCNN73y95XCNO73u/4G2tMLnn/YKn
tVNJSW6zwAlEBGO0rRBwQl0Qt4hBf5fsYRW2u9Z9ZHRhK+3OFbY7181m1N9vu2+F7b71RMjE
/UNhd66w3bkeG0b9k+P0LbDTt5wtSYp7vOy+Fbb7Xkb/GgArMCy5CmVuZHN0cmVhbQ1lbmRv
YmoNNjEgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDE0MCAwIFIgDS9SZXNvdXJj
ZXMgNjIgMCBSIA0vQ29udGVudHMgNjMgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNTk1IDg0MiBd
IA0vQ3JvcEJveCBbIDAgMCA1OTUgODQyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag02MiAw
IG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9UVDIgMTQ5IDAg
UiAvVFQ4IDEyNCAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSAxNTggMCBSID4+IA0vQ29s
b3JTcGFjZSA8PCAvQ3M1IDE1MyAwIFIgPj4gDT4+IA1lbmRvYmoNNjMgMCBvYmoNPDwgL0xl
bmd0aCA0NDQ1IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJzFdNcxs3Er3r
V+A4s2WOZzCYr6MSKyltOXZK5O4eXDlQ5IjiFk3KHMrx/pH9vdtfAIckWs5BVd5KxRTw0I1G
D/q9xk+zq7ezmTWFmT1cdVlXmxz+oz+6PMtdXpumq7Omzksz+3z19uehMouBFuVmWFy9/XVa
mNVwNYHFua3MbHGFf1Xw159Xn5Lf0om1WZX8nk7qrEjeT80E/2oT8/6dzJnZzXRmfr6e3kyN
Sf+Y/f0qN5MGEJuDk3fkDqIQx9ax4+k1uC66zCXTFDf4x4df0yYrE3P74d3ttZl+/GX2r+u7
G/Px95u769ntxw9T88lMb6cf/+A94NAtH9pmbd5Y09jMtUXndyxav2NhecfPqc2zOhnSCjZd
wWZwiDWPzL5f9OuvNNenkIoiWZqHtIO4dunEZTbZm7n55ebnFA/8BgKHKbPmFebwyIbh8EVW
VHUdzm7D2VuOBBzBzmYL3ixuUIH1AfZrss4PnwnjFUueMmse4n7425v9yeKD4CteRcHM/sYh
lBjCp+Qwv0eLJtmkBdgPPVqUvEEjjssEQvucwqcpIFclhLSiWXZ4M7sqzNpctS5zeWGaBq4R
5N1M6N99f/XwHahtGbLNGVYUNivruB1irWOscA1e7hFq6xyuQNzS1vCpZMuqzfITsIRDalsi
FrbMm6yyY9RB+JolYt6ytueGUJSqIWDesDo/ZOVa9ZAvYf5r1B1Gwmjpsqo+y7qCh9wqeEih
godEabjPh4KHoyn4TzON9CwUdsukhyXgHJYAsVwhFARUBJVcOQvl8gFueoPFVwBFQGE9pwXs
lRyAHrBS/mtmABVQBo8MrAkYUihLM19+PZ8UR/v/pMSeXDtCVEgPzh3pIXCuFc7FoqyYCCqo
6oe0hQDXi/lhLXO8gIu0hP0c7LriOahdrmqwTIml/kwtFvEjzQkEZBbnKtv4YDBzGMz7FI5d
JPMU7kFy32/MXdoAR+LoC0RgC3A3EEGsIM6GKJXoQigV53g5MiqlCU5Rwoq9jwJIanJKlKU9
EuV8myLHLVFsmHQbId2KSFfIlKd3vOqZsDNDHp7wYhFSz/shk3teBScNcWqDYgEbEncic+KJ
zH1YYsRqS4mBk3TJN5ynhQYxcveE/5zsbsP2ecf7o6C0nJ8O8sOC40SmwNkW0ll4/AD5e48Z
rZJ3sJdDjYbzPfX9HpPWkohBbC3d4JNjd0Ebi/CVoQ5BikvY/44FhDatcFPRJbxmB7PY8QTG
WifrFQ2e6d89NAsQRw/b7sx8AQGKi5PrNrr7o5rkOJ72u28QSkJ1A61Fv8LRvh/AP0o3/puB
drG/wmVdXtYGeL2xZVB+6jXKLC+bmr3+s9+TVpfgF0oGEgmF31SVI52clOAjK44C5ykTaAaZ
RdEwRnUZi1sHJWP4BTGL2wc9Y1iXtLh5UDXZXhe2uH3QNoZ1eVPMvcJJ9KrIqan3HwamGO2K
rLOXqY/h49TG8HHuYvg4N1F8dPgYPj5dDFe1rC7hNo+1zB7rRpjL1kctg2K2UCe73ZN5BwUN
rA8ddgmEBElN+oX8LoOoVSxqoDGEDNIajwfAJ7TiQsjG2hHoO5c+F4WRtAv276jxFnJrSRmR
cUhCBFrR4gwpFLa8xYrtII4DM1E7khRLkgKNK7J6e97tuvKYHlExZpAuedptmel4iIkBegWV
Z8VukKo2MJoTAHKXks6CghYy9/QEKp+IlxX/+BXs1E+eUH0Q+VxEfqCnBB6jTvAMqNclnOQN
RjBHod33m34uywz/PtJCaE7wZ7M09x649HPa/188v6jld9xkuAR6BEddRU3dBLwl9v2c2gtH
itvieeh1UEMs79NOHm2gOPQCWogfdsEPkZqeJTVKIvZNw2lA4XVm5QKTB4sSgjfWPPBJZRLv
Hz06+xX9wucc3nBA2AJs+Fljea8i2UATxJg4eKbBZsmjiBjRZQnfSK7vPVYH+qzxHj5vh+dB
BktCTkUI5m3TvLYI1VDRlSpCgqoipFh7ERJYFyHF3ouQwKoIKeZehPz2qggp9l6EBFZFSDMX
EfLRayKkp95/mNyTeJtjCBepj+Hj1Mbwce5i+Dg3UXx0+Bg+Pl0MV0Woqux3Raj5oSLERexC
FQvVzaHMUCtoG5d8XWMn2yTDTib2SGINVqXFqgTaK2F2QCoBTQI5amF4y4se6BAgGOTikVjX
+2ODc3tzBp+owsVrK/JoIoVrUPz4YYUS1pJDHPEq6rfNxVPtZQm4678waxtheqb+FbH2G27l
j6QvHOs8n8NDMNjv+wPoeUFhngjx5RWBBn/RL5/5Q+5R6lnd8APLBdgJuqFvv5S8gdTxnREj
vhl8qZYao4czd0H1ClIJ6gXGgy1DazxRmWxXZkfjbZoDTx94Fj63X2628sc3wcwjG7BTuDTd
mTzA+63B19brykMFTKzLg6CqPCjWXh4E1uVBsffyILAqD4q5lwe/vSoPir2XB4FVedDMRR58
9Jo86Kn3HybQa91d5v0CHCf1Ahyn7AIc5+MSHJ32Ahyf5QJUlcC1wOz5y0rQ/vDnyGWLOZf+
7yt1g+sUtxp8i0n81QkXchvsEu42M+RC2AzDwyC4tVwP8C4xQ8+d6YG8vTH92nel++9RIZ/I
n4RfKK1/oVg5au8FB9fuhAuJ6jGnc0LxmYKwuaOmmU2+0KNEvKxkk91ZUO4YlIgCOW7JccXv
H2Sd3+b07IE/KTjHDp08fDDWNkztZAmbwjMPPWWnZAgCWXfda5Oh60YtzQUZCqqSoWLtyVBg
nQwVe0+GAqtkqJh7MvTbq2So2HsyFFglQ81cyNBHr5Ghnnr+MEXmmdLVuPAs81H4mNgofExc
FD7mJQ6Hc0fh47misE6NcDHhjxepsfvh1FgWISo4o3DjV6g3bKtK8IK9ZYN0Y7Hhghou0ONn
/O0EXNHyLMVeDIinwc6Qelec7lM0WCIX4HDjPZyQzzEzvvfFI9TCgAkPMCEF8x8HhOz3tF8f
x3smQ0ecVQgZNkyGpdh/wZYyEf/s66+2jG+lv/vsiXHUOz6d9YyyZuDeeRXpAoH4qqZ9deJz
FZa1RnyM6sQXtw7Ex/ALxBe3D8THsE58cfNAfLK9Tnxx+0B8DOvEp5h74pPoVeJTU+8/DFx0
4Y8KfVykPoaPUxvDx7mL4ePcRPHR4WP4+HQxXOW/su1OWsMqFLmwX5mfsF9JdVtK3VZctx3V
bSl1W2DdtlS3hF+nBT5873d7nuCVniNzmHlEozWBbGlOBi/1jFXoGSvhRWzvKiAd6h0r6h0r
6h2t9I6V9I7g+YNMHKCGW2Tpxfywljn2Q61kxa0ktp2P7I5ayRfJccyGRI/CYkyENGP+MoHy
ckhk5RNJvuI86sNiubA+QaV80Lv+Szqp4SjPkGPoV4eD2fHEliaA+wtkTAM5afDo0B/TQtgO
czTHjMB2bNPzaGOC29P9q87v3wo/P+zpq1tqjlGeiIQ7PPGEM5yTIE1IHZ+fZNUgsLeWBXP+
8T7WvIgIHTTAG8vi7VLGsmyLjE+PiBPOd1lt6+q1Ob/suheaXUFVzlesPecLrHO+Yu85X2CV
8xVzz/l+e5XzFXvP+QKrnK+ZC+f76DXO11PPH6YNLSO4qM8TH0OPaY2hx6zF0GNOomg4cgw9
niiG6ixfQitqkaQ0li/+r1k+9HjWjVi+9izviOVrYvlSWN4Jyzee5Z2wfDlieZewn4wbQGH5
gli+TjzFn/ScSjsurfYztc/ccB+oMzf3PXyc7zbaax6TJKDxkyzgEVuNo5HshBgWITCM5kCM
XpByVMhv8HXQwz1PCwpU6jAtROwlEbtfgbR+JPWCtKIjrRh6dnkAmq5PHwgsNRhB0s/3m3W/
z0w6+/eYVwv3+rwKBKCRKkA6o0bsAp3C/y9wacQyEClgOotGDAOF4pY6f0YsA3nC/zpzxgw9
bWKsKmfG08oZz48tdNVEMhvHj/n7H/tV0+O2DUT/io40kBgWKYnSKbcCeylQoEguuXht19nC
0WbXdov8jf7izhdJyZ4RgnYPPfSya+lphsOZ4XtDHS9p0vGSDAPPe9bxsjUdN+nTx7BuuyX6
9P9p+uwzffoJffaJPj3RZ0/02Qp9eqHPIdGnF/psJ/TpHfsh+oQz+gnHLJ6RwdvpMGOHwlJe
JkGkEjzRFAQMZfx0pL84dRIRyfIDLY9DHC0/3nx0vmwvV/p9hsRFZxA33nMkhsgxMOM3Dikw
uo8VeQ7iGQpWfUUqYrcDxQagvLvSE3DiI0aINYPloBSQJvfMr04n+fHnyofyyZ5fKoROd4lQ
LhOBw3wEnSCF2vLQH2nob7i/sLt6uTk07gXC84FCjhQydA/E/LCnTqppr+ThI2ypc+9IM2eV
qnOlaqkURN9A5b+AR+jBHf+HQ4MN0eOm4GC713OFutPQLM+fSPpgeqeryZHtHvbzr7aX29tU
vrSInomA4lIbOhZQpp7s+V4CW8QTt+ETh4cpyGHCZGBwZzgrHQRAzVrfDPzdevAxvrUw+R58
NJY2CWrKk2GdFEpgW6QM+6RTAptSZZgntUrLm4Jl2CfNEtiULctclCtFb4mXnXouDCybpuee
tOAm9TpeUqvjJXc6XnJj4HnzOl52p+OmftUDGiD5WfoV/tevJf3KDFSWYcsjx3Fhk0PFb9UF
GXonSz1dmBo7UpGeCBJGcXJtiVfMaRBVOMrl4D3O9heOIhIhojxt+T2JU0hfyUzfZhlraekg
voibCSRhBI3YOPZGOQo3xAmN0sb+zYlz45eIk1GbOHXrTJwMLxCnbp+Jk2GbOHXzTJyyvE2c
un0mToZt4jTME3FK9CZxmqnnwtSFeJoWfdykXsdLanW85E7HS24MPG9ex8vudNwmzgb60xfi
bMpgJsTZFOL8eYVDB5x96G0asRoa0phEGybRnk6il+ms46+BTjfuFYeo4HYHBoQ4aybODZBO
Q1xJmEWWFFmbZ9xeaGLLtLYnf8H98YTjV0dESS9gaSSi7xgzkNmY3l/4O/n8N5ou5WHHLsXz
/MNkPiLBBCKY97iPY5UW5ufqfGDzUexnI+BdqjkDIyYDqsaZ+PZMz/zAea0u9B2XYfsDhXi5
FhdsizOjJ06ONDPiirPQSD83HBZFAJtEnfSOxvTOre9oshuGRJN4/dnlK1GhSXCDRfB1pkbv
foKASE9QTV+rZ5x4QdMOK3yCMGtqig7WPxLAv6sPVILapf8cTrvu49DeN0yOp5dx/7MjzfZY
KST9L1zSwV1PrGx7eR5p5P7rwm+loL0bE/55JY4kH0hCcGRKAN16E6VhcWls7V9/n0hB3cLY
bikBg6YQ6LZJBxi1ZUC3TirAqCkCunHSAFnalADdOikAo6YAGMbC/xK3Rf9mulMtap/Ys8Ot
3+Vbw6cZ1fBp0jR8mhYVn+xcw6eb03CT/YdhNjWHmCkJRzGi/3ZG/8Q6OCQR6+AEVsNpYNZp
iHXw5Aqz5K+vK5yMiP874f+Q+B+HUUSfyINAswcYhWmwWpQEn0+4n0hCLefYiyS0SRI8S0LL
kjBkSRCmb518jpKQH3bsUjzPP0zmIgkiAcCtMFX2SA8PvJ5Ypa+uQC+QrPQ2jYkv0HI9CUNs
8CAF0F1fIblgQT9V431J2QBqGoEfk6AX2nkU1vlFsfSBu2Fqid1QBAq1CpN6qOSWMEB5DjTK
76vnkR5P/yb4OECzmsF/Xwi+D8CU98HX+UZVS0NUT+MKqZuk9Z+H6jdQzttslVC/2aF6qLhX
Qg1dyXOXJXegHsLhAfMcWfXlRDWo+yJ4IcRQwSGD2N/6llJvhoVbiqC2OOnWWZ0YXpAn3T7r
E8O2QOnmWaFkeVuidPusUQzbImWYJ5WS6E2ZMlPPhenLlB8a/D2Fo2moI1jNuFhJfbmEK15T
leNyhXW/CVf8purHxcrrbhOuuE1dEZc7QvebcMVv6pa42CmGW8E1t9JFcbGDdLcJV9wuQH8P
AGQDO0cKZW5kc3RyZWFtDWVuZG9iag02NCAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJl
bnQgMTQwIDAgUiANL1Jlc291cmNlcyA2NSAwIFIgDS9Db250ZW50cyA2NiAwIFIgDS9NZWRp
YUJveCBbIDAgMCA1OTUgODQyIF0gDS9Dcm9wQm94IFsgMCAwIDU5NSA4NDIgXSANL1JvdGF0
ZSAwIA0+PiANZW5kb2JqDTY1IDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSAN
L0ZvbnQgPDwgL1RUMiAxNDkgMCBSIC9UVDggMTI0IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAv
R1MxIDE1OCAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczUgMTUzIDAgUiA+PiANPj4gDWVu
ZG9iag02NiAwIG9iag08PCAvTGVuZ3RoIDI2NzcgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4g
DXN0cmVhbQ0KSInsV01vGzkSvetX8Ni9iDpNNsnuPnom2UEW3iSwtJtDMAfFatsaKFIiyQ7y
OybY37v1QbIlm6UMBnMZIDBgsflYxWKRfK/403zyfD43Sqv5zaSveq9q+KNGX1e1rb1qe1+1
vm7U/OPk+c97p673NKhW++vJ819mWt3uJ1MYXBun5tcTbDlofZm8L/5dTo2pXPG2nPpKF5cz
NcVWV6jLF6FPzV/O5urni9nLmVLlr/N/TWo1bQExNTh5Qe4giuDYWHY8uwDXuq9sMStxgv+8
/qVsq6ZQr16/eHWhZm/+OX93cfVSvXn78upi/urN65l6r2avZm9+5Tlg0R0v2lRd3RrVmsp2
uk8z9mlGzTNelj34X8CsxYdy6iDyAdtrdTV85m/1sYSI2mJfWojotvRVX6j9sKHGodSVL9Sw
2K1Xw67iKF7OJ1qt1KSzla21alvIKoShpvR/N0xuvgN1HUOmfYRpbarG5+0Q6yxj2ra410eo
8TVkJG9pvK5MmNJ1VX0CNrB4aUrE0pR1WzlzjFoIX7JELFp689gQzqhoCFg0dI8X6WwnLvIc
FnfD9xgJo1pj+zTrAp5yK+AphQKeEiXhMR8CnpYm4D/NJQ4AQ2eYA/BSNC1eD7r0dcv3o/EK
7oOzpjLF67IptnD18UJelpAUDRdHw7X/MKzhcthCXZUd3B/s2tO9DaPvS7xAuxI8++J6YEz9
T83BtSnuCF2RhwCdfCw2NIDvVrjXU11p5z3e62lkJr7YXeAouNJwe4plSZkoHlbl1GJc29AB
0cDhLb7iOuAGb2L/gceF4TclLjx8XLPL4Pl0YDTfIF00EPYeOoAgbqtyCkkulHoHHQ207soa
/g/sZEMfvLT5P5iZ4koCQy0w1zXNW0PGIdeQZg8zDPT9Wa32pcMl7IbrYfVAO4DA8pla3XDm
DnfYuxsSEUP2rPWRFZF9rxMj05wwdlN2MCmsq0Hn6wVMvC+htXggYLGCrvWgDluF3ffU+enT
19Lgip4dT3W8UePyGsNzIZU6yOAShcNQsPi52mMmO5h7Xzbg+pZ62a22VV/DybSV1zbJiUmu
gcHI9X+HHaWgLygsOEuwGjCEaeZpNzr4GtTwwI0N/Rw4qR0ldbtbDssKr4EHqsKDOPVwBsld
oPtIIK4T6Rwgmc4zdonOATtD5xnLROeAyXSeMUx0jlPKdJ6xTHQOmEznOcNI5xirSOf5tHLG
25HyXJvJbB4f85fHxzTl8TEZAp7WnMfHpeVxkbI9NJw/T9ntD8r+Syj7jzK21omye14JcFgL
qV5hzQhp2NDXFqeFkhEoqcMorheH1ZYhFUcGDm+5Dq2RFp+dqkOXSC7w5w2qgyMC7oodUn3F
EtAXO/D3mYHhACyN+w18HceoT8Owg8UbrGF5GA86lLhs9WFIU0vcfU8suf/E3H3K5AOeJJ14
XfFYHnJYrdeR6SGOYADRMLzlDkwV3I9iNewF6dIpHTqE9KU0DveftgAIfKF+LzVuK6moKVDH
IC1I75a3xMDacegO43V02BHLKFgdziluUBsV8Ft1KkrwLDBtmwJsTqXI4vHtScmOpcgWd+ST
hIgaG/o54FXCxlId4ghaCN7jKa4Hl0PzQ97a3p2EizulR34IBcVViecY77wpPuM9h7OG+06z
gfAfSR6tCxm6sWr066u6dQ0lHj3C1pbz345lsEayEpWQUVkM89ZJDxk+I4l5+6SKDMvCmDdP
2himl+Uxb58UkmFZJAXzqJMhelEqxdTjxvgeHgg+oF395IEj4TG1Eh5zJ+ExNyIeFi/hcXUS
Lqtl3Z+qZTfehlAjQldSS1JIQwrZB4V0pJBEx9i5p7tDGmlIIzvWSBc00lJ9jN2LFVmzj+CR
P4Ygo9h1R2N5aLAXNDPGfJ1qXYweqmQgCE9EB0SLzPdAn6sSpQ2lE/t2X7GU7lGJPNOrC/SK
QsdKxH3B2UckKSy9LZXe2FfxotWrw4kg1W2KqUkxYU1PhAJRwJLId1Nw35pigTlodkwY8j/i
O35rDA80bhWs7ukLI4HC4nfkvg7KmroI8KlE2SRRbcjQ5QK1BN5NkPGaVQk/4REVWlReIHK/
Y92/5v4Icwn0jb/UF0wMHhEGYaXc2hwqrA/MoxcKvFzg0CYx8BhdU0HV5k9loWFZaJFLp61z
ljyxQugn7wwPQ2WCDahIsIJ1JNgAywQr2EeCDbBIsIJ5JNg4vUiwgn0k2ACLBCuZB4KN0UsE
K6eeN6YbCcp6zMCj1OfxMbV5fMxdHh9zI+Bp8Xl8XF0eFwnW+QY54CzB9j8I9k8R7JNi1/Sp
9tcxOrB06dmAEUAaoViEdwV+ANcaTUyrkcSQancDj9ve009wALzaAKvi/Ntc4Yuzp1dOHV45
l/zyWJSxDr2i18NA31hEt5iIBma5px3e8QK5wG6Lb4pq9eiAO8el6OBoWT2hVNd2fzWlutbg
oRcoNaAipQrWkVIDLFOqYB8pNcAipQrmkVLj9CKlCvaRUgMsUqpkHig1Ri9Rqpz6sDGRjxw6
eJz3p+BRUp+CRyl7Ch7lIwOOq30KHq3lKSizp/bfK09t/TdiT5/Y056yp4/saYk9PbFnE9jT
BvZsmT19EXqZPZsj9rRFcEbsaYk9DbGnZ/a0xUltalI1GNP5Dt10sK4OS8EN/QArXjI/IhE1
xGQfkTf5kwdx+5btqL1TK4aQbHpmOkg3WSKXdaex1C4lx0X6RAJ+gftjirfltKc0fcAIHefA
UfHrioM63FFjwO3DxmK1jiNX69WB8udDoe2KG15XXkXqxOMm8HhwhdoBY7tivX/GE2rcwA01
tjwC96TFI5H2pC94gEplv4ayH4v0Sp0St628ti7JiU17c0LcsBEamNvgoY10bQo8kA0k/Y6e
DIMiEbO8g3BSUDW2u+Ww5Bkh+W3vnhzPNKMJM9K7w/O7o+d3hw3vDk+ppyMWXiyOlrhkkDIF
12c4DKGHzp+P5T8yXwNVbAoAaqnWNRQAzo2iNP/tWH+MP1PSB1TWn7x10h+Gz+hP3j7pD8Oy
/uTNk/6E6WX9ydsn/WFY1h/BPOpPiF7UHzH1vDFuLIldm0l9Hh9Tm8fH3OXxMTcCnhafx8fV
5XFRlCxssz9f0kNSf4jSnxUlnQLSISBcmIV03cFiPNb0+E6AaVue1oZp+zQtQyqODCVzy7yE
2kQPAPxexxr4OILGjzsamBB4F9e+5Xh38aHQU1bsiNyX/GppcV7cetqmNmx8gxvf8iMEOj/z
6IGHH3jA45lO9DplhqOi94FF0oeF439ICj2uLL1YDOSMlNsWi/j8aEidWYE5e/j44KdHE54e
fkzH+wKOXsdyuh7Ci8SS2kcf6UUSPC8f6xo8W7pG/9C1rK5ZT6Ih6FpARV0TrKOuBVjWNcE+
6lqARV0TzKOuxelFXRPso64FWNQ1yTzoWoxe0jU59bwxwA8B9H2lzQna9N2ZN5mM4qYG9Mym
ZmeOsOA87nmAz+151n2EBffxSAT4zJHIeo+w4D2emBj8mROTdR9hwX08UAE+c6Dy3gMseQ/n
LaZGPm9Z7xEWvH8HFsuUpuuR+7hMQf4piHnqY3YsIhn9fwBOXDi1CmVuZHN0cmVhbQ1lbmRv
YmoNNjcgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDE0MCAwIFIgDS9SZXNvdXJj
ZXMgNjggMCBSIA0vQ29udGVudHMgNjkgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNTk1IDg0MiBd
IA0vQ3JvcEJveCBbIDAgMCA1OTUgODQyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag02OCAw
IG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9UVDIgMTQ5IDAg
UiAvVFQ4IDEyNCAwIFIgL1RUMTAgMTI2IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDE1
OCAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczUgMTUzIDAgUiA+PiANPj4gDWVuZG9iag02
OSAwIG9iag08PCAvTGVuZ3RoIDQ0MjYgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVh
bQ0KSImkV01z2zgSvetX4AhuRQwAAvzYm5N4Jt5ynJSlmT04PsgSZWujWB5Rzsz8jN3D/t7t
RgMgRQHOpiaukBQeGkA30O813swnr+dzxSSbrydN3pRMwJ/9aEQutChZ1ZR5VYqCzb9OXr/t
DFt2tpNg3XLy+ueZZPfdZAqdhTJsvpzgl4Gv3yc3/EM2VSo3/FM2LXPJL2dsil81Z5fvXBub
n8/m7O3Z7HzGWHY7/8dEsGkFiBIwyDs7HKzCDaw0DTw7g6Flk2s+y3CCX65+zqq84Ozi6t3F
GZt9/Gn+z7Prc/bx0/n12fzi49WM3bDZxezjLc0BTtfktGAVDFAIaSez8+AUnGXzfw1iI5V1
GV7KCFwcBEZXudYUGOu/ULRMY/ALlykNe99utzuWQRv/0Hbd4r61CzifTyTbsImqZF4pCYOh
y6wqclOyqcwV27eT9eTNfDBzoU2u6tHMkSVL8eJ+FiYvazImE4ETSlOWPt66xkGtT7ImT67b
dWYg0Gy1z2oI+4J+HuxzmoHTfGO/W9iPxrWvB+jXTMNuP2XoG99aoLMjTenH6mkqypzs/hiM
wdisXdInTbB7ZP9lEKZcjXZS1nRoRGwnpx5FV7W2ro73WORwDJSNvqqbcPgaHIrPtjkNBG2V
KsYhExX2uuFXu2xq8CDaxcEB1QaW13e1Y9FA6mQgyqIqZFFFsZ+32VTnJe8O2bTi7O0im9Z5
xTvXTFNJGK7WxXiuoxDkslDmZEJZ09JnB8rI9qmjIXWuG82O/ZQhFaVLxXPYlQa2rIKlPMFW
tSt23XbQqPhzBvvEtwcGuw5D8Y931N7uv0EvF6GihJHG0ZT92mGwZxwCPIBTL+Akx8Mp80ZV
1Yl3NBQe4K+ZMhC2BXm5/5LJAhbufIV8rMFf6F1JkQPNiByyYGqfNhO/i9Z1QBVQUTmEJeyO
0klrhC0JECz12F6V4EqdtEfYlAE2Ep8DvJAyr9OLL3B1/eh1kZfH5g3ssEqbg0AMQlOKIahN
+VLcEB4EzjS5UUPcyBfNvwP7PRMNKJhDVQE0ONqVBB6insBDWFO4j1sCD7FJ4MG7BP5mPmC/
ONmXVQUuOqWIM7uE7FSiKCEv31uO3g05ekU/2BzeAtKFOBhSCQ6J43qgY2Lyhwy61Hz3TO/j
Ae5aSjQ46Y1RJ2laFiHjb/gSCU7ZhSjg0sf1Bkm15PfPe7uMki+ox53rsSW8pdY8mzaBgiVk
pi7GNNYUNBP4rpuigdVeuJHXmQRX2PeX4CZbuR7sQB28BRPu49VwNSaXjapPSSpwfuE4f3Ng
3UOGSrJDvqqAS/HHdkW/2GHxxTbAKlTQgPnfaJNlv8mShluBfONphcApS8zggoSwQXBAZ/HJ
oFbpgMQr3i5fheHsIJVfnRRudQv0qeSPuLeVDUGBi9qgPq0zYYNR2VDYduE+/qD+6/X6lQ2i
NyFd88VfL9DT4+IPONHObgOjKTClDYx2gSl9YDQFxhyNOhSYk4py85iVdvtriOoGDgFsum3Z
HP7MJOptzj6D5lLjCjdbQwWj8Wz7aN3wHbVTp60zZEetLZWE1HS0b65+pvU8LZZfYC1QUB0+
Zzn1q6mcqEnpwRWT10oVJIJWBXsZK2s4JyolVA5NClXC2guVg9NClbD3QuXgpFAlzL1QOTgp
VClzJ1QOjgtVwtYLlV95SqjSYfdo0KlGnShRCh+GNYYP4xbFB4GJ4UPnY/jQuxgOShTXHwOO
V6rXH1GEvHNUojARMPu9CP20o5a91RxMkgXSRsn395A/wHgHKDGd0QO1EO6SquLBcJrVKBHY
Bny66VjXHtjB90rIkWXQPhO5pLofc7SvNr2qAMHLojgujqHNCCeuv7b7zTpD/gcuaHBWcBSC
Utjcnxa6bFBBRyWoaYBWUqlLYDJz47Y+cQlN523c2qctocmsjRv7pCU0mbMJY5eyhMYzNm7p
E9atOZWvyVATWPTJXGiIwTjWcbyPZhzvA5bAQ0zieO95HO+di+PpdNUg6/UgXWVI14YOdIHJ
0wzS9br9jZqeM3t57A5sZkVSkkg2Ph1LyuOa8lj2eQw9giLifezm+iQ1XT1gc2ygkZjbkNm3
/7fIX5C8s3/b1zWod8P/Q013JMhjnoA0le7NerHu2cFzw+jjqIwZNrnlhe4vr/PHFiqGNYVn
qCZXqm5+jKFGlaqP/shrcVrGqlCqKRr9MsMaeZZh2XcNh+83rNKUrdlqPCsdOzzQ93ElFCIi
XET27bLdfIPRsPAWVh4OOyhYcTRqeLQgnKhiXFfpoq+HXd3/BF5nhu9W+FxCuWpsZazxcEJh
iioDTfi/tc2r44r41FF3gnE5nd0R/Bo5J8ZnWQU19IV1l2EO7NAJLPlxw+G+ofiyZTuo4IUd
Elvb1JlvBvkR0kry/PjwHp0/Gbzxd8IrsLKXArtj+PUMVwOFO3ZcimKsamOOa1F3RkYFqQEO
lmVS1QhNy1rcOugawS8IW9w+KBvBaWmLmwdtIzgtbglzr24EJ+Qtbhv0za08KXDJsBMKSVM7
VAJnNGOJS3XoA5vo0Icu1SEEJ9Ghj0CiQ+9jokNS6IAZwb2B0J1QsPZk6oWOVEzyB3eLc6z7
RK/D5uiSZ6Wu4FvmYPd7v/iKJKupZC34od13bBFug79nKkCrIZnHq1RpQt6acImt8NK7IEVl
XzOFZIasIvm9w/bt379Hj/L24ukbEaHG5biaWiJBZoIvHgnrYMSGP+32SJTsLLMqv1rtWwLo
CbrJ1G2EAe2MJlQYcJbs3G93dibJH9cb5B7N75+BAxuKYgWkbBsdFjpD1YHob+43u8L4IW8J
WANEHQn1zoG2pxszwaORoBS3LESl/OtROVJpnZdSWxqFw6tBd3sSxxtDoUyBR7GuGtzC0XVB
6yJx50SCcGiSWRPWnlkdnGbWhL1nVgcnmTVh7pnVwUlmTZk7ZnVwnFkTtp5Z/cpTzJoOu0fB
Y0JNFQ17DB+GNYYP4xbFB4GJ4UPnY/jQuxiepNSiApYc3B0iGWR6NoUKV2KBBCny4Cquv5BM
n/nuCTvYmo5S09lTVbfNzItMKgKTKseknzN3bVG2hm34r1huI7nbGQy8DkTuBpmksOVsSzhU
5vSBxRq+R8VtKLd8DR6KW6plgfwdf3/obP14b6FXGQSzdhUg9GSX6GIJ1bUGTru2M4U+u+OC
tWj8nKW7yO2Q/hqUL3y1xJaP7PLdJ3AbaLFzTV23cV0fIZSSKA9uifwtrFRz1/toMlMHTncO
LoFwYU+IrGGax5YaXPuBatQNvUIvcKZGZ547172D42PLaur4ACtQ3GHsAswEtH6y29bwb9qN
w15T99Mepe+RKM9PbiF039jRHePZXjj2dNygQF/QsbRXAPtk9t8NW9NRdGZ72kAsIX7BYFeB
0U9ECGuRZahP7L1lsfwCxlAlHNhysd//iQJvUPex8d4+6ezcHgtMCaRQVT92DZwaMKUaqNAl
HoGx8kDtn1fJmt6hSeVJWHvlcXBaeRL2XnkcnFSehLlXHgcnlSdl7pTHwXHlSdh65fErTylP
OuweVb4argWOcRL2GD4Mawwfxi2KDwITw4fOx/ChdzE8qTyqMcfKU/XKU9HxLkfKg6f6w6dL
LAslECiW7AzEA5o7yCGotVbDXygiNb/b2qZ29Yq9z7BOx0Zqo+eOKnc3wgtyU5iwQGE8s1SW
0bC+2z3b13YFetOQ3igrK3cto35tJmHFhB6A/oFrdnvmZAQb/8d62fS2bQRh+K/wSAGxqt0l
KbJAD0FzaIEADRonl5xoirbVupFhy2j77ztf+yFzhgejF1Hal7O7HPF9doZvOFQnvufy/Eld
Ay8NR21fE0iAkSeEwJ4PGSAUggW7FB4dpxkPpK6+ZAtwxIXwxuI17Jo1hLBqI0SPTghheQUh
enxCCMs2QvTwhBCWbYQY4REhLBsI0WMTQmTnJkLMtEc1WTA0kItl2jW9TKuml3lT9SIxml4+
vKaXT6fpNkJg477BY14Q0meEyAm5f40QeJfR9y3hYahvZv5VPdMp/PfGY5V2pLEzfU50H5W7
vQjf+ccdXyoe5AkYQfGXrMFLzGRsDlnBzLLQRKsjLI58FWMPaOx3XDZwwVnxhQvN0wtdCEd9
LH96xpFROKVyOuOtI2ztCFs9pSRcYqsnbO0itnqpn/E6nnnHLe/YYdkHW15QaOf8GynkobzR
ezk0k6gmhYzoSCGRbQoZ8ZFCIpsUMsIjhUQ2KWSFC4VE1ilkxEYKxZ1bFLLTHtXUgoKLm2aZ
dk0v06rpZd5UvUiMppcPr+nl02m6TSHfboPPhcyy/u8zhLAPC1Bo3HM/UEkPEB3i2NTTiYdl
7Mgtwgt9UusyIE1EJWd3sUNpYt+q08WlLg9dh5t7GIGBhA7CX4v4O0/3ULEg7jzhbk+0w893
uDoSgAcfqO+AFmMaeaAap2l+PF+2lqkjky72I/WMof7+J9RkVx3UKNQODlCR0bhcsDKDrswq
W/7PlsjDH92bICHR5ogamzBC6gpF1OgEEVJthqjBCSGk2gTRgyNASDX4oUYmfPCeTXpYqY5i
8HYJY+llNjW9TJiqFznR9PLJNb18OE034eHgy0UX5HMJIwYdLksYR3bjSsLXMnCEdmLggsQD
J+gCoEA8YOeD1HHgZBkaJfiZLPt4ejpTePV+47BQORyeZpb4c40nTcD9fqt5hab+iDXWvv66
QSRR3yO1U8CKhK5QDdUHxAh4U3qjgfqyhgurgIXXq2YlL/qGMsENw0qzIqppbyM6+ltk2+BG
fHS4yKbFjfDocZFNk1vh4nKRdZsbsdHnceeW0e20RzUV+z6AG5Zp1/QyrZpe5k3Vi8Roevnw
ml4+nabbTu/goOsKpy+bFbeDd9i1AT36ASzpyBaDNBPcjlx0IGM5duKjObYYX2gCnuYTH6gV
WZ3anZ+qDir/NWO7vD3H2/u86XiRgRHjmCe+hqL+ywYP2A/0Cat1slaDO+G1UklAszd59oZn
/w1i97x7OKlvTrhRx+yA38yXUP8jv0e58VD9DsnZp3GjVngLNfZdrgOX1GDVpoYenajB8go1
9PhEDZZtaujhiRos29QwwiM1WDaooccmasjOTWqYaWe1zUxR6gNLz2nV9Zw3Q0+J0fX88Lqe
n07XbWoEOCfL5iLV0jvxDbgzQePzCXuEjnuEPfry109YWcPbPfKp3tGxj5/VUa7UNnTAkup0
y+dvHFp2Ek2TAOF92ongi3oZz70MFtnQylTUUXTU7vh65hsqboJaMC2NHraLw17WeYttG/CE
6VoSbdOqscmzpK5YVo1OjiXVNqwanPxKqm1XPTi6lVTDrGpk8irv2bSqlWoWd5C1eD7CKeZf
51rXczZ1PSfM0FNOdD0/ua7nh9N126m7Hkr/7FQXoj/cXpy6uWrAlZ4v2bXvsWaGE/M8Pt1B
MRzq+XyeD3LXL/PDw0m+g63Q2qGWgb82HuPJ5D2etM8ivNA0dOu0NHF5yhfeGmPd39X8yYE/
XF9DXQIlAOR267vWwYNLdCBr1uP2ZjttD5vrP/Dmnu9Fz/gh3+sSuOKBjwBqEQfjNM2P5/Hm
Ya6OSI4gK0PNMvT96y3vumLP8xFQ1SGqnn60zn6qMjqiFQy2fcehX6FKocYDUkeVDKAPS6kr
rI9u/5VGC/6lFuaj0gKA3SHXfsYiyGOpdSu3373E+JGnO/P4kbcEdTC8HYvcL1u92NURiWl9
7szueXi+qKFcmQhgL/5lwt6A7JXsvuajg5bO5COJNh/V2MRHUlf4qEYnPpJq81ENTnwk1eaj
Hhz5SKrBRzUy8ZH3bPLRSnUUg19WAiL3fqV3MkXcFIur/6G2btT1ueN/zOr6f6zNHnV99vgO
sLr6DmiTR12fPL4jrK6+I+rkohuTyzvEqv0OaTNHXZ85vmOSk7V3TJs86vrk6+p/AwD2RFQY
CmVuZHN0cmVhbQ1lbmRvYmoNNzAgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDE0
MCAwIFIgDS9SZXNvdXJjZXMgNzEgMCBSIA0vQ29udGVudHMgNzIgMCBSIA0vTWVkaWFCb3gg
WyAwIDAgNTk1IDg0MiBdIA0vQ3JvcEJveCBbIDAgMCA1OTUgODQyIF0gDS9Sb3RhdGUgMCAN
Pj4gDWVuZG9iag03MSAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250
IDw8IC9UVDIgMTQ5IDAgUiAvVFQ4IDEyNCAwIFIgL1RUMTAgMTI2IDAgUiA+PiANL0V4dEdT
dGF0ZSA8PCAvR1MxIDE1OCAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczUgMTUzIDAgUiA+
PiANPj4gDWVuZG9iag03MiAwIG9iag08PCAvTGVuZ3RoIDM3NjYgL0ZpbHRlciAvRmxhdGVE
ZWNvZGUgPj4gDXN0cmVhbQ0KSImUl9121DgSx+/zFLq099DGkuWvywywM9nDAofuYS4YLpxu
J/HQxNluB5h5jN194K0PSXYTVVjIwW3rr5JLZdfPVT9tzp5uNkZptbk6a7O2Ujn80UmbZ7nN
K1W3VVZXeaE2n86ePjuWanukSbk6bs+e/rzW6vp4toLJuSnVZnuGZyWcfTl7n/wzXRmTlcmb
dFVlOnm5Vis8axL18rkbU5sX6416dr5+sVYq/bD5x1muVjUoJodFntNy4IVb2FheeH0OS+s2
s8k6xRv8+urntM6KRF28en5xrtav/7757fztC/X6zYu355uL16/W6r1aX6xff+B7wKYb3rTJ
6rY0qjaZbXRLd6Sb4X0SlW7+QH90psuq8u6YxruTG3ZnA86YrE1u0gY216uXqdaZAd9sVidv
wTPYJ2tdmsO8Y1qB6+qy729pVG1HPrlKdQ7bGa7p6p6OB1gcxvqdmkYXos3fQjS2IULoyPvu
gzpPdQG33W77u0lNeFsLLqGLBUQIHSiTwzUPTxMsy/987GGv1tJe6aHmZQjHe9hfiZ7AUwXj
/X7ER1gmx2xpvAhU3obnpp1/l+mqhGh8UEfYegWh2PGAmjrwCQfIJzd4wyPgOt8NB48QBif7
R6lzfpYQu7bUDbyazgFr52fZZZfZNtvRI108/iKrMI42q7SdXzgTHG/Y8S8pzkyG/V7RFhry
CsKsuknafUgH49Jhwv1A/NQ0fErh7S3glPZSwoNv4IUJT5dDrxehH24h9m0yTEO3H/7qpmEU
HhjlyvvkNktXrVvwxeZMq0GdNTazsGhdQ/bC665WdDz0Z1ffkZqGJQM5Vi01Da+9sXE71GrD
mrbfWpoKnG3ilqiVFWslJJJdigWkViO4WqA7btEGntepYQsBNIIhQM7vv8qXii0rMTKo+dCU
bQYYWYillg0f0/yTqGhBVsv6YcQFPcRV0EP4JN1HSdBDPAQ9bE3Qf9pI35kcQO6+M5S7lIP0
SmuHWV0oSLqyyCH5n0HClMmISdgknyA7+eAGbpGjkE+/pAUBy0Cu7YHGrTu6aequO3Rkx1Mm
Evn8cARuwxQEJ/IXmG6AAO9oRc4r9+1Y5D3kKS3hbGnpjpZzHu34xh3faTz8mRpU1RV+MYJf
B3U58owbtxHvxVd33fn11FsKhB8nvzRkrC2smv2Cpaz7bHEogferwpRw53TV1G3YEqDCv4Cw
3dyKNGBVBkLcOjCB5UewELcPZGBZhkPcPPCBZRkRgrmnBMsCKOK2gRXOcxEXYthZhZegcip8
kWDmN2GP63NY4/ocN0EPgYnr8+bj+ry7uC5SoYJ3E04CFUwoBXNXCmo7Q+E3/JhaKsOqhGqr
ClJlP/IZfGzd0ORmqP3AIx/p+CTFiHOpBipUSjXWHVitGTHliVUzqtgpzP+KkjcZ7/G4p1IQ
st9g2adYR9BoIgORB4qJ/jNe9IwFqHB+d2s4c8XTBjp+wjlYbT5l22VlqEMBo10BU6QryNzk
9xTyHle+4+set1wnBygn6HrHP6r/Ch6aBGpIHpgUVigEKEuAgsDhBB4dUoQXjwxTDwHEMzd3
79dcOohPNMDIlUMa9nLCryKzVdue8uv/QVfVNPO35wG6nCqiS7D26HKyjC7B3qPLySK6BHOP
LieL6JLMHbqcHEeXYOvR5T2X0CWH3asBbLaCUD0Me0xfhjWmL+MW1ReBienLzcf05e5iuoyu
AnvKR9FVPo4uoAH9HAKwDr3q4P+WLzuedr3AlcCqZYNgQ19Su74Ecpzazh77OYsNJ/adE5IC
O1YaHPjq1v9eK6ePzthfA7DmpdTanRyPw+n0W5oWaZ1WCzzAWVGwj/1x6i5xLSjkhiM2okhA
jbVPf0tX0xP1bOQZPHAFFALHr+nino4HRBEEDtunxcwTNBVNoHnezDi3sCek3L/u0xbBeUs/
217xCY8Sk6vkEh4ZV2wt142G6kbALq90Q5NHtkG2l/RpyPjjcNIEFuUClMee35Lb6RSUc/f6
g6C0ml5dAZSsyqCMWwdQsvwIKOP2AZQsy6CMmwdQsiyDUjD3oGRZAGXcNoDSeS6CUgy7V2FI
7PwkfRnWmL6MW1RfBCamLzcf05e7i+kiKMsaEsAsQGkDKCsHymoG5cUVtjqQSsOkBsAdFHgK
OWiJgGXyJTUlVhs3izEo4lS3+wO51ibdtuf5W6iyUH0ilXacgNp7U7ni7uXzN+BNgdlKCYlw
A5y0VMsZuIM63rjre7rGCgiv1CX/ktFpmufL5iywrvGsM2hjuIKsQi3l0x86SI2c/NH0Lxux
v0NJTPyYnc961OSUj1n6fEdNTPaYoc901MQ0jxq6HEctnuAxK5/d5KeU2kJIWSrm8qiw2Ad9
E9W4Pscurs8hEvQQibg+7zmuz1uL63JeF+1JATR/1E3t8ho/Z3VS88+c47/0kLFu8CbF77S7
wkyi0UXLcDyZcU8XYd4l/0L2aNf4odxLBRK5Geoj4+ojulVBXY6BFK8glfjcCfc05C4UOVJS
Z2TcHaFGUROAqeAOCmXF65BjFko4vHDSNHRTv3PThAKpWuDiM5RoNWIGTdCbHJfFkSNCwz6k
BfWHP0wL2zxSLDhVZkbcOmCD5UfIEbcP8GBZ5kfcPCCEZZkigrkHCcsCS+K2ASfOc5EoYti9
Gj62kJTWPgx7TF+GNaYv4xbVF4GJ6cvNx/Tl7mK6DJUcyTNDpSjmat21Crr5hiTYFOFXmX6w
9i649kZOYMF96Lf98JkGsMa3yU5BkaGxW9DJSDW9pkym/BaKBfRA1x4d2vly10Mr0E1q33fH
FLNzUtDV1Yikw58IDKpU8HrE1oQ8QrZRYdKf9CW2XeT8XX8YYL0qGXdSLUAxAR+dR41hS4iN
bQu6MWS6bg2flQ3R6wIrFISXIUaN1MQY7AWxSaF6p8Y6Z+cEd/M2qzWUMN+EYwmp/6TwxOF5
UBDGPTwKKGaW+9NlzSTaDDjVAk/xI4NPBPvGAzwQ7CMdZE8aNmfYf4UHVCd3AzRU0MX2u/8u
6ekIz2+KZgvs/ojI6No0YMNYJcPWt4faTXhAQgh2LpdOrMokjFsHErL8CAnj9oGELMskjJsH
ErIsk1Aw9yRkWSBh3DaQ0HkuklAMO6sFliRi2yTpc1jj+hw3QQ+Bievz5uP6vLu4LpIQXuis
ymcSlm0goWkdCduZhOeprql8gf20CbQ+UBcAZyxkTJfaBDOygrwHLwAqB6f0KcLwF9eB+Fl8
hBShPuzNc5J/peMTboAea6jKUAY2DpID0qUC13K45RYJY7CYwbF7Bk0R5lyD0xgpLnEM9F4d
n1y7ATU6iwOiDGq+DRRBOnmZFuDsO0jrhzNOOrGyCu657vP+9qMDYQXdJUSxIVetX6hyl+RA
SUUXNKV8QbdovaSIo0QcssPylE68vnPXA887bnn8dLHdqZG//H5P6FD8/VIP39m8kQDnVBFw
grUHnJNlwAn2HnBOFgEnmHvAOVkEnGTuAOfkOOAEWw8477kEODnsrML3Xm4fBXkOalSegxaX
Q1Ci8rzvqDzvKyrLZAOnljWe1YFsWvM7bPKZbBdYrGEVM8GHv4ECT+fUGPLlATFlku6Wh49U
bN2NB1ZVt9sdeh7kI/KC8ullqrEIegfggFQfaLqb8kgJWCwS7QAFSdLvnlDpiA4dwAvsyhCf
6IK/O17zUfEPzscSFcvBkxrwYSSgfu3UZ95cB/RFdKKr7DDCAYF88ebhTjOodYHfFy4SPOii
Bzen3/1yFRfCf3O4ndnDSoxLrDq4N1E9dkPFWa/2dDWOd5fd9iONzZ4VCR/VCEVzpHije5Tz
PUq+B1Xo2Pgiy3B9Q84ZioFJth2uqt3YfDd+GbS72+Vh/B/jVbDjJhBDf4VjVqoiZgYIue9h
D3uo2ko9Rwm7S4REBKyq/n39bM8AKU57CQlv7MzYnvfs0+Vu6WIHixTPG9CWWj3WnEV8wiMi
SCNE1v968jTjsPAiyDUzd+A/KXH6/g2FduAcrZQoLPtnkoBSyB6SpY8BCsDqAmwc45e1FNDU
4w+HtRT8lwp496DNVdRWgW3rpAICP1CBbfukAgLbKrBtnlRAYFsFDPOoAgIbKrBtm1RAd26q
gBl2QfO5Taxz+LgL+zY+h3Ubn+Nm4Ckw2/h8+G18Pt02bopBCDCggKgYuEPsz5y2jx7NUtg5
eax04Qjq/mBia0QHuq7XdcTOTOZTS/yRo6Mcskbe3WRJS3SKQXJkBmcnj6i/mInBKTOd+2EQ
anBE+MyfdIdb/fIuj4yV5rh7fsKg+xV3uBKmIBWjLQirOP1suc+Ovtb0W8/UWMsGQGfCvTUL
Cj1AkEwk0IpM+Rn9NCh+YC6tmDlL4iwYnHTBJbs0t0beqfly2Tt/rjbkYqqUKCn0WI2gUzwp
mtTLw+iTfnRTewPcNRljSNdR0lWCtPG4Um5zSszp3MDL+TfM3W5DKTgIS/48C1Wi8/bU0U+I
crjrmWnAcEiipNP5VGgaTCqt4hiw4Z80R3CrgYkDe0EoJ/2ZdaQiBSukS8NQuXdHot67kvEp
QrmObC8NHZmOewXDezkp0k5n9XnSJI2vSBE70oJrR8wQpcxHjlLfNVOjb74gZyXvs8KCtdrM
yQraWbzSH4fd9yeI/bdsaqg2XE2XgMqXuIDKohmtyIc041V6SacPFic6wOszlbjjpmrUd+PY
9jhvoOLwqcHK/xodfZrNyirJolQg/NE5WX3hlt/qizHTZdlLL2+6uHR1far5+qh79IKeLx34
gO9GwTflsGOygAjf2qG5bMZSfEi0elQMaX77RkVC9+t8mlp9Jwv2JMeplqlhKEoaUoiyCx7i
yn3tPQcVwv3jupDpUOQPZFpRU6YN6yjTCtsybdhHmVbYlGnDPMq0wqZMW+Yq0wpvy7RhG2U6
7tySaTvsjBJNJJk7eqxcwp7iSW4NYxvFxhS1M2r8dcQN7zHjCj/IuOE/4ob/WBEK2xVhuI+4
4T5WjMJ2xVjuFbfca0UpbFSU4Tvihu9YcTEyZsUZ7iNuuP8HbDZePtT4ErjxEuZR4vkjwADg
43GDCmVuZHN0cmVhbQ1lbmRvYmoNNzMgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50
IDE0MCAwIFIgDS9SZXNvdXJjZXMgNzQgMCBSIA0vQ29udGVudHMgNzUgMCBSIA0vTWVkaWFC
b3ggWyAwIDAgNTk1IDg0MiBdIA0vQ3JvcEJveCBbIDAgMCA1OTUgODQyIF0gDS9Sb3RhdGUg
MCANPj4gDWVuZG9iag03NCAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9G
b250IDw8IC9UVDIgMTQ5IDAgUiAvVFQ4IDEyNCAwIFIgL1RUMTAgMTI2IDAgUiA+PiANL0V4
dEdTdGF0ZSA8PCAvR1MxIDE1OCAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczUgMTUzIDAg
UiA+PiANPj4gDWVuZG9iag03NSAwIG9iag08PCAvTGVuZ3RoIDQyNjIgL0ZpbHRlciAvRmxh
dGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIncl0tz47gRgO/+FTiCKYtDPPhAbh5b2SiZtacs7W5q
p/ZAy7StrMZyibInyd9IfnC6Gw8+RMiVZE8plykSjQYaDeDr7o+rsw+rlWSCrR7OTGoKlsEf
vZgszXRWsNIUaVlkiq2+nn24bHO2bqlTxtr12YfvloI9tmcz6JzJnK3WZ/iWw9u3sy/8+2Qm
ZZrzz8msSAX/tGQzfKs4+3Tl2thqvlyxy4vlfMlY8svqT2cZm5UgkRkMckXDgRVuYKntwMsL
GFqYVPNlghP8cP1dUqaKs8X11eKCLW/+sPrp4nbObj7Pby9Wi5vrJfvClovlzS92Dlh0ZRed
sRIGUJmgyWgenIKzZPXXnm+EpCXDj1RZWqFJpS5Tra1j0DahrJW5rkprpSjY4nlzSDRYtqm3
m38kOay4dg27Z5bkeQZOwtaGnm1bPzZk4Xx1JtiGnclcphqsKzX6hAkhUyXZTKSS7Zuzh7OP
q55tqtBpKce2HS9KZCd3XOVpUVllq5LhhCIvCr8jWuOgtOvCbclt80BLSBMB28KWzfpA3xt6
wmJVmqcqbDGMp3Vx2ulZWlZK0GJlZcJpMKjAl9uUuqMRpVRjC7MSe33h17tkluPJoImrtMwN
6/Wkoew48mgce6rLcKrdtq6aZKbTgreHZFZydlknMxiXt67ZziREWuBxHc3VW6d3wXhCUVnL
lwd7Q5qX1g6pUyPAhuE6RbgbfiPm4HDD/wb3oeAvsAvNPbttWmiU/DWBTeDbA8PLkynocHNn
Jc3+DfrRNCYtSyGO/Ck682G4VxwEFpGPHDrr+uKR+JpI6MFru5L9r4lQYJtbDxzxysBdgsMt
shR8laW6YjN60tk+LYXjKqsghXmM7IuFKFIZ10Zx0akLOPOq6HfAi5fpqD6KcxnEOTh2ML3K
ilPqKO6pw0pH6ua0uhmoF3KkrnNzSh3Fp9RzeXLt74j9tmVwkgonlTqt9GhjIvLg+Ig8eDYm
N6flwTcReVhdRP5x1QsfI4LCIUL8FmU+CA1S+EuK8KLQgFewMgAJDI4V3BBwJce7WLrnBgJb
xd+SioIDStlL0+x/z26eqW3dsMOTlZKAbayevVsyLfLsmC2wzc6QSlpD7sEO4CtMB/DKebsG
piGvXfMbzFzB/NS4T2ZwbvyX12QHq/pEXV0fr//6+MT+iAQ2Xm1re7sf328qLqDjAtystcAT
a0+GwRLWW7hnTS2PiZedk3PANehd9BE46DIpIBDAjJqDC/kBHFzy/W7bn7tPPLdVd9vd+ldy
dHBxvYW2GsnqYA8oVVUBIU7nZRUGCPmQdPnQj81+8wBDSf73RFQUK2YSNMCsxTNYl/PNARIF
1h5gcJjNjg5nSYpybJ7ogAxR7uZ6BuNWfP6XxXIFPsVANIfBYchr/+3xnqlC9JANt6XMlQ2E
xPSOy0WlkaoR8jpplLwRbU9eJ46TN6LvyevEUfJG1D15nThK3pi6GahHyRtR9+SNqXv4RNR7
+6I9eHWO6Dny/JS879kped91k3JzWt5f/JS8v7opOaA1AlRp8EKdAKr8TYGKVwbTI0SGtgPG
uEp3Mdx04W76evcMCVjO7ROysI1rYN8SiCUGLvqT/Xa/Dauh05t7J6DThKvfuZwqoFA5cgMe
GgDFHeZWkm837RMsk1gtLZ2x+TyZKWK0E47QAqMPK7fM2b+4XlgfSL64wKyt4p8SCPeGL6AZ
vn62X3P8EvwKl4WQRwfCAvbOl8O1HOEdCzucjZTtniEC2wRg9YATUCDCjdizGndJY4XnLIOc
HsIBBo+G9FAL/+0oj9TbSiKAPz5ED4mxIUzCqDsKNoZ3p8LuUC/kDuCf27x5kJfD9S5N2Ye/
AbsB/gbDCBzZQmaQWWAcUNpoPk6MYWC8IzEAW2kcwNPaAcBWfALA0/oBwFYcB/C0egCwFccB
HFE3A/U4gKfVA4Aj6gFR0+rdvjhRYY58PpL0vDmS9Bw1lpiYpLe8kaRn+UgSxWpOzuiwqggy
gTd4atWAqwXchzoRcIbhpsG5tc9NglXdG5xtvIsotdcDLhDWnIZAjB0P1BGMWjebQfcTbD2+
pYEABREgo9xyTHvL/8c+7Wt7vQ+YKx+YvdT9MDFEogrTuvtbr9fNC+Z8xAMFDEDI45t9Osjj
a5qAD2HAxWEE8bAW5RJagrZByhVgzSt9bO/tF7uzv0h0R3BYKYCxhJVvwHDAYnugWIX0vEw0
LAU2SWQhofaLKcNiVEikBaXymdtF5Z41taDfSif129W13KdTPA/pKKcschqLx26F85WLAgen
AFPyq8QdthInb2nVcHA4xi0yG/1UkcFexO6aWKqMfu9nyv9cUDas+DU5quT+e4WpeO/74pN/
+xljHKXTdOaunOK/qHQxQ09b7NObdqfVMh+PHETd+pl2z0cALEYgTGEpovgTiRo8O4qPwr8O
45aF30Gh6QLNsG5o29q+PLoGHFrQEcECaGxlFax019xeKIruWDN8P7/5wTdZIyVfr18T3JJ9
ex4J58KEYd3xpuTGhITKxVbNyQ2GdjDnL7v9IVaDhQsjjU+sbDWJ5ZJwT7p5/eb385v1dtda
3XubWeT8vktZrAhpJenY9cc6NunO1bfetK9Y21G9i4lSy6g461uje+cRC7bEnT9KaiijkrZq
U4GNvmqDo2HK98q2HMAfSRlQFM0XpvR8soCyeKYwpenTBJRFc4QpRZ8goCyaHUwqmk4xmhdM
KfqkYFLRx9UpxeDwCpWsVACNsyPPRjp0Dox06BwV62De6dAtPNKhW2CkQzR/0BoAUXT5Q3c1
7OHWcCH4IIEwFHNnGLPbFssdyzugzAv2pXoMiInhgNXbrW11Cvv6K2Kz8ioQyNuTmcNRrAmR
TFEk03DnscwgKlG+j8Gli+8+31enqxgZ2Jw55td7VMZ0ob7bNufEE1umlJQsFFieqUE1I2JV
ilJdTtYFb0l5gYAhcGzjnjW1PFLAsVKGdMPPe/bn+ZwyuIpfYOgoMN4KDHg/zv/XWDMshGBs
ofPgnRBr/KnoIj4uXbqqsXLc1cTdnLhrv61090o/2/t3gn0P9rmD/c1nmodCOIL9Gp0PKdKt
+75k7aH2kZig3divFIGejxAcZusI7NKeEYY1UE/rGImdNArjiLbnsRPHkRzR91R24iiYI+qe
zU4cxXNM3QzUo5COqHtOx9Q9ySLqYV8k0YykeTnh+Wl559lpeee6iNyclneLn5Z3q5uWRzEN
l9LRw2I6CxdcOmDleND1GNVEXir2ENWFTU5teWf7E65/wkwdbyl22GwbtnmmV3bjBplfn6K0
kCFprKwxt5QVzm2meEkfQAJN9SMm3ECGc7bBIGEorXZULy2hMioBsbdNtqVNthUfQi5Awk2K
6TKmfDPMxZ4aW+rucQEKq0xKXl2r459x/AMjvFpCwa2gPBSA7t5jYeOoKLOERmcioS2fBfF5
t2e1zaGpPgHvhgz9P4gbO0zhcUF7Gy7S9CS5s7AzspoiN27Mk41s7LCvn+m1paNR8Z392aNn
wK8hIz+G9m+eoIexpBsL5m6bA7uzNK/XvyYUtQ47h/eQoB/v0X+fqgOB8rJ6J1NXcEXh+kZC
hJNGQ0RE24cIJ46HiIi+DxFOHA0REXUfIpw4GiJi6magHg0REXUfImLqHqIR9W5f4vFhUtjz
aTwyTAvNCWFvtfGAMCmMRwNZgdapaFD8f0aDASVEoK8Y0Ley9FVI38zRF/LtDLGDwwHhwAbl
nrVteoTpSi8/Rys2Vj6MOcr4OaGUpDkxkiAmHxr7S0wyuJInJ3nzEvcNJLMvsAuu73OC1QD7
hmEu55vDE3DSa/WX/G/iy6a3cRsIw/f+Ch1lYGNYkmWK590cDCyyaAu0QLsXr6MkAow4lbUt
+u8778yQkiKO2lsP/hBfDsXPZ16OUysv5ysN2KpkZa7WtFYDNeiYq50UGBls5yd0lPUt8/uf
aPpK+gMqYuKPXx605PNmzMMh5dRb54oCLdbbwsmq/A5O3hFE97IL/a6KnZiws3LjdXXJTlFt
dqajIztFXmFnOj6yU2SbnenwyE6RbXYa4X4WbrMzHR7ZaYRH3qTDJ+uyC+abNvpi2hfidE4X
4nTGlqJfEaejXYjTsSxEk51lTf7jQPWVnTRZwbfoiXYzajZEiMAMp98dnS461wQsMjesZm+M
zi+vXHZmZuLfKigjtYv9eADhju5BTJ/zmfN6Cot4Cj2DLeeTXvJJryJC+XTOMVlNTjiaAhiO
gv3gQFGUfSUK+fyKrzuA08H5oRZo/DZk1ycpfQfEaNUOatV+biWXBLrVTLeaLTiAGuWT/HnW
gq8b5B0CnkadpVh/vnMbvVS5bcD1UFEL57khdqvQbt33/RVOlupnD/pv4Bkr8+58Gjotw4Wj
5rbxBLuN5/629Nnl4f/w2bjt6KvK6LPRQslZknL4ozx9yE6XS3Y5fZNHzvRFfjH3BqXIYovd
jmpvbx02wjN9bpL8T/3co6uvVveBBvr20p6odvT7++D3qVOraczKWX07fKek1iPBUaPDdb7G
U2fPFwBPPYfFlxNTieVQd4/n7cze00luquJf7H15aEa4LFKUqmaKMqJDilLZTlFGfEhRKpsp
yggPKUplM0VZ4X4WbqYoIzykKCs8YN0Ij+tCx/IQob8l1/lu5tP6OLNpfZw6Q/fr+jj4tD6O
Lq2beatoyB4fRs+/zB7NmLc0T5xhZyvCHMw0ncsxS+GRshSdThFCjvnIiUfT0CJ5TYxjwOr5
KsCU7/ZMHFWC/rUp99RWx++gZ/1ts9NZOlRrh6bWVEF3N4dqpaQjMra3AUQDPy/d7WUDcrY4
5kX+KMUfyHciIw8qZhTBTJkjKCaInY7k+HDELCD2iOsDxfIFwku2bPLf5OleQPoJA8RkAXA0
lL4V1s1HpW8LiOQQcRSw+YBl9iS3lCu6fcj7gM4s9qdC6iQ2l+w1agCZP9LKs/CV/8/ZzkZc
ZtLJ6+lVBVXusS0O+ZVa5cQ8cN54IXw6dJ4Y7vh6hO+OtT9F22AaJqNbuwEol//LNaDwNAST
saqajDWiA2NVthlrxAfGqmwy1ggPjFXZZKwV7mfhJmON8MBYKzxQyAiP6+IYRclrQFIc5zQh
jjOWEv2KOI42IY5jSYg2TgtPFUeclhGnO8Wpn+G0YpzC/wJeTaSpHE34U5Td2NgNGz60PYyz
1uXI8UgnLgbKVjHVVTTVVTBn7CFbNXrinUv1zgQ7fX7i0zpoKRtjOm7dkL1ohVt2U/F1IF6F
8CWBeU58nJNixkjcfmTgDAUedq3f5B+ZSZ6VbXYcMhFeuPD6nX8uj9k3BaafmEMevXP62iJy
q6OR8HUEJldsMkqQtsqKRvwR8NwjbxVO+laA0bcAmj9+KNBZOhFNRUuPG2AGmHPS/TV7Xe6T
wtHagNtNTbtL90nkGo1QXOKPqUhKbeW7SMymi7OpizruEMc7pMkft9ln6fqnTYnhOOYmRtGI
aaVh1q6ZXyHpdDuvU/VL2+s18O9NAWgDwIdyt+cb0l219/slf8tmPDlL/opq8zcdHfkr8gp/
0/GRvyLb/E2HR/6KbPPXCPezcJu/6fDIXyM8MisdPlkXKhJ1X6PmVG64VSM2LeqSiri6oqn3
Bj3ddlhwUdfXO9V60NOth+0g6upuSDUe9HTjYbOIurpXko371cb9tPHVnZRqPOjpxsNGMxqf
7rNU40FPN76u/jMAQ/pMqgplbmRzdHJlYW0NZW5kb2JqDTc2IDAgb2JqDTw8IA0vVHlwZSAv
UGFnZSANL1BhcmVudCAxNDAgMCBSIA0vUmVzb3VyY2VzIDc3IDAgUiANL0NvbnRlbnRzIDc4
IDAgUiANL01lZGlhQm94IFsgMCAwIDU5NSA4NDIgXSANL0Nyb3BCb3ggWyAwIDAgNTk1IDg0
MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNNzcgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BE
RiAvVGV4dCBdIA0vRm9udCA8PCAvVFQyIDE0OSAwIFIgL1RUOCAxMjQgMCBSID4+IA0vRXh0
R1N0YXRlIDw8IC9HUzEgMTU4IDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNSAxNTMgMCBS
ID4+IA0+PiANZW5kb2JqDTc4IDAgb2JqDTw8IC9MZW5ndGggMzgzOSAvRmlsdGVyIC9GbGF0
ZURlY29kZSA+PiANc3RyZWFtDQpIibyXXW/bOBaG7/0reCktYlWkPjnAXKSNZ+Dd1hnE7swC
QS8URWm949qBrGTQ37GL+b17PkhKskXPYrE7KBpLOjr8OCSf99XbzezNZqOEFJunmY50LmL4
Rxc6juI0zkWh86jI40Rsvs7evDtmoj7SS7E41rM3P66l+HyczeHlWGViU8/wKoOr32b3wYdw
rlSUBT+F8zySwfu1mONVGYj3N+aZ2CzWG/Huer1YCxF+2vx1Fot5AREVQyM31ByMwjSsUm54
fQ1NSx2lwTrEDj6ufgyLKAnEcnWzvBbr2x82v1zfLcTtT4u7683ydrUW92K9XN9+4j5g0iVP
OolkGReiUFFaSm17lKXtUSru8Rhm0FtHvVVdI76GKo7y4AW6LUdB8dCIf4ZSRjq4DSXMECZa
wtAWMGB4dSXWi9UGrhN44V+RmzK8meW569/NWJoZL59CjRPcdmJ7FNUe+s2DbyHUoAjEIZyn
ZgBJ8IVCTQhrkgQtDzSlIargM8Xs+y0sD6bTGDZ/4Qor23Nccs882CxY4tsy+LC4/WgfiUNd
v4QlNNxi+2VwJbovdN8MJ5ambmL9HomzYfMKB4P1gZmV0PIxxM3xfGg7UR/4Ef9t6m5rHkAh
6C1R7w581Tx66hmnbgfl3C30k0MJHsN5hhWBYeNtI44dru4DP27qA198xUIrLKrEwYnV7Wo+
qhq3z00v/r5chykUn6dmll4FK3vPg1xsZlJsxazUURlLURRwpmATijn9bZvZ06UQHE9Vckhl
kVbDmJR5pDx5GMtNokyyKMmHUZUpOPXTmRjLFMcyWP1Rl0mcexMxZhNhRieJ+kKi7hNzdZKY
ZtqbiDFvYqb8c7wUs4uR0xQ4muuTik8FXVGngq5wk0F9IegKMBV0E5kKvt2csh72gQLK5loi
9In1Fn61AyLubYnkKIOYfwRu6BIPyHUoEX41UqcIuu0rgAYp8MwvNk37nQCElQA9Ue129nnF
77cVUoqZBdlNe+QjoqI8g2GdHGaVOIYUPKq2qRvoEjHbhEi7R/EUypgAFxygbeQwowneEFXd
2bfFMwzNATCoWozWzXNXPeyAYZt/zODE5kmZC0CrTJQdAw0hi2RemiEIPPIauseu9qFGsuBJ
z+AVmNPfFgvQgQJiUClkw3uUiDRY/rzg3kFAlCzOdKBwC5BwP4TzjHCeEM6LIEK8QF+Il5Tw
XyDI6A2UhJQEa4irlHA1H+rLMSwhVWLxDi/8u4MWJM5DIiEfAIbQeUIYJKGzLXrE/xYmDJsi
R/whnFdQEEgWd+b+HbLWChexv+E7bhg2d5JLkURprkmX4SgUWeI4GwhaHqCoPZhx3G/1c1By
1M/K6WyHSw5fIOZ0voMmh/3cnE536OSwn56edD1K9zN0Ot1h1JPuIDOdPlgX0F+OpjDeicpP
xYeVnYoPSzcZ15fjw8lPxYezm4r7KZrCLi57isbamQ/pKIpHy/ycUFQhRSUxNEeiICvxNWLo
LwyRLxTaAqK2e7oUeNrQoixWZ+gc2K9zoN/BIc/wiCIn3tENoAPZ3IXoYQEdV2JryA3m06C2
YDeEuOa32ZIqtqTW4ox8GGHCUcJ0D/5KSjz/yMQvDZJBI7apDXBdCWMBnx6PFV98Ng+ETQtl
YEJ7uBTmemxrHUhjA1JL5JSIzDyWxONDKyqCaYKeF+HnPO+40SRxGLWtkiHGwbdHXhdOsCKS
RrlM++8atxrKlAO2ghEM7A4XA1cahbRrybGq4EjboQwO/NNiDaCC+FVwKiQXfffQNBvT/cgS
mZF6YKgLkdhOPc5ttWtVmVZhFMemY/8MH0r1r9AO7KjuwA/+J8a5V4asKMfKcCYKORAXz+i0
KJioVxQ82VYUTNgvCp58Kwom7BUFT7oVBRP2ioIvXY/SvaLgSbei4Eu32PSkD9YFHnE0KyYr
PxUfVnYqPizdZFxfjg8nPxUfzm4q7hWFrMSq/weioP4cURiazP+jKIwhLB2E9BDCJc4R6okQ
RnOLECafq8nOK3K7hflb0ZPP0Lc00SscQk0MkyPhGfLPzdEqD5JOUWtJ8ErXDV3DmLGj0tzy
Nf/dgu/VwWFPb4vfQoXLs+24JWF+h58UZ8CUuSu18d0kmzmjFy/YuCsy7gmhd8sPRpU0u6c3
2rTKd2ar0IcAjHd5uzJP3oe9KFstgmIWUuLIYCMV/KVxjwCdA13Zh891nKD3p7weqpmfqNkl
nE7lWZZmF0E6lWkpml1C6FSi5Wd2CZ6TibpP9GJzKtEyczLRImUq0RU86w12rk+rOhHsCzcR
7IszFdQXgv0kJ4L9RCaCfjDKArJ6MCKDasclAmMygmECp7xGyjAOCzyqdOa+E7d7uq2JgHh1
EXtnZxEPEtqfBfJPM3i1OU3SnSZNmApOzykBUTNARiYx7U2i6QdbxKwlzkI7d4mPhDGQKRrI
IkAvumjbQ+vBWpw6Fcm57RU5rRxK80Q83NZVtzXPUBXgWJs77CinjsZc6H3Vn+FRh27SrbxS
zqNiC4rkJAWnyndXotrtxK564NsGXaIMduOyDwAJWiJhGFWIrz0/w96Ajwj4jyYX6Fa1jU81
XHljU9622TUV5DnXnFrXDMPzQL+XV24DN05OG6foAQ/jaJvuJYRqQbPYfHcYTUgOnTLZaA2z
QcvMGzRhvTZuGe+jkV3ucX/BLmcq74/uOdw56uf7dLZDPIcvUH4634Gew37WT6c73HPYT3xP
uh6l+7k/ne7Q70l30JxOH6wLnHWPAEwFhzU9Cw4rdh7UF4LD2Z4Fh3M5C3oFIE2LKMt7AUi1
A6Y0NhH2vlOAt1tzfOjM/C7uAcrInE/iSrwP6TOxCpPgodnxGxcU4Jxt0JYEoD0yt16Za4iX
Imi77bH5GkrwpAy5Ttxsj/XWoG633RsK/s4PxjTKexEwJNnSly6gCN0f3wCq6bc5kpUWfPcN
6VUEz404POHwQCR2FECeFTTR1Jk767TP7G71ODS5OBk2uchGnBHGukgsUcM0EHYCiI4/AVHj
jHMJO0ioIY3nexFfiZsD2GRUmb3jbRcmWM6mMljuB27HnPCQP0JFgyMoQA7Vrbcd4h8W9JqL
QDevSGJcH+3Wp8RZYWb3RytAA9XB9yE2J2GsbO/5qweGXZjV4dXgxeBhK5JRjpq0hhbDxHhl
zNpye2P7ng9YTvPRvOdS2nNmTkm/51Bd9ly9sViD70/l2NEAYQpdcNs/N61xJd+wlYLsfa5i
+jgDo5/q9Mzdg/r3p/dMA0zUqwGebKsBJuzXAE++1QAT9mqAJ91qgAl7NcCXrkfpXg3wpFsN
8KVbbnrS3brAIOwngoQPM7g5Kb3nhb62nhf66vle0H/wQl8Bzwv9HD0vePUhSXGx0ekafehP
sjQnWWa9PgDBjJPeg03Hs0SyEKzh+GTBHYBOB+K5PTwfjgxE/rmoE9rphLFwN+RLJVKCKZ5D
q8eO6MDn7IUemQCgIwtMikMZ3ojKXLzSiz4bWjiaGzSS9Sys9Sxgjgd7BXwHDwngvRHMfDr0
58b0hOZWOM4c7331CVVB4vdW73TJAkNXGUKd/m9D/DA7sCdGTwtoNGkwc8AVDKpC096Mjbrs
7bGRqvqA3wtlsDfcJbqbZ7sdlo7wRR9jmfk8y4IP4o34oUU6xzC+u2ZXEfJOhVG6+RlvgcKN
H0q/0t8r/iTjiRphhHljNbFlCL3QE1TPgjw8jOShEcOnzWP0X8mn6hXKfP/cP0DtUUZgf+IC
axJwUgZR42cIah3/OKnNA07gxyi22qpWX4p5b7TwqjC1eNmj3Eqc5g6rrGBV6acG1YDWzF3H
Pw0/fDQZohrfv0LF5L9Zr5blNoEg+Ct7FFWxw7I8xD3HHFz2MSfJpixSKuEyOId8SL4382QR
2sEXX4SkmR7YYbd7OlDH0HeNgnJHiQvcfYyrQvfZXTMfBhU6iMD5rr5W6gLYIEPnMGSKXAqn
CocxW95SSNU2jJnClgKqqmHMlLQksI1AU8xSQFWyJFApPgWcG15El+Nx/KrXnTUSYgONhNgo
K6H9JCEu3EiICzQSTA0riv19vo8eZ2YhOegeVGBX48eVkBF5w7lHggfmxHjHBHVm5QDdaPSv
OCzSANzoqHirab9o2FTc1L0LqkcUSRMQOH7Xe/Oth/mGjnQP51yqQAfOI+lfc22YuVbOKLIk
qiV+Hp6fu7fpcDx3bhrcgf9Eqc5h0U8ZUsUjTbzXPADS7kPAVTCHzerRSCuhgZWvsXOoDGhm
ThnaDCIZeMifT49ITCVU/qDAOLlRghemICVKmMcL36x5uqjmZVWixu6JWNjv+BOlsGAphE4+
Mk1nOIv8zu7InzzDBPCJCn53D5jccpPBMIm08S94aSNtgZJ8anNfrBzGjbUl6zqwNxV/K87W
sXOV2AQsivTbgxvt5T9OMKaTfB4ZijreihSo3L1mNY0DF76+d+Mblqz5bvWO/x9xD/AfqVEF
bxJPjGgVbE3sdce1oelTfzj3f/WhefbyK8mrtUo7Pykq+Mge7RUlrCFoTmoEa74MdJ2wZlhV
y+cNHmQu68YJz0oNqed+PNE4gIeIxoJrcFhYQNx/aEXHER8e7x9QBbUbQEuh9tHrAY81FeFR
5GCWiIpWhCaO1zeiJlFT1wy0SpuEbXUz8CpwEjY1zoCrzEnYVDoL3l7BTb0z4Cp5FlxFwYAv
3ku+3zBvZsKyt8mEZffSCe0nCcsOJBOWa0wmmMLnQSfyMgpf5echV70UMOyseT8ylJU7PpXH
PiNCos9vMGp70oeAXmp4c5zbEddyDtAqXRk3sDiBC8Tx0/3bcnhhH2dv4cueTBvO0sCX/AMY
ka5A9g2yGaggEu+JcjqOyQ82Le7Mzg+eNs2dZWyHl3a8UCFeTEmLKXkxnhdDPux4wEdA6S/g
AV7E60Lg4cCok/z+w1ctNrwb/Hrri3o2M04sEAq1+hrUmJWbUXkGWfXlF0/poPdx3LrhNIma
nGagldMkbHOagVdOk7DJaQZcOU3CJqdZ8PYKbnKaAVdOs+B63g344r2A+HO0atbhptrgw3RQ
XikHN99o6r4aT9fWF87R7fedqq7xdHXdDhzd3A2p4hpPF9fNwtHNvZIs3m4Wb5fFN3dSqrjG
08V1oxnFl/ssVVzj6eLb0f8CDAAo77JZCmVuZHN0cmVhbQ1lbmRvYmoNNzkgMCBvYmoNPDwg
DS9UeXBlIC9QYWdlIA0vUGFyZW50IDE0MCAwIFIgDS9SZXNvdXJjZXMgODAgMCBSIA0vQ29u
dGVudHMgODEgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNTk1IDg0MiBdIA0vQ3JvcEJveCBbIDAg
MCA1OTUgODQyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag04MCAwIG9iag08PCANL1Byb2NT
ZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9UVDIgMTQ5IDAgUiAvVFQ4IDEyNCAwIFIg
Pj4gDS9FeHRHU3RhdGUgPDwgL0dTMSAxNTggMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M1
IDE1MyAwIFIgPj4gDT4+IA1lbmRvYmoNODEgMCBvYmoNPDwgL0xlbmd0aCA0NTE3IC9GaWx0
ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJvFdNk9u4Eb3rV+BIpiyaAD9xyGHWM7s1
Ka89NZKdg2sPHInyaFcjTSTZO/kZ8SG/N/0FkJQIJbvlSqlKJPHQQHcDeP3ww3zyej43Sqv5
amITW6oUfvRi0yTN01JVtkyqMs3U/Gny+s2hUIsDdUrVYTF5/dNMq8+HyRQ6p6ZQ88UE3wp4
+33yKfo5nhqTFNFdPC0THb2dqSm+1ZF6ey1tan4zm6s3V7ObmVLxL/O/TVI1rQAxKQxyTcOB
FzKwyXng2RUMrW2SR7MYJ/jw7qe4SrJI3b67vr1Ss/c/zv9+dX+j3t/d3F/Nb9+/m6lPanY7
e/8LzwFB1xx0lug6rVRlkrzW1s2YZzgjRaUznvI6zpIy+mtsovSV2sRFtNs9q2V7hLd2gf9r
bAOvkiraxjpFb7DpAI7ZyIemE12UpZ+nosh4hiV0h4gOcQ22DcRVRw8bamqXCQ8w/wt2Xkxg
vPmvMlyed8N1XndOZ+A0OkVu5/DiHMd3dB2fa0Zgvch5dB0b0PkyUi21NQ9s34JrOnIu3cwn
Wq3VpLZJDdNWFWwNyKWa0v++nawuQbDLTM2QKRJr+pjWZWICdoiVYqizIsnKPmoKA5t33BKx
wjBWZPDaB7O0DBoi5gwhohNDe8HQdoalOTHMCxs0RCxoWJhwjJcwtxglhcBoXuCJHyY9gPvU
BnCfwRBuL+M+HwHchxbAf5if8hhsDoM8pvMkrZnH6KyY7rAYPi26VnB+s7qAPX/X4MGw0SMe
ZROpj3CSCjkuNtrt1dtYG+i3pu+n2GTyyh3Uv9XAvuXDAhYF+NJjAXKgNI7grLiyiKc1HDLk
EwPm29U6nhbgwOcve2hK0RXusZQe6on9abj5RQG/wlJmruHI9o/xVMIB9rVukMWgj5vUzdRR
D3Jx0WOst0BVFuLW0BvmtzDd+pgM+o8w6b/A0yhlpvyG78STK3r7k8Qqk5nM5REoXTj1AAxq
IQuwU4BOkUlvV8Rwx0ci2hYzVQHXchdpVR9hbljlQejWlyGh1/Ylxiwu2nZ5gNUuaFBsWcvn
Zk1pAX49vnJYC1sHMzUjhr8H98ygPPT4PCt88lIpqQ/tI1gX4K2G1f5K7y29Yz6gnjbyxN1o
MKu4OPJ1pH8hfyO7GZ5L1VBtMJT78VKFJUWit+zKKsa07XDT2GjP4WkI78ebN2q9pQ/1D0a/
MHQ4rqW7wDSVhsKa1aWq4XziduH5NBV9YL3Kylp+bPfrFaXun5xUEAzT0qQ5Cop4muU2j3xN
cjRn4NiWwbLDaLjyjFv74sPwhfozbu9LEMPhKjRu7gsRw+FaFDC3A/NwRRo390UpYO4Jety8
ty5pLahFi/PMj+H9zI7h/dSN4vYy3g9+DO9HN4YHy09pNKSjKz+ppyoj21vjyagiy4+uEl3h
ES6jzYZPWEYEUkMXJBAT3R/4sAFnNeqZjXf8AAIHQlvLl3SSr1Vco8Efq0rbdlAofo91hZxx
Ui9+Uw/SIt3VH69mMrT0OyleA1I+uxtQlkrI0qEh8s1xcI2hA9EzddKn9GOmxwlyjCDD3Att
5101cxxlkkxnnqO4GH7CxSp0iWvCFRFXJo/uX0EYsE+gHNBcrjwUTg3AlEZX53n3aeeAfttS
4jjdebRBXzMMCusfZSz6LF+Ke65I8IsE0BhwRcqEDB/jNBreJqjUOI6lZJS0dzBnlIoaGHZ9
5GggKbAVB1XXO5zKEjSbdn9UzRaSAQnePbf7BovpcTeUBqe3Fdi/O75x8D/fQdytY6RGknFR
9xQJOJvxrtHRYYFx02mAE1TDAcDdsxLU7T1JT8Xp0c7YG/G0wApZqRWcnEprt/ym8oFL+rAg
pXCXzKLb4zfUKnidk7O5bxe7KQ0GDabIAuvu40B1IA9Z3S0v9nA51/zghd8msMXPimCZaSSo
QBEUNFgEA9auCAocLoIBe1cEBQ4WwYC5K4ICB4tgyNwOzINFMGDuimDI3JWJgLlfl7QrkaU9
TfsI2OV0BOwyNgbaC2AX7QjYxTICButdgZ72rlvnJGHSrsbdMlUAx8BNSsupAVpjApG2L/TF
yBGuY3iqNsBJJUn3ClShwQd3UIsdj8k9m7WQ0YWCp+tafDRwEyQf34CHOV+JDMrMpyf3tqVK
BTV0RiRLVymZfqpR0rsnnE8txW9o+CwNjRgCHQG9av/95EY8ygjtSUc3w7BCDVX791HRRakv
qGhBgwQSsHYEInCYQAL2jkAEDhJIwNwRiMBBAgmZ24F5kEAC5o5AQubu0AXMe+viVSgq0vw8
82N4P7NjeD91o7i9jPeDH8P70Y3hYVYx9UBFF9prCCMiAp6eVu72u2Nc4CV1sdvQi/qKahrP
UoaK9UBCes19UF3izZQ6IOlkdHOlT+7Ig6mHVmnFRq73JR2dai+ytJeoBcrCA7hTCHeAM6jU
Ua9tqTFBMQpDv5NWZ8ToZ/pX3IaUER1QdmPHtuUuQ53snTAiKw90WYDJF8AHFSo8YFHQGktu
Vs0Dv+z48SUmJ9SWniSpa/CiZGrDHsd1I5cNG3EvJV88vvfnTO18FYHDiixDZkMBPZQ2Q5oD
IVpa65UYDgayrXQsh6QGgi1PkMymNgWr6OeGKgSulqj1xSPcglCmYqWBmNJuKYFoa1iu6Qmd
5i6LSKw4ESwHinKFlKohSfhx5Me+Tc6INKsvKDFBw0Q6bu2JlOELRDpu74mU4TCRjpt7ImU4
TKQBczswDxPpuLkn0oC5p5pxc78uVUezeYmkdJL5cbzL7DjepS6A28t4F/w43kU3jgeJNK+N
XFue5DgW/tZZCJGSUCn8s6PVn+NpzaxTwzZ/kXtmGV3jKTbRB36oty132H6mq0odPeLthEY6
YUu5ztGlsOpuhXKWr2JdEnGj+GliFE9I5igIqalVuxXek+AUmqJQcNFkuKWuyNyZ/PevkP1T
bfypFt13iFEOAUHigwgSA17HGvmSQQV8jGG2atky3GABqYgDTLQhKZu6xhdqHDBybrtIhZLR
7xJrE9aVlFieHkdqf+QPiRZSkqeworvF0VvxG8ZaRMkZXxZV/X1lYW41brgAmwkaZLOAtWMz
gcNsFrB3bCZwkM0C5o7NBA6yWcjcDsyDbBYwd2wWMnfnPWDerYujggIP/Wnaz8FeTs/BXsZG
QHsB7EV7DvZiOQfDxAX7wSnA/0Jc2fcnrpDO8xqEDhe7Mcdp4SChxmghqkW7/hqjyjLQ6DSH
eouHOo9mMYrNe1BNGUlPVGJw34WzXNAdFm1U19AOtV3ltV3mBWZJzHh4wtNcRM1m0+5ZjmUR
0hWc5vXxoJotdVwyQE3P/N62+2/UD+kuG1JX0alunu95v3veIe+UMBN4WKEg0ug0irdoz2oa
77ooaV9ANEfq7poG/sDDsxXjKKqR+jQRGmYQXpP49KY7lIDfidJgD4YFmqBhShu39pTG8AVK
G7f3lMZwmNLGzT2lMRymtIC5HZiHKW3c3FNawNzTwLi5X5f8okAL4V1mx/EudQHcXsa74Mfx
LrpxPMhzGQT+Pwq0/P8m0HoXN/SD3biVSxsceDxjR6aPxziN5FYHh18bOvz06dzR6A6Szwd+
AAUw8XA3cQpGCqk26wlXGHfZHts9kWfF9zIQa0u1RsqEmLhhh5oO77HNYtE+H5uHTTtkFZNk
JAgl2synvSwcraBfOV5W8Va7xrtqHa2AY3IUZfAJQgv8nkm/7VKS2vC3OghwOKx3DG1j47MO
iAHleyKLtc86XkHRjXuIymKyMPe/4jjA94sjBPw6kDDjy0QqZeIOQ8hhYbDc7BtInQY/WvqE
VB58OcJm7vUCJF911WB0R/yp9XWDdXU0k+KyjXFv7nAUE/2H9bLpbRsHwvB9f4WOMtAEpmR9
8N7LYoHFAu0fUGwlVWvEhux0u/31O58kFXF0KHpJLL4aiqI4z7xzB6RDr1NOx+E+yRjfgMes
J/sLhQHKB41Noi3KZVhvJXs5j7crf5OLfLMdpsttLO4yUFBFTQsvL9aFxcoZpAdCq3CfhvP0
U9foSh7mNXa0xobW6BdNSZpnTdiIXjaCEginwg8Bp8o5zOLXi/y649Fu+HzRfeGW9Xl40GMg
q5cDMd4gI3DBdXmebl+4kt/5/7tX51hpl0Z8tNcTDSusoV4/tPJkIFndugIp0UODBo8HAHYN
zYBF+fPXpALXvt9oKkQ1K7ARrRVYZLsCG/FagUU2K7ARrhVYZLMCW+F+EW5WYCNcK7AVrjXK
CI/fRSQHoHvfVeTVZFczarJpOdVvqckrZ9TkjTKqWXOrrsbe4oA1l/AQslvJVjWxyH4ab5QX
/BdtPUAKfD1kXvHXOF4h/7/TFVBkoqoEuC7kxxspHHqn0K3Woo6Gey9V6GmEgoa144L1B0sI
XjzsKOF/jvMFrT0OnfCRUNSAHg5W/YMGJzDdVSnCGw3JRXGUuAUyD21YAFYiWcAb9i5tCeiE
bpS8ek1+H3nZNg2sGluCCsoS7AvdemKVh1d11yGGPkIFdJ3rErygbweAHHBewMu+fmxXxr3q
6w3jLqqJDSNasSGyjQ0jXrEhsokNI1yxIbKJDSvcL8JNbBjhig0rXJPMCA/fpYrGtyYT/G7n
83rc2bwet87Q/bYeXz6vx7fL6zZE6h42io37sshWXfDtmPYt/4tA+Xt8IcN1YQEcBLg5uek7
KQOmT1ue3+hqLJ53vd49Q9nn8otXr+zcDBtPywpmsJLa/22HLg3AxbasIH7REPHLIRRGcNNs
hYIfWNnM1BiQdUSPXNOivPySYQCP/iwuz0gIdhvIyXk8jvB8dLgwPVAMsQT/FlTykUoCaCRL
UxKYfHm9XmakEtg2MCQn2EQaHuDiTMNy3/i4RBH4R7Dwv44i275UW94lFxcItOlacpGBPVt+
JRcYqLPlVLKBPgbasNkwKNnAkIi2NakOHQaxemhW5sTS4/bl9bhLhu639fjOeT2+Wl43GeM8
BPbMmAf179Kl1gEyHrK443+pa8H0rkLzWVPz2VFn0lDzJ/LAP150QG94o9tv9+KJw0WXrhaa
sfuWk3E+9LHSMEFeYzt40ozvqKvdw8C/uwpBNAERcHDiGwu5HBcoCE4t9Iwdrgyz+wV+IhYj
UMvi205JJ5xDnNGlBM1E0pLv/q0+Ze9iPVnzgVUbEfnoQAmWN0CRjw+sYNnGRT48EINlGxpG
uF+E2+jIhwd6GOEhy/LhyXfZ9xs+xdDTnc3p6dZldb+tpy+f09O3y+k2Q5oOAlOGhNRsfcIQ
X/b8LzLkz90D+vdnqOVQuV8vojMB+oAWT2hxhJYDZbXIA/94kQH0FFvIaAIypPcJpJB0PTAs
8BkMi4Zh0Qgs0Le8pre/0AUsEvZJsJCamcQmVcEm7YNN6tkmFdLgETpGAMZpBYq9q+y3gP1s
XIvxn0Ze3YkXhHTCteoj+AVo7ubxUAFy3u3Quk+NDedcjD+o17xO8384pn3X6lX3YYVVoxBt
eZsa2qZn6tqm43CfZIxv+MAdaHE8y/ANuktn+kM4pfocgTUZyh595jy80s/blYvJhf/NwFVc
wocF89fOWtzytHPl7TjMap6H87k4D098NYqHXkzVLj3rAZYw0EtcrxOZXehfoRbin9vOB6xD
agLvC5i2w3L28Q/I5a6hZWEx+Pw1Ab9r21jkV+AX1QS/Ea3gF9kGvxGv4BfZBL8RruAX2QS/
Fe4X4Sb4jXAFvxWuaDTCk+8S2lcg32rbV2K6pysx3bG16DfE9G1XYvouK9FkfA/oaGMrenCx
XxL3VfmI9X+G+w5P/hfsilzJ7RLk8ZGHL3Nxph8T/YU0qRC4dMF3FEdIX459wubUYWc3I3Ih
k+V+WOIG65tDWGF1EDhA/jkEwR7TrmqaJWVj/C/ZMd/F7VwlJYtmTuZjNSVZtTMyH60JyaqZ
j/lgTUdWzWw0gn0abOZiPlhT0QjW05sP1k/RRntW1Xhjqnb1Rg7nRfmKLNpfMf9YlfNT60dm
deMj5ydXOT+5ngFW7TOQn1vl/Nx6RFi1j4gxt9+c26dz2ycoP7fK+bn1gBlzhwOWn1vl/Nzb
6v8DAGx+klYKZW5kc3RyZWFtDWVuZG9iag04MiAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9Q
YXJlbnQgMTQwIDAgUiANL1Jlc291cmNlcyA4MyAwIFIgDS9Db250ZW50cyA4NCAwIFIgDS9N
ZWRpYUJveCBbIDAgMCA1OTUgODQyIF0gDS9Dcm9wQm94IFsgMCAwIDU5NSA4NDIgXSANL1Jv
dGF0ZSAwIA0+PiANZW5kb2JqDTgzIDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQg
XSANL0ZvbnQgPDwgL1RUMiAxNDkgMCBSIC9UVDggMTI0IDAgUiA+PiANL0V4dEdTdGF0ZSA8
PCAvR1MxIDE1OCAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczUgMTUzIDAgUiA+PiANPj4g
DWVuZG9iag04NCAwIG9iag08PCAvTGVuZ3RoIDQzMTMgL0ZpbHRlciAvRmxhdGVEZWNvZGUg
Pj4gDXN0cmVhbQ0KSImkl81y47gRx+9+ChzJlMUhQAIkDzl47cnGqbFnaqRsDlN7kCXa5kQr
qUh6J5PHyO4Dp7/4IZFQUkm5LFH4o0F0A/h144fV1bvVyiitVs9XRVQ4FcMfPRRxFKexU1nh
oszFiVr9cvXutrFq01CnWDWbq3c/LrV6aa4W0Dk2Vq02V/hk4enb1ZfgIVwYE9ngU7hwkQ4+
LNUCn/JAfbiTNrV6v1yp25vl+6VS4c+rv1zFapGBYmIY5I6Gg1nIwCblgZc3MLQuojRYhviC
vz7+GGZREqj7x7v7G7X8+KfV324+v1cfP73/fLO6//i4VF/U8n758Wd+Bzids9NJpPM4U5mJ
0lwX3RtTjW8kr7QWX95CHcOEG3hRFrRhim48lRCHip6fQ63Js1DjjA6Ho7oLE5hhCTM0YlBu
+JtNDuBDVAR7Hrj3XkfaOodToQmkeed9lvNU3poqXKRgsn9REEadwiBrDCfOi4TXUMM71a8l
t25ORHxtDK+vw0WBDikZrcHpgNVW9K5Zhn6S5h03y9Bd5yhcZOg+OfF+daVVpa7yIspjrbIM
tgvEVy3osy6vni9JsPNMzpKxUWHGmtYuMh471JwY6sRGiRurxpoI13XOEjVrWLMJPI7FJHZe
Q9Q6Q/DozLC4YFgMhs6cGaa28Bqi5jW0xu/jJa1bDEcusGoS6H4WdI/eh9aj9xH06cVlvY+H
R+9d8+g/rM7ZBpvDINuSDPFCbKOjZoZjb/isJbGCHZ7kNnLBPZ3xIlC7EI8cHvFt2dIzH+yC
DnbBBzvngw0HihsRHHBASmldP/EoiIck2F5Lr+4VdI5M5CxMc0QEgmDSAQHARZM8rtvXMEf+
/UpfMJtDDb5vykoaQghKsFVVE9p+dEZNmvYDp3ZwXwi+rcDA4KzM8IVTdkHNnljACnZRItYh
enf4JYQFgAmx+Mo919K1gUnp4I0bj8dDze087nYGhN2KsNtaONjADDKw2yKRILRtvT52j4fu
4ZW6lEoapAPQKwZ61euuYz2Y0OtXf+BA9KmnkHfCABqnCrgrEKwZrfoCdlTw/B1DACT/Bb/z
rrlZSLcDme6fpf3lrSZ4Jghv1FtuF1l6A1i7BdNJ5JLcqTRyOu2zY4oztJF2mewGtaRFxmhq
2oMYIIh6aLXLwemyrmF30Ig2So3OJikn1p3XiWS/PQ154JzdVs8QVBdUm3VbSRt3UL/h6x4x
uHnX27PZprv4dbRVd7uDWm+/ou/rDSwzKpvvoUHt98izQwyF4ktwG2Jm2kH2hWTXhA5Wn85H
ig/1ek+P2I47r1/uL4EoWzg5u3J9ZngsSwkawChxerQKQK/MsjvoSQCFzOorJsGOq6lDJPny
HKv+VDdv3Wc7li8kvHn7Puex7E978+Z95mPZn/w85sWJuT8Fzpv3WdBj3meEefNhXUSy2VzY
p+IoplNxFLEZsbggjrydiiNfpqI3tbkMhxxSW5L0bMdGSm16SG2f6UBzwijoFGrY9fW/IBvh
ScGj/QEzUxbcEaQ/SR1/D4nrW2jwvL2SYbXh70sJTKc9yR1PpdoSylNCCxalVQmZSuiNp09y
Gf1AulicG1Wv2G23fip3o4OMjQR6h/S4BrS/jE27UWucOpXj0jK8rxtrnlSTzIqBigNJrvdb
eCHkAANeA9pRbzeSnyVPlx4oxn2OM5Ljqj1E38AMq/Wu+ifz1lJtgc2YabCySKDlhVu+YeJ1
5BL9Pulfdj8R4MXclYNWJevXR7ZK1aJvMP8/lwOZObp7ug9taMGgR3SaqmyUZXiDusMMlcnA
kqZg9wFHU4w7jBbjrPvrg5xQl+dDRTchp6hecnqsO3KK7Cenx74jp8hecnrMO3KK7CWnz7w4
MfeS02PekdNn3tHGYz5aFyg8WHXFNOwTcRzTiTiO2FQsLohjbyfi2JeJ6CdnDBFyAzmN7Y+/
FMWJOb0TUJHPR9sCVUoss6ny2VMLHDnYIidnJ4cjKHWNlbrGBdc+ZhK1k74SdQLN9rXEwwwj
f1h+RhJgDf0GeIbiplWNiPstH1W1ls5LEZoGWYLSnmxOmIcl9uZqfBH6TC4RQXVAx9/iPaPc
qnfq8SDOjYcYikgjtfMjwaeQ+jHv60ds23PEwIs8YqJlRDRoq0SrSyy+pQ4dbJpTWsc9rY3Q
uqXuGcHXEXxpxOQcqlnAzQRVSi0JvOSF29asbWUoD74nLvMUO79V2bTrJ/6xq5pX9qvl71Jt
TvziTwjxaYjgPmCi8xvB/4tZXQwHZIpZVv2YnbfuMcvyBczO2/eYZdmP2XnzHrMs+zHrMS9O
zP2YnTfvMesx79E0b96vC/DB+TA7Jw4xnRGHiM2JxQVx8HZGHHyZEb2YtSmck3xUoJqhQBXk
QM16xlnY91ipWqpPkwBqLIOHywBM2pIrVEcVquUKlasxwnEedEVkgYUQ2W8vE7dnoOuLMSXQ
BQTcEj3zAMHLH9KwF/ZmPWJzQqw5RWzc5xUjeeXIYAZQU/G9Jg5hiUm/27JurtWW+xz4S6RG
IRv61laJpYyE1SfKTBp7Vt4mI1iU/wiL4MhYP+zhuTzlTBKlrig63FEZD8BxmZBWLakCLsFZ
5BeUxDBddNtql0M8yro+1DyijVIDnDqP+UBQuJ0IQYX4CD/OHK7PHMxJqrp/w9c9YnrKu97/
oYp/HRXwQ1Xb5eVE8nIa/B6dDkRufwluQ7z17CBJAOBhh0GsqATA60Nbr/f0iO3HQ92OLiei
bGE77sr1meGxLCVAcOAA2wruMMZZjA8cz8wOi4VgX30dQdymxXD8JhAX1Qtxj3UHcZH9EPfY
dxAX2Qtxj3kHcZG9EPeZFyfmXoh7zDuI+8w78HnMR+sS56Ja2L3TwM/I47jOyOO4zcnFRXns
94w89mtG9iI9zY0UYIL0fEC6EDRJB6TfYMWqgxU0aDjBD0SPjNCMFWBGxwc/qzBFuAGPkOLH
NZIRpuika0syP9dsoTZr6X0O+FG1NgbfU9lnBxpJBwLAHUAAfyrKPxkV80GN5SAwBzxIARTo
gQHtYVwWCtV6TlIYhGk7mHFGbmWMyb/jx3UIrylZawhzDFLFHVv6lB+sq7U61gcWDpsDm6oR
ZRFZPVD53TeYJAFumBqwFEdWYmkJI1MaIXhCCvmOlbjmDIOlK9beMKMNERgnj9Eot9gYTZKE
zfL/uRhNC40bzsMxUb0c81h3HBPZzzGPfccxkb0c85h3HBPZyzGfeXFi7uWYx7zjmM+8O+8e
82FdREotnvrzsE/FUUyn4ihiM2JxQRx5OxVHvkxFP7lgP1g3kCsdHdlUyGXPyJUJuRIiF10s
qfBswpz+qxDpdsDzjdv9E2MroeIT+7Wk83ONBpGvGqWqw/Tli6D0YQGEK4Knqr1WDYyVY/2Y
wBedUZSqEG+KJYtQExpN1Q7w6wXKDXNWBzKm6F2O37BZU0XqAr6zQtm1q9qqbNSBfz6HSAjV
rLH6TAmHWsJiKSzd8BzIMW+bb0hwHVRYmyK14FqLKB0TtEM1mgVU7EzJOlwatFwaHv4Yq4cS
PISwo4t7fjggx3KCKIAb8ZkHbywdsUCjdlyM/lbQz1t3A2v1E1R7KV0tgv4lEFRFA2Y8oO4H
zGlAMxmwn6mhAS2UkjmW5+Np/5czJLDbIc3abugEhsZrEV2DMFNgPrRgyc23NDy/saArwcmQ
dgztJsS7xBsvLk8Fl7sMcbNtT9kP002KrF8f7XAc2OFZIUX3T2VNuzMJvuMdJaOU4EycUrJe
JGmRTjMCHGHYnb6MwKo/I/yb+KrpbRsHovf9FTrSQGNY39KhyGF7CZAFdtOiPQQ9OI6SqPXK
ru0U6L/feTMkTVkcFehhe4lDPc5wSA7fvIlb+4og8ExFiNv7iiCwXhHi5r4iCKxXBMW8HZnr
FSFu7iuCYu5ZNG7u76U4696U3vxqcvTKhPPZKhPOp6dNaH8y4XwCyoTzHpUJarWgPyOdG6sW
1f9fLQJpC84SLk9bCegGZE1PjDrNminrXzw/EArF3aAiyGfmfDANOB+/AedjaN1MhS5vv/Lr
tpY1b9/fHZNHFsjE9qgbhXl6olVpTfrKmz3J5xeEwoqzIUHK/78hkYgSM+ysh+GK4s64Swg8
PAeWIx7LWl81bTzEgw1tg3gQFJiZKxx4ZVAc4ZUrI7cAJrkVpfyemfyOZx/p5koppTR7TbPQ
HozXTEt/9paNwXcZggXzdt2WmQ+CeyCndLXdgQ+3NHv54TspzGF96i6kdbEk8Vz+srTOs3ZG
WltUJVLF2hGphXUiVewdkVpYJVLF3BGphVUi1czbkblKpIq5I1LN3JGMYn6+FwuVdezYp2Bw
plMwOLEI2M6AwW6nYLCXKaiSZVbBap4s698mrTmO0r/Yxr7YG/BOQw8X8o0kE2moDFIqRYig
oJxjuqrxTGXusx0mPR4x4qRlSGq+Hi3wyFsqwWms9uy84dk6sNOOx0sPEUkMass9tVlpdWCl
35r9DhyXGxn1i9w8bLvktEu68Psr/3/oUBHw3/rk/usi7O4aj41vRrhBeKHLaQy3AyBHkE83
8Dfi15ukPyavPJJv/QL7/yazBegSagQKGvYn8dVb8xGL+85kZTsTjpTWAkejfIGjc+LoCoLy
ccf8nJl1P/C0JfjUseGUSslxWrBQzZd1k9slrq+vQalF29R8CVdZVqNE3i1SWyFQhp7QxuS0
Al0tVsjrFpu7R1g5JTPI1Hz4C5NRazgJV1glnTR4ZUDmH/9GMlTm8yWDZ3UKhlEY3KIqgyvW
jsEtrDO4Yu8Y3MIqgyvmjsEtrDK4Zt6OzFUGV8wdg2vmjvUU8+BevFCOkLiGhycbw8Oji+Lt
PB5uPoaHu4vhOq1Tx7Zq5mm9+W207mhx46kSAb27Yjp4AAHlxDhviKSgTXlE3ERc3m1O/U6+
DMwma5BwZkgE/8DD92uCmvyDpYf/4Ytjq5WvJpmtJu/eruCSqR+xJw8yxJpZsGbJa5ayZmG2
CC9O/lN9H9XtLDQzChnnToRnnPi/JUVaEmsSZ5LiH/hrcq/wfpGdr9YSP5E26KlfYKUT/33B
rWX20yCDZJ08h5+/ywA3mPs5HxfEFyiuoMqb5HNypHAaqg8M7/e7gywwLgmT6ueL12tQ5Lpk
90R+JJCGrzmnKHjiAkkmFRHNAFEgrb4WO5ofrrbybURm24jtmu+Qe46UbgptUSWFMDWHxIJ2
fFqkfPYVPG+5wrXmqwwfZUrPU86pkBqZhZpajre+ClV/L1lqk7iTZN2PRuMZMjpt49ksiTxK
N+nrfFtnMxqKqDZvIWVyk6I5416N5M7Qy0rc8xk7kEbNSqbWbOTn5J4e/3CLZ4a1YFv5KNqr
Nn9iL3Ws73SPwD3FzRpboIr57Y8UXRrdWE1Piwo+yQxqT1aojcRtn5Jhym5pTkIB26VST7/C
bnwwe+v1n5gRMVxxYYSL4ndzbyRVGn6Rrpz/UnBltUyrWHA/ZoKryOelUbRLXSb3n3DYJWsx
NKa2P3WPQcKuKtjYsKsCAc+HTdViWVwez/m+nvXYM9SKSOw2He0L+M5PlxPbabxCJB6Jrqpt
GmQJvag6reU+IOtyEn+oMZSzq9zbBTqLZCLtT9NZguo6K27tdZbAMzorbu91lsC6zoqbe50l
sK6zFPN2ZK7rrLi511mKuVcicfPgXqgPEZS0xQiknPTYxDIO2gsVcPY+p6s6NO7ZXbag83c9
9e3QuG+XCILO5sHUtUPjrl2SCDqbIxHX7azrNnQ9mz9T1w6Nu3bJpbgOc2vq2qFx1/PofwMA
z0cOZAplbmRzdHJlYW0NZW5kb2JqDTg1IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVu
dCAxNDAgMCBSIA0vUmVzb3VyY2VzIDg2IDAgUiANL0NvbnRlbnRzIDg3IDAgUiANL01lZGlh
Qm94IFsgMCAwIDU5NSA4NDIgXSANL0Nyb3BCb3ggWyAwIDAgNTk1IDg0MiBdIA0vUm90YXRl
IDAgDT4+IA1lbmRvYmoNODYgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0v
Rm9udCA8PCAvVFQyIDE0OSAwIFIgL1RUOCAxMjQgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9H
UzEgMTU4IDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNSAxNTMgMCBSID4+IA0+PiANZW5k
b2JqDTg3IDAgb2JqDTw8IC9MZW5ndGggNDUyMiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiAN
c3RyZWFtDQpIicRXy3LbuBLd6yuwJG9FDAG+F3fhiZMp37Idl6V4FqksGImWOaVIKpFOJn9/
+wWIkgk5i6mZclkk0Wg8GuhzTv82n7ydz43Sav44qaIqVzH80UsVR3Ea56qo8qjI40TNv03e
vusyteioU6y6xeTt7zOtVt1kCp1jk6n5YoJvGbz9mHwObsKpMVEW3IXTPNLB9UxN8a0M1PWl
tKn5+9lcvbuYvZ8pFX6Z/28Sq2kBFhPDIJc0HKxCBjYpDzy7gKF1FaXBLMQJPt3+HhZREqir
28urCzX7+GH+x8X9e/Xx7v39xfzq4+1MfVazq9nHLzwHbLrkTSeRLuNCFSZKS13hjLQXN2PF
Ez7gagvciMZVX8Ezxvm+2Jc6nBZRFahVG04zaPjecMNGies76AkP5/kt1AYiIX4/8Uu7YXbQ
y8ivDCSWvfW3sdKRzvLchirVuHDagta89DZMYZ5NCG44gVrTdw1xM8HXhr9gNXBQlbTudkc+
K3F9DLWG1i1uBBaitmJveC3v5xOtWjUpq6iMtSoKuCMQVDWl330zeTxngutmSjaZLKrM0KYh
5sbjh7ZcHHUCkc+HVpOZCGMy5om2zLAtS+B1aEzi3OuINusIOzpxrM44VgfH3Jw4plnldUSb
1zEz/j2es9nDyGkLbDUJdD8JusfuQuuxuwj67NV5u4uHx+625rH/Nj8FNLgcBgEtKRBTCNAo
ZdJDygi8JJWCS56UWZQHF6HOIG/n0KAh727ULMzh2RDudGFJ/22YQSJwQqSBuqv3NWRUEhnp
15Od3/foEHHOmCjPYEknSWxSiz6IQ7igPxBU8uApLGH4ZkMP1bS9NEAu7tXXrXwq26x2TQOz
5UdgkaaHeew0ghRdiJMA6oDvon0MK9h3C2sugoZN6jlEVCilddnum0XfbqfUcwSRKKixttMk
Ms8GBiNAM8FaPbxTi3rHZFB/5We7bntARMAladjyow9jigK6q2vYZAL4j5h03/Hs8//wnFlh
5ywLnvO5IxzFPWwQooMlHShuED4IVQPpseBHjwaybqXrpmbLGhsZ11PG9TRw89OWHRMaYcIP
WzxBmAgPB1AADmeNu8W2hkdYq7rr2hVZN/QLFFHhVeOv/o06msQ4jorl2l4DQENAUuh8Dy4V
HCjkcKAWW7iMOAWEOYFHvW/4juRB0+4VuV2GCOp3uEHY29VSXF+JqgSkg6NEhnjedBSw1UZC
aYOsqHkTInNRXMW+kifH3w5Dk+okypMyV2UUl2nipEDiIitLeGj2cFVLZFC6/DBGVuDNwIzN
oOWJ85XuS0F6wQT36gemJ5x+z2bV2240OfgZXZzmZWIcUmDu4Ozrer+C228wBzGOsJfL0Eme
CiNJ3AqRQvT4ieeQ+PIxO5C3kVSpO1o1/yLKlEjH4IbkjA9iYXxZk/Eno47aLpdTj0I4bEIb
m48AWyZ45gcCFwiDfbOEKw68CDe8hN+rDhRWiSeZoqzhvse3/sXZ2KA+QDSAbVD8pMHbh3dX
9vIXfPkhpY5v2qn8sqpHRNBmJaIognFBQsKZ4y17CmOrltSWtFPPYuypGRNPNo8cPtnZrnFz
GWYS5RFcqhrxrwj4F8EPj6GkU8BfblfNd/pquHE6nCRNDlFPBlFPOOoJRR2cDnHPKe45x72S
JQMlJrke5ARwaJFx3HHUACBi/idKMcvuaY7E6FNbbPULrnFvp7nYfEZ2jfs75cVmv/gad3f6
i81+CeZxr47c/UJs3N1pMY+70yXj7odzEVNlXkquMeMgpi+Ng4iNGKszxsFuXxoHe3lp9Aqs
PE2h71mBlcb/vMAaAC0WeqJ8BGdhEYSbIGia9jtlHKZ5DlmK7yvOwWvO1RmkZ0nQYKhyimH5
z9QDgQAXg56eCi12JGoECBb1evEcYo24rvuGmQiAUbUbeulBw5HMYizjxlcQ7GvTA8GRuBA0
YsLHYk22SB8hgvhS7WvutBq0qlfgqxb8WgIjUPwDASp+CKztdts92vBkUugLLEVFZkqlJyiN
vR1nxQ/uGB1rgDTKdZq503PsYK8TXKZM56XcohT28BSirGjoxOi8UBKRbKzX6+0C43xK9ENh
/CKgEqClqheLZtcjfzVrgX2P7i3sQetY6PBxT6SE1ITa45swOJAUctdUMx1W7u5YXnWrMbIa
uhn6+GZUATdaaq2YWstxaj1Pq0dkcwj+gWxe8EwOIF7lPp4Rq5dnPN6WZ8Ts5xmPv+UZMXt5
xuNueUbMXp7xuVdH7l6e8bhbnvG5W2z2uA/OxbFQVoxGfsw+jOyYfRi6UXt13j7c/Jh9uLsx
u5d8shKjfp589D9PPkMCKF06i/6+eiSFzchfWuQvj/PbBNyo5Et8JNsNZ7t+ke1Ok1fJMOdz
zPkSB8Wcx5eOajRbzAGs3SIsfcKf6+tjODZRohNbkmmuCnE2bXX/AI+fQsO4ppEzAY8NwvMs
1IjP98CdyKAJlqzP3LPjorcPNSnvDbduocgqXKOnRpsehzcpeTVN12OQMHjrtnsKMVqqVl3T
dRhabN9w4xHqOo1ga7EfuPZESsZKjgtgVm34CYEN2hW9s4VORgdbfjxT2/7NSPHHR+UmrATm
H6mIkbpF4wJ/YAAyJIuYFMoUJcgCD7AMnnyC42+lj8I4VjOHC6UjpHWgLs0XCl8ULQ+zaIrV
DN0nGPYTP+BOWQecB1QIseLgEGg6404zk9Nse7gwOodwYu+uh3OEqhIux2bJccBx09cl0qx5
WdNtRStx1cc66E9cJaTXoofC7O3I4Vkpt3DyDoe/w22WEBSEDMILLdIqpcCzGCFBWUgvUBS/
rBlRNqEOXLFW5BCqW9GIfYvokAYtCJ0x3SjMjtxfZtmv1JGZn9yzc8w+5mdpPTvL6WOeltCz
c2w+5mipPDvH46OO1cHRy+Bjjpa+Rx0tu405uoBn6MRWDZoWup5E1tPhEEBPh0OgfB2qVzoc
Nu7pcNigp4OXv9NCR/ErxaP5V/nbuGSMk0GuA140e0xoTfyWEr0hvOB6VL1v1ILgBYCKfhlQ
jjAqdQPnDqgxjZct1Gz9+idWmkD5X+0LgQpsouZuMBWog0fcJWCYNB7BqdYWp3Qqa7+A0Jki
uJGaRD1QiQI7gqGtt+V9kGI5cpMQVurqsCI/5f1Zw+CPoExyo0UWwBJDXc/uEcFTWDkUibju
nm0+WrehXrjw41xd0zMDw2njeEglNeJgHvwlMd/Qc4n4d0IH2oVay9K/YUwN8QBSEp6nerhD
RimCK9VvkVMgvDE/3/BEuAA6+ePBHZFrUQ5wfE37PSyIs+FW0QQVgHfhSCChKrUMkHpOSTCz
45V2rSSmIHoUOxQlSLb4XG1QM2gk5YryYMpSha1PobZNMsZppWfyX6KDtIQL6GUEsXpJweNt
eUHMfmrw+Ft2ELOXIDzuliPE7KUJn3t15O4lC4+75Qufu0VUj/vgXOJBuZS/DPyIeRjXEfMw
bmPm6qx5uO8R83BfI2Y/T8D1ZVgQnigPPCFpAhDneOIDqZ/7kITpTEQTSutOoJPkEvBAJjxR
Dngil7492fl93w3gdUAUQ1FoHJ7Lim6msACoC9r+jUIFWAY7hD4o+Rag2CqBB5DebCSAJ82Y
BPtViFVaM6IQp8cAmQiyL+odpnoScPEDhcu67dumU1v+fGSQ6+oNKWD14V51P3C7UMX0iydq
jHB5yQA7B5CAiCCIl5pD8KUquPlvrG4aWLWOadkbftlyUdEDPwIsdWHBOIam3W6753aMMOC2
mxVH00ej/YqjZS3YR4FAfAnUogtduC18RlibAvCl/ye+anobN2LoX9FRPjjQ98dhD0WMAgFy
WCRFe+hJsbVeoaod2M4W+fflI2dGI4WjAEWBvViWOJwPkvPeIydy2ybcp7CzB3VUoEUThDqx
hqFO93ZQJ+YVqNP9HdSJOQx1uruDOjGHoS7g3s7cw1CnuzuoC7g7SNDdp7wYU9V+iPnC4kVz
YfECtbS0IYt3vIXF2/nCEsSxvEDukmINx4qfgGOr3eduy04v0lkCzX6/jw7mjTUdBOu88+yk
RyUMet+kzZ0T2ckMNhf4knzYi9NCWWn28iXBMiU0WcbyWF6xj8zbR8n7KGUfRTxiy75qSxo3
c+YBaEmTdC/yHOzmW9o8Wg5gDiQoATipuJaGPFNQKT/RnsVnA4Tx1shrl9zEylhCspyQrCU3
C2QFBBse3/lzH4lZhvYs8Vmcd9GRDQMP/iGDN8DXE/+fn8+p0syo0h22nMf3D1F3pblGOSYr
xJTi841yXMVn+XaJjNG83zbQvzg7wfg4nPjPX/KqpBXVjOX/ZDXOuamn3EAO0+lYYA/4z4No
GwlN9+r9n2z4h46IZf+dQooKU3HcXc/SmiCADOv4C5R+Hqfc/VAl0THeToPU74E/mpcL9zOs
rCHe9/K42drnx5kdTp3YRvmIzgor3aP+lu2IS41feVJ3turkoNTvguIo8bWJIrUVfngizmqB
rHJT1KDgYTRTzOuxnerRxKN7fe27SzRwNk6sSVAb/Nptsvill//QJhlfaxCwP/woTlykXD8Z
18+sFl0W0PNiWS6rgq8ooZRgScEnzL07bAeYiqu44tD0+saRr2i96F3R7ZRl8Z9lQE7tUEAD
wBQUAJqfZX/YwtSveVrehy1I+pqjZXzYgnSvOraTY5DoNUfL8qqjJUrN0QWcncSaFrznRWQD
A6YABgZMgQoNaD8ZMB08MGA6YGBAUBCkLQuC1cam/MmNTeEam0p29AcuIPgArgTOPEM/3MyH
S3QmAjmb18h+jl77nparYg2/BQ33Fh+FK7EIQWNhG6aaG6ZaGiaa520D7mvM18Mg0LGds6Hg
ncPc3MyONqgFWmYiDkz/lJr+KXX0zxKjEi6smAsTPjvcSQaAR56ZhZ+u8zVLJ6Qaw/5vV+aR
yrINc03Kx6IX5prYjNjL4yb8ST9nM1R4pmKeMSxTCMsUCwXwQTv9apTRBSmBOOqtCmDKFZ3U
Xa/Dka0ioJhWcmQZb6T9ZotkDtoTA+2PRAQUkIIGP7FAoIyTUor2Z7S3tMQrmswi7i69VAZV
5XCJ2G1HcWzjrzggne3hYFw/KoxAfE1orkJCFOQrh+54MkG14Y4GkSFg9psRHLAfzVMyYaeZ
EUtzl9TQxbtQXdFdLdMKjATJWFJdSKn081qJ/sGNhJo2lXSzw3g54reMSGtxE/NsInCjHcbu
cmQp2ksMafe7DYTxV1RGiygyd1NsQK7vyEEeuoFl6ua3qrEDPtSx/AJYGmJ8Wial8PEjOps/
IxvfcSzK2flw2PqFUhQTrhX2BhI+FSSG+fG3OL70l/4Q7TY5LfcI9dNQcWPtB8pWin0stJRL
QGokDSQl9kUBxdPUOLQ766aGavzSyZijjJDPd/68aem0e5qZ6vrtO4LHmjsHrp4ZZ0gaV6zd
fdvFSPbHTVbc4TqkKKunTZbMd5+53TtBBmirY/kFriHeDYe74fPje9T/4LdePm51Cf6/h5xI
kHSTdwWINmui9El6s/aeVBR4LaCiYAqqKM3PqijYwipK87QqCragitIcrYqCLaiiVMd2cgyq
KM3RqijV0YoMzdEF3NMfbYrwLgKr26fw6fYpSgF7u26fzqzbp6Pp9rB8SqjmP5FP1U+QTx6o
pq1DKIOpvwAkCCNJrvQDNXQ0D246OqqaO6papAV3ns8bAMqTMCHtI6E9v/GIK+/jxp5z5nfE
iGsqHea4f+Pjjt2tF/qno0fcVxGGkS5zXVcey8c571Ebmua5O5OjfYssc9oD6AF+K6Y94lKc
AoKAqa4bx/Me+1hSnS8GPyKjgN0h6vb7/vUGWO9Hg4ez0zfu9IYjv5Ejyyvsgc+YiaypYglF
Y0PRmFBsfbybjv4Z3qWUsSqEeGIMYp7ua1FPrGHc070t8ok1iH26s0U/sQbxL+Dc+s5BDNSd
LQoGnC1Y6M5eKlKLJDmp0Wpmrkt8CfjqRpNGMa6mUVvX2vW5bZrFup5mbXZr12e3ZSDW1TLQ
Jrd2fXJbJmJdLRN18nZ18taffLWMtMmtXZ/clllgcr/MtMmtXZ983frvAD9Dl5AKZW5kc3Ry
ZWFtDWVuZG9iag04OCAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMTQxIDAgUiAN
L1Jlc291cmNlcyA4OSAwIFIgDS9Db250ZW50cyA5MCAwIFIgDS9NZWRpYUJveCBbIDAgMCA1
OTUgODQyIF0gDS9Dcm9wQm94IFsgMCAwIDU5NSA4NDIgXSANL1JvdGF0ZSAwIA0+PiANZW5k
b2JqDTg5IDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL1RU
MiAxNDkgMCBSIC9UVDYgMTU0IDAgUiAvVFQ4IDEyNCAwIFIgPj4gDS9FeHRHU3RhdGUgPDwg
L0dTMSAxNTggMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M1IDE1MyAwIFIgPj4gDT4+IA1l
bmRvYmoNOTAgMCBvYmoNPDwgL0xlbmd0aCAyMDcxIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+
IA1zdHJlYW0NCkiJnFfbcts4En3XV+CR3BrRBEiAxKMn8Ux5K2unLKb2YWoeZIl2lLElFylP
Zr9j94O3LwBIKYBqaysVE8JB49KX090/d4urrlNCiu5pYQtrRAn/aGDLoqxLIxprisaUlehe
F1cfRi02Iy0qxbhZXP26kuJ5XCxhcam06DYLHGkYfV/8lv0jXypV6OxzvjSFzD6txBJHbSY+
fXRzortZdeLD9epmJUT+e/f3RSmWDSCqhE0+0nZwC7exqnnj1TVsLW1RZ6scD/hy92veFFUm
bu8+3l6L1f0v3T+vH27E/eebh+vu9v5uJX4Tq9vV/e98Bjy65UdXhWzLRjSqqFtp/YlK+hNL
yyc+9sfvudJwVt/v8xZvfvxK314M/abf/ck/8rJQ2VYMa170PJsNz5OF1Mb4s+oKzyINyooP
A2FZwnO2Ypfr7Aj/R3iezQR/3hl9ezsMiPWgghrWvsB4TePHHsd0CVr5zB9eWPA9QHulKcH0
J5cp66Bqw3c57g75Uhcm2+cGpMXL+pF/92ABUMcLHYPQM/1103zITbeQYicWrS3aUoqmAb8B
RYsl/R36xdMlCFxQtQyB5q2aY1KaQiXkEDNOUFa6qMwcVVqBZ8clEdOKMV3BcA5WpUkKIuYF
4UVngvaCoJ0EjToTrLVNCiKWFNQq/cZLmDeGoScwqipYfqb0BB5Um8CDBlO4vYwHfSTw8LQE
/nN3TnLgHApJrmrQ+YnkKCbbKSZbjoO6EeDZVYuu/wt4epM95BZpYEU/MLYshGkLIcB/IXQh
Dg4UgsB4n9fD+jWHyxi39kg4jwcW4aBRhdFwpzOaKNsQmYpvdPsEQpp4CDm1F7s9DY79MPYb
F7cq40nhfjkZF8WKw1VCFM/Iqa7pVHq+qfyx1pHTABIlvGKdL1vc/rnnwQhkRcQwAuuDRsRd
vmyyL/jn0yfHOfD6qjVCFVUplXuZ1I1XtlQNnwGq1tK0sEv3NVeS9AvCmDhyVcN9V7ls4KiH
XJWZeM2rGh71zivHHKitAvVK4qs9zx7AWE2YpNvoolaymet5earoypm+H4+oLlTjy278mqPe
xFqM/TiiknF+z5M/KtHnkE3IK7jjd3xFle3IdNaZ0IIJ9/wFFWe7ZxozQtaS2YE/7zQ3/BTJ
KGy0cKB16esJJCV5GnwlXvU7qkLD9iBhwVnhGSrboCnb7Ctv3P2Nrx+SoXK7kaPJU0ezGU96
1+JXoMrCZnS3RrndZKkmh8KUAQ6FAUUORZFFl8Lct8SoIX+Cbb/wB3zKC+A5kHQxPIMR/HEq
WFM7a+6O4DDSgBJx9XgEO+bLGpxjv+XX4774+0QJP1YEq34Eo6O/4d8dxHGL0U6lwYNLhZj2
v+EtIdA2x34rrhIuokKYlS4EPuMzW1AKsFhG1CFdJVGT4nNUMYQDxGLjVkHaT9QYZRNM6KOY
knZDSbthU4Hq7siUEDy7J+awzdqZt8p4PR8ANFwZKbCqaDXVaUDcjeZH4AEZFHPdN8z/PqXU
Btk4leIZTWf5uHRI9AxfyPVx+ZDuGU5n/Lh4SPoMp/N+QtyeiKezf1w8FAAJ8ZAM4+KTXRwk
ZY0p8VzvEXSm1Qg6U1oMtZfQ2ZMj6OxFETSZ3A1EjjZTcq9kSO6l42PYKyT3+z3ndarq347i
8OQy+L9z4hcIOWIrjDaMIktlvqXglIF/4kncc58/d+iJHSpkh/+IfhgOA6SAFnm+piDEpMVB
iNM/YV4QGPqGmAC5r0Xiq0/JSoZw9x3FcVi/IatBi3Q8uIH7uvkeE4ECXvD4UJwSYOjuStfd
faDC4oVo9DAS+ffcFGkccAuE9I0I9irCzWyxUsHBn/T3gPyusz9YMMfa4uTkamqQSs9e/XH4
FzIiPPxtOGz67XuOasRUAmefFBt1YZQhjoLU2TjVuDIDrA48VlNJsLRlFY6eiMtUEuvHBHE5
NElcCWlPXA5OE1dC3hOXg5PElRD3xOXgJHGlxO2JeJK4EuKeuFLiPswT4sEuJUS1QzUUg+eK
j8KTXqPwpLc4bC/C07uj8PSuKJzkL20qWDprTszUnBjHX3bir47KKQmVHZXpvaCuo4YaAavy
v3gWm5Mqc8g7z7lfYs8/T2cf+4GYUCFznDPcvGGYOK5y9d1UJyuqk4FKd/yFUgwjedePgif6
fsvrRqIpHIlH/vbYVcgsWfJWs7jecEfCNS9ULk+uM3l+982L61m2bkXBLJzqUibi+N84QzeK
LBnnDIcmOSMh7TnDwWnOSMh7znBwkjMS4p4zHJzkjJS4PRFPckZC3HNGStzHVkJ8ZpdQCkHP
WNc/aj6GzzUbw+eqi+L2Mj5/fAyfvy6Gp6lDtaH0wTCRrW+HlHTtkIa4qiH0SvedFUIwAq1T
f4XNDUSVKrlZoK94XbvRX24FhJnE/uf13U28Cgg44A8ZhI5uiZ/3Ih6HZk9qDHsPhIlLZVWo
d6YCYb3BSgRuu+WaBEbirQcW21CThjdBXhsOL+Lx5bD5g+ZO+14bmiZXru2YljTy0CN/eyrJ
hv6lX49IXjpw1IxGJJYw/2f9oav2Qv3h0DSXxKUDlzB8gUvi8oFLGE5zSVw8cAnDaS5JiNsT
8TSXxMUDlyTEQ7TFxYNdmimLQyxqcwqDJ6YkI5A3J0AXbBk/MeCRfYOhAbtk5fjOAY/sHFwA
sAv2j28c8MjGwTkAu+AZiY3thY3ttPEFn4lvHPDIxsGhYhtP3hTfOOCRjS9hwPlXXQd1gOie
ztkfOKsGlqwttGa+cETaAXLpviG3/HcAN4/nggplbmRzdHJlYW0NZW5kb2JqDTkxIDAgb2Jq
DTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCAxNDEgMCBSIA0vUmVzb3VyY2VzIDkyIDAgUiAN
L0NvbnRlbnRzIDkzIDAgUiANL01lZGlhQm94IFsgMCAwIDU5NSA4NDIgXSANL0Nyb3BCb3gg
WyAwIDAgNTk1IDg0MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNOTIgMCBvYmoNPDwgDS9Q
cm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvVFQyIDE0OSAwIFIgL1RUOCAxMjQg
MCBSIC9UVDEwIDEyNiAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSAxNTggMCBSID4+IA0v
Q29sb3JTcGFjZSA8PCAvQ3M1IDE1MyAwIFIgPj4gDT4+IA1lbmRvYmoNOTMgMCBvYmoNPDwg
L0xlbmd0aCAzMDcxIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ5FdNc9s4
Er3rV+A0RW5FDAGCAHl0YmcqW46dsjTJITUHxqIdbmzJK9Lx5HckP3j7AwQpG/BM7extS1Ui
iYfGRwP9+vWr9eLleq2EFOurRZ3VRuTwo5c6z3KdG2Frk1mTF2J9u3j5ui/FZU+dctFfLl7+
upLiul8soXOuSrG+XOBbCW8Pi0/Ju3SpVFYm79OlyWRyuhJLfKsScXrs2sT6ZLUWr49WJysh
0t/X/1zkYmkBUTkMckzDwSrcwErzwKsjGFrWmU5WKU7w29mvqc2KRLw9O357JFbnb9Yfjy5O
xPn7k4uj9dvzs5X4JFZvV+e/8xyw6Yo3nQsLAxS5pMloHpwiEen6XzPfSEVbhoe0dVYadIy2
mdbsGNp/rsZl4hsuU1qRLssyT442m33b9+Jdfy2E+EWIseFjN3zZ7JuHdAlOAZRWd7JeSNGJ
hcplJo2EmdAfQkmdmUosZabEvl1cLV6tZ+vSsswq/WhdgQ1Vzx52UcIUbMsWOc4nS2PQP34Q
mTvvZaosYBB3UNrifOQM2Dq54KK9Sks4J7FqLwd66+h/txVFVmal+CWF9ZqEvszj01nyBLgE
rc3zR5Rnti4VuUdVtb87NRokq5uMuuParCrmm6JetPBPydkOzgvvEa2jymxZi1lPGorHUU/G
4RiwPgacA9ZtuoRzS/ohXdpEvG7gqDOb9K6ZZ5IyK21VPJ5rtk+cqIAIezyhrHjlq4Hjqb3r
eUid1RLWcLhP6SNJukg6gdOokz9SPIM7OKJ2Iy7aHhpVcp/CmSQ3g8BQMwV0O//MyL79Bv1o
mjqrCvnUn3JaPgx3j4PAJsoMLqd4tAPuizflNlXQI2l4J/uvqcRJ3X4gKKoaLieEg4RboUWe
aQgG+qdoeB6FG06hxKgyGV6VCZbSPGctpZ2bywKOTs87qFJmVR61V6XK1DR8WWTVAV7kZj7+
Y3OEjfYw7FQd4jUcooqbA4XraXF4lGaOa5NnRXx2hKtpdvqa46WSz/nuT+Dx2PIa0oxDVQF0
9OhgIrh3fAT3no3ho+siuPdNBPe7i+Cv1nHSBaZRQLrGWnCMI2zkkMLnEcchkkIQd5qcb9MK
COqyfSGGL/TaitMUXGuT4xSWgrnWYobtKbDbFFaU8Dv/d2kB5EuWouMmDjCVwQlVkUjGZdW8
mLYfms9Ik3Vy0/VfUmIdWB9MuuHmF5D2cdjBgeKsHR5ShWyy4x57JD+VfCWcp1//Y04H+FZI
nrDZMCG4B9lqWEbf9mLHbVfEXzghbVo0NzfTxzj8mJYcARY8ercFW5sM7f4qRUHRXBL9jd6B
Z7P5Rl1gkzmS3+AAoMB7AvjTDXRN/17KTJmLdlfU4/zGufMH+EAlR2ClcYdwM8bHHjOFwmkh
syeoHnCzxdTQ8Mu1a/jJj/nUs4NUnvpzR/1rOLQCnIfXyCTtvsUd42JEs6UmccQMTFqFEIcD
UUs8gjSn3U9IQy3XPCC9H3hf60kfuEXctXuxxfuLw6GUQ5EgE7gueIt3mAQQEzfU3FCX7ymp
Su6/dxkUbpcxhTAQzdbipiFR5bbyeehTAvpyWZQlXjyMp1wqf/mm5GIqkLsqlj4cGk0fEesx
fTg4nj4i9mP6cHA0fUTMx/Th4Gj6iJm79OHgaPqImI/pYzSPpY+I+excfPaocvT/E8+H8Lln
Q/jcdUF85psQPt98CJ/vLoRDfghnhbI2B1mhKH3s5K68UlNaeAchC3UJUgcGRTOkeM13++8Y
qRDJd82+ucWwQfrAFu7A73vR0VcPJCQp+nGoWFaI1Ho/iIKPIPQpD1S8GHzsueZrmbeBx067
fhDIPkhvp8TSH34ymiGHlYesIX1dhWL3wcl0jVTnnnf8GDr3jUyMZLREBroRDnbf5Iic2Zx4
vxfN/lGWMDPagDximR+zQ6opMm1qKjRUZmTp+PxDu+8wkxRAU1ChWqIdA0mAtrUsTK6Qzx7T
Tl4+RzuMxmknbO1ph+FnaCds72mH4TjthM097TAcp52I+Ug7DMdpJ2zuaceZR2knbD47Fx+2
2mR5wPMhfO7ZED53XRCf+SaEzzcfwue7C+Fx2tG4caad5cQ7pFhcpBcoT+gyO/JBCWNIwlSs
XcrxsWcxSgKFQv82leUoYfQoYbSTMJoljEbpJXrXtB2eEJETVLQ6M7Gi4eV9bq9SKWGSHXKh
hmJV9MQHSHY2QXIzzJM6Qd4rXNM1/aOYRurArp/bG8LBZf++J7TlkQZuDgstXU8ix3HCbo/D
FmDTgPrGYUuc6hY1saW2u7uO2kgK1bAWeow9WujRp8il/I8WrssEHZITMD0R5/GM0P4+TZVl
Ddc2RlMOjdJUxHqkKQfHaSpiP9KUg6M0FTEfacrBUZqKmTuacnCUpiLmI02N5jGaipj7cwHF
XTkU/Kf1Y8+H8cmzYXxyXQT3vgnj0+bD+LS7MB6nKakzayZ1pHzVmLsLrid++shFJ9Y5UI1u
+fGNH3sudkD2dPx0hWCFhSCXgDYqhWhm7Wd2BNRcDh2ODrXk0G5eYCGKH6243O2pkErudltq
2nT8vKZ/L0GWE43gm3U72rYspAaUMwpKJIlhv8NShqtFuLnJV9Fwr41r3xzibgyg4o6H6QFH
MusdsnXDjzgwEolCh/LXwUr/Vk0LCUETjf2Fmvap8PqfcpvSU6p8ym2MxrktbO25jeFnuC1s
77mN4Ti3hc09tzEc57aI+chtDMe5LWzuuc2ZR7ktbO7PBVKgiUuwGD55NoxProvg3jdhfNp8
GJ92F8aj3KYNhEg+cZueNI50FFNO5HaEigria4PUUlFA4z/SGsQ9KB0R6/GcrlK+5spdzfWQ
KhQoHbGZSjb7xrWgSAEiTcEbCdJl5f4barlOOd7xneosBrlhS+CQKtQ6T9XUcqwveSWV05/3
fefKvGusIsHNKnmNLKaS9/CgNUW0EIjh3Faz4g6ZoShLIjwkSqk8vU3MoK2dstMTZnBolBki
1iMzODjODBH7kRkcHGWGiPnIDA6OMkPM3DGDg6PMEDEfmWE0jzFDxHx2LioueiLw3K8BeO63
EDzzSwCe7zsAz/cVgOOUUBRwPjO5U/jwtHyRzSO5Y0nuFCx3CpY7hZc7hZM7BcsdmU9qByJx
0y7/VPD8H8ocT0SmnGTOX6x74UygJi2RPg+7NNzlAYUKFXzAX8Vk6OBr1/CTHzE59F/Sm1ZT
gnpKb4zG6S1s7emN4WfoLWzv6Y3hOL2FzT29MRynt4j5SG8Mx+ktbO7pzZlH6S1sPjsXVcWF
TwyfezaEz10XxGe+CeHzzYfw+e5CeJTlispkVs2Ej5yEj+QLbSeaewu8hU+ndOBen6Zwv8tk
BdRzwVSz2QERWawAXB+kEYizIUX9IBi7Z+jubrd37fz4wu3tc9Vf7klBOVI44lVtMFLL8QHB
XuDAb5pbDPQi6W6+I6+BUunvuEt7CTULyqEuRSXTOkvkaYNPoFd8tnOd5ATbcpyfV1L6lVS8
kIoXUvFCDBOTZmI67foBVZTEqU+J/z/E1FOk2vvgajVX23W4V5VcfcfKjnhHQe0Fc5+uLkT/
ZceF4H2KVHTjykKiZRxjOzbQEoDrSvvE5wE9PIpd8QMntclvKURs4hpZ7t7zB58ycywcKcjj
p/6kbVo/yZhiUUc7FW1J6+K/eJOi4GxSPHRQwngBuxSde0P/30EcYx0bk7e5F9qF4mnOdnhG
IIvhPlgc7bIZOte2JfEsBvcpuqE/TFJmHM2dzekx9rQkjA3GCGpn3P31tvlPn+WSgjAQBNGr
uNSFIQlqZu7hBSK4EVSI9wf7n4jVswry6Mo4XelqDqBKx5Tf9jBKm7Xh16Ffc1COuYmX+7K8
ZaOg/N3NN7pZtml1k9qhhlJ0Y3h+ZD0faRE40pda9p1s78VeUDv22YVmzzTx/dA/HKq4jXPs
+thEFs/nMUsshWlg4VrPK6V5XOFqTyulaVjhYs8qpWlUJcWWVErToMLFnlNWnMUULo5W0LLp
tPR86T+YG57WQuhtFNhoI35vcKgdbRbaajNWDw7VwwZCGzbA4sGheNhEaMMmibhzLO42Etqw
ERYPDsXDZiqe2wyLB4fibfq/a9BAOvGu0Z/XXUNnjI2YL7UUgkoKZW5kc3RyZWFtDWVuZG9i
ag05NCAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMTQxIDAgUiANL1Jlc291cmNl
cyA5NSAwIFIgDS9Db250ZW50cyA5NiAwIFIgDS9NZWRpYUJveCBbIDAgMCA1OTUgODQyIF0g
DS9Dcm9wQm94IFsgMCAwIDU5NSA4NDIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTk1IDAg
b2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL1RUMiAxNDkgMCBS
IC9UVDggMTI0IDAgUiAvVFQxMCAxMjYgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgMTU4
IDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNSAxNTMgMCBSID4+IA0+PiANZW5kb2JqDTk2
IDAgb2JqDTw8IC9MZW5ndGggMzk1MCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFt
DQpIiexXTXPbOBK961fgtuBWxBAgwY+jYztT3nXilKXZOaTmoEiUrF1b0kqyk+wPye/d7kYD
pCRAqd1KVeYwlYpJ8aGB7gbwXveb8eD1eKyFEuP5oEmbUmTwj16aLM2KrBRVU6ZVmeVi/DR4
fbkzYrqjQZnYTQevfxkpsdgNhjA400aMpwN8M/D2efBRvkuGWqdGfkiGZark7UgM8a2W4vaK
v4nx9WgsLi9G1yMhkt/HfxtkYlgBojOY5IqmAy94Yl3YiUcXMLVq0kKOElzg1/e/JFWaS3Hz
/urmQozu3o5/u7i/Fncfru8vxjd370fioxjdjO5+t2tA0LUNOhMVTJBnihajdXAJKZLxP9EV
lSpTlgjaT126lKYswEPrItXoZZWbtNE2V+iuoowM3St6rmqRDI3J5O3kU5sY8PlRvKPnJFEQ
yWazXC34i8V3u8miJa+vxwMllmKgC5PW4HGVF2kJDpi0QEe12LaD+eDNuOdaXqmAa0dhdtmI
HAGIT/ER8BYqcwnEHBVF6XaryLugcxv0fTtPjBSjdrqH5xL+r1ciT01aHe0GnI0cjLLQZgwZ
PLMlWVo1RlMudN3449PgTHL0mNp54FulD+ahURWO+ijfr2F/8CiRa3VamUb0RtJUdh59Mo+9
BpW/BpUNf9wmQ9gpudsnw0qKy0kyhHnljj/blRTsflXnx2v1EwBQDpfseEE4UuT5aG+vVLvZ
2SmLtFHgw2Gcyl8mxZfpGo5ZI7/ABSrlBraonYn7dgcftXxOYJfk417gbStzGHb3ySLb9gXG
0TLNyb5QPlXnPkz3jJNAELDnRd+lYTcWz8lTAqe5grtAkWz/lShclOOB8183aVkrUTaQQDjk
aVGLIf2lo38eheOsSo/qMsWj0sFKleeslar65grvXtEfoI2iWxmx10anupve5Gl9gOdZ2Z//
2BzhsvAwRKoP8Qbvd9wcWLzonMOtLPt4UWZpHl8d4bpbnX71caPVudx9B+5tGxC8RXUO3HO6
MSG8n/gQ3s9sEO+lLoT3cxPC+9GF8DfjOMMC02hg2LKEU98TDu0vacaXVNEVxEjl2/VW7B+S
Gq5rCytM2+WL/ZEA/8mZeARleQTg38/28y4p4cLuX9lLpNNKZfXxbVXKs0JjF1zOwRqUun0B
YgBS2X5NQHBhngR9eKCPS3pf0fuC/orlTtz9/ZWYoBdIbw24BVtdg8zR8uO/2itvcrdgzSLx
hHfd4NWvYJkNhKuAht1zabkStJHfdgBAuAJZFA1We2bTFNnV8TdOWZa50ClQVI7RAnllVe25
6aOEsmOYGwMSLjHHmdIYxzHhVGAXZRQC44QStPV8QugZOglaezYhNE4mQWPPJYTGqSRs7JiE
0DiRBI09j1jjKI0Ejf1WFB2JQNpMeZzuMN4lNIx3OYvgPi1hvIs8jHfBhXGgiQg55BkYduQQ
KLB0xw43q0SBI3LWblr3aq+K+4k1mLgkblhbpAds148Iv5tAIQovjCzs44RBemWfbjxlKevU
N/EbllJKIlc1uDw+xISftwld7FFSgNf3Cd5hZLP1gmA7aAn1Ryn/QxQGXk18h3BUQJjCswnz
5YpoIZefEwUk9vY6GTbyUrwQeVSWZCCevf35AMyJ/Gk/ztfEOYXcghGgNAVb8KcZj+DpgJUc
udGu+HbF+rJHKoQyKqFdeIUZoCkgIuBx+GTJ0liqbHpUSen0bZXmHmKCtpCPF8pKi3sIzu6X
OyifgKNzTDUie8G/13Y8m7EBUvXBOp6RNdetV2SHCQA1w1NSYjuy37YTmhdY8lf+xgMfl9Ml
lI/2x2FKqh7jTmaoKZUNV5Pntt+B6i9DB1cE79NDDi/h+lWV3/NCO38rzvM/Wi4bUQGwzxii
oMy/2iISroguFdw3OabesYFtxwvDRuJ2dE9igj9WuMHo205wKWpdgU4LivTjo2+0v5CaXbnF
NUs4NTnEBXJMJTZshy74G10vOudwkDReMEUCFDzfqu4L1hNKnyGjIYhVLUHxNEbiyvEMe9I0
xwdMAOKvGtsCCSrBe6pWoIBFZc2icV0LW3ths/AZZQvbe2mzcFzbwuZe3CwcV7eIuZM3C8f1
LWzuBY7NowoXNnf7kuOT0TrD/B9mPoL7zEZwn7oY7nITwX3wEdxHF8GjEmeK5nsSl/8BJO6k
KmeJKySX4yt6WIkrrcSRwBkQuBIZ4KRct8V5UNlwobz2iQB/aM17sIZ6HLirkVDiN0hhOyDM
AoLDlZBlNBXI+G1BA8Qc+cUgMyLBrnkIOtp44mCq1rWPksnsmTqBDdKpJodxKaRWUgLccyk2
bbvFVWh6O3ILUb29vrR9wUHxn1VuiZylZoMsW6F/QP87yCPqwV4s7QvKJAkEZBSVYZQgWd7/
BZer5aGMFUV3dHiXwC2s6ekklHILclaB2WQ7QwpW9gAU9gAUWBPgx0miIZJPj/SjPVIikLcK
O6Y/lehHKZExzRklYjSqRBFrp0QMx5UoYu+UiOGoEkXMnRIxHFWimDkrEcNRJYqYOyVy5jEl
ipj7fak7Ji+b47QHwC6nAbDLWAj0+QiAXbQBsIslAEZFpwBl0tlZ0Sl+rujY3sbX5TV79Y26
DzC7wW6kBH7TlrigGSmpmalsMwPXeMUvXxgVD2u23rhZ5u7L1k4nJmyLXRN2YZcRcTpt+aa2
1eMWz3ZyoFSS+7f92nV/6/2DB7euFbyCOLT8wKujorw6pHbVbRAvOKFEKjkTj9RHrtebWbun
13Zqn0sL4I40kocL+3FHanKoTWXeI7gpJkCTMdCYXM2XKPelXDxviZapacQRMx6RYgrdhjq5
gLyrwvwpFz9OLoq6V2CeyAWjUbmIWDu5YDguFxF7JxcMR+UiYu7kguGoXMTMWS4YjspFxNzJ
hTOPyUXEvLcvmkFTBRMfgPt5DcD9vIXgXl4CcD/uANyPKwDHxQMKaF2cFQ/zk8Sjx9DKa4eq
vHYUyHk386Shurqiunqy32+Xnyz2TN/2iYZKXKztNxo9QR7IqDgeIvdtLMaPJRisyHRBfw+b
igNWRe7PrUrkpBI5dUOFTPs84ojKMgASgCPU3LLZH4RQe/n+0YTKovT/0ajK8+/RaA4HTUdp
1KJxGg1bexq18BkaDdt7GrVwnEbD5p5GLRyn0Yi5o1ELx2k0bO5plM2jNBo27+2LLhgtDLpw
kvkQ3s9sCO+nLoj3chPC+8GH8H50ITzKpnllwPGzbFr+fDbtc9i3iwQYBEpCJEaqXws5gqKy
kfeW/bbttF2+JFTiprYChtLacigGMaHP4ALOsMBZDstQ5Tit4VJ3bkvOgqtRJZ8SeFRU9wMb
AYcNkZuxIJVixmPc2M+JQq9WOx7s5qLRE/zjZlvRpy887rD+7thNMbs9JESO682rJQU/x0xA
LOIwmtMeZuWaDvHsGpEdtyjchnDjws3IE9KoQeKkJ3/dHPUySzvDaiEeeMROfGKM5+PHirqk
Q40yvp0x6KScbtvJvp1Z1syOi+dAN+J7EPG/NyHTNX+mFDqLhf32bB9b3GIIYSYiHVlWuRA0
5xkUvsSL4RUebhxMh9/2CR5aq/H4dQ73paCawFpAqhubamVTbWymDSUabVc0ckF/j46vP718
Tmg7GvnS2qeY2ic0q5Kh1YIxOrvUSfX2x1+9w0oA72xTdfUOrauh3zKNqwS2SyhewOWvGE6F
GjgE8Uf1h7e8zLQ/5p0w5rVB2YgII6NRYYxYO2FkOC6MEXsnjAxHhTFi7oSR4agwxsxZGBmO
CmPE3AmjM48JY8Tc7wtcCgYV1EDZSebDeJfZMN6lLoL73ITxLvgw/l/uy2W3iSCIonu+ondM
JIime97rCFZIEWGRBSsjT4wlRBzbAYkPyfdSz56xu2siBQkkNrHj6qrp19xTd1pdPm6CMUBh
sBl1BOMwiY7c8G4C4zVoRgCVwOZ8Pe5BJ67g6gfWHc+6MyADUWWRgogk4SDKJsc3/OGellh4
Lpafi1tUhqbA3r5BEOOHW8nnB66JhKyBkC12q0DI+w2FedAW2uFQ/BoRlR7dRuoFGCZ1hEkt
MCHlqJByUPf9O5SOK/djy8ZkxUF35H+/0vZIhrtjDtVMnY5LSIb8tJYRUg7gkhffEG0IbBeL
7+rLt/ENb0Io1m57gH3uT6njo1R6WQ27MpiiGzf0ZT9iHrCM/jqWMzJmMG0dvTrCwq/ISVzi
cdfPi2dz2XWILrVR8Ug7OVK4WU0okUNglAKiB41Sw0apnhulWo1So0ap/qtGKbklL7NM1Ncs
WqbQDguWSaImGYxsJYOEbTIY+UoGCZtkMNKVDBI2yWClCxkkbJLBSFcyaLpFBiN9di7RcrRD
uu1JcL6nSXC+Y2lwth9JcL7aJDhfSxI0IeDhdnXtzB2lEOj/DQSiSdE+jyAwEAQ8Q8ALBLxA
oEEIEALqaJJo8EUpEtdF7ReJrPq4XlXWG8nBdvrhEdYHrTY20nWB/Tb5hABtYMG/bWiAo866
4S66Ke5lCE5viFKQtPmhj2sUoXqEZ/fYCFc04ZYeiqYE7AKZO6i5G8c9Po8exCP3sCpU6A63
IiXI29P+ver4YTvU0g7nDLJ7gB3F7vvotvwFxR8/R9hbdBGfLlASb17jg8FZLNqbz8WdmDec
H8z+50XAs1vt11sGMsPZzSnWAMWOgvgs1E+ZgwvhZ20PZCwYaoS0A+wPzhke3zLGFGLu+ubM
PsZt6bu5n2gZNvjFMaWpHH2S4+3E8bLfZei3haSQlfRiKb3+upN8/dxiOjD/TgtzqdMJlnFv
qyb6LuyGZEE0WLGLr/7/QV1Z/stY66vqOdaW5aSSKWs5arM2nx1Zy+EF1ubzI2s5bLM2nx5Z
y2GbtUa6spbDNmvz6ZG1km6yNp8u5wLnBTxSG1PitT7denOA7q05QHfPHiD7Yw7QHTAH6BrN
ASaHe1DiMMNwPWFYWvdhjuGKxAIua8RwL/qkmK0Jw14w7BHD9I7AK/DwygOdKlgpWMa2dx42
ZoDWsMS/MM1b9z2dKKpGWaczbScDsNvJO/Yxk+7rS3+20DmWqACwgQu8bIaoBOXZDOnl3yzM
K9DgdF4Z7XwSPXQonV1ARv6hnOqBwrc2wAUfRMgmnYJ30nQEFDM1KpupCkVBW5+yuapOFDS1
KZuqykRBU5fyqaJKFDQ1KZuqisSplh5lU3X3m8kWYH8XTqJwN83MbEzOjWL2ueWfqeFsYT1W
Ci4ca760hrOl9dQpaJ96vrKGs5X1UlDQvhRGZQnnK8udoaB9Z/KVNZytrFeKK5tXKl9Zw9nK
i8HfAwAb2V4xCmVuZHN0cmVhbQ1lbmRvYmoNOTcgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0v
UGFyZW50IDE0MSAwIFIgDS9SZXNvdXJjZXMgOTggMCBSIA0vQ29udGVudHMgOTkgMCBSIA0v
TWVkaWFCb3ggWyAwIDAgNTk1IDg0MiBdIA0vQ3JvcEJveCBbIDAgMCA1OTUgODQyIF0gDS9S
b3RhdGUgMCANPj4gDWVuZG9iag05OCAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0
IF0gDS9Gb250IDw8IC9UVDIgMTQ5IDAgUiAvVFQ4IDEyNCAwIFIgPj4gDS9FeHRHU3RhdGUg
PDwgL0dTMSAxNTggMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M1IDE1MyAwIFIgPj4gDT4+
IA1lbmRvYmoNOTkgMCBvYmoNPDwgL0xlbmd0aCA0MzA5IC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl
ID4+IA1zdHJlYW0NCkiJrFddc9u4FX3Xr8Aj2bEYAiRB8tGbODvueJOMpbYP231QJFpWR5ZU
UU6y/37vF0BKAjztzk4mhoiDi48L4JyDn+aTd/O5UVrNnyZt1lqVwz/60eZZXuZW1a3NapsX
av4yefe+r9Syp0a56peTdz/PtFr3kyk0zk2l5ssJ/qrg1/fJr8kv6dSYrEq+pFOb6eRhpqb4
q0nUwwepU/O72Vy9v53dzZRKf5v/fZKraQ2IyaGTD9QdzEI6NiV3PLuFrnWblcksxQH+8enn
tM6KRN1/+nB/q2afP87/dft4pz5/uXu8nd9//jRTv6rZ/ezzbzwGLLrhRReZKbWqTVY2usUB
aSlV4UZsCh5xDkvRyXOaZ3XSpdM6M4nayY8fp3RaZjZRz3uYlYZ5HKRUT67mmE5bbLKQ2I93
6bTJ2uS9X7TOdGWtW7Np3QxyzTNYPqcYsNhRsaa/XaqTPrWQAXXaK4H2p2cPHtVDSuN/gDwZ
3Aga/dB1xxseef43GqUscTxavJYkQ3c6hxSv1DatYKv2+4P6kBaUAEz6iWq7JZcbbgPLhWVK
pOLKPoUdHy2zLK3PtOVMyxIxJ4Y6MTDn3dMmnVbQ3foV0gc9Wkw9tlhJiwyzWkjncB5y3Mwi
K6u6cYmsjF+YMTwMpKSAvhawliL52uHq2kS9pKaUusNhQ3U7zJ2BXFMR2CnsVjfNaAkvPUyt
oiCcYoNTNDpzCbibT7TaqEkDh6GBc1fDRYKjp6b099hNnt6C4E5qy5CBTTdjTGsbjdO69oG6
gKNajlFTwfzycKSp4NhIr1WRNWdgkVvf7WUgYrZkDFZkzsEWsmsigcA3pczGFshEI7C0eVZE
RkSskRHp5xisYA9i2XkLc5thW0w3o2WFszpPegT3qY3gPoMx3CUqgvt8RHC/tAj+0/yS9aus
MMj6uszyhlmf6MEO9GD5pOtcwREvobcm+QzXpgWOg9kkq+7YrdR7piKkg5LpwBJhABPut1Sq
XxZ8zwqHr7mYpnS31f2T/KCbY7Ja580lTWqvDMJZp9Nx8xVYI3lNaxhQI1v1ao81TzClGhgY
bjpQRQN3HdbTIldX/GdDzXcQuIb/Z/RozmgK+bVgJi6IiQsgJiS8bAjC9tDH/D8TIBuYcYG8
ZNtBY0ovl7XIJeSzMnkJU0O1yYFEnmFGFZKeRTZ9mD2qXj52K2LEKulRUgimoSsmv4s0/dUk
CAv8v6kP2FkbBRuqiwLnZTOj25bTRHkCbnTXzWDKovTHaJwBw9GeBBl+gwfD8Z4KGY6zYTjc
EyLDcU6MhDtaZDjOjOFwT44SHuXHcPhoX+AOCo1Y/H2V+RA+zmwIH6cuiI9yE8LHiw/h49WF
8CgNWlvDIRvRYDPQYCM0qMc0WILdQRqsPA22zhUZprmGaLASGqwGGqwcvuZCEQ9Wb9LfYLlz
4ZBbvNZNgtQEoQ/YVQsmuQSCeEzJeh+7Zbf5RjiSliUDCUaciNGgV1xQNcyKe1lzX+OLn1tP
vK3Y0ye2aKW4N5284PSBRk/o4UqgMgjUZOAStZI2ru33VKN93/XS2PVFrRf4x/W2o6of0i7g
KmmbBrrTQnfPmAmwloebDSSjBTEAOgPCUxFXF3gC7JyXV6/O3/fi/MXdy3tAPP4LbkWFnEql
1B4unggb7mG3Vs/SoldfBZP+pNjR4+Ncli72P1keu8UJzh0RqrP2esiGbNY2RZVBQ7/qTvQb
bTyWG0bwwLZ8IDXaeKzs4YkF4y/3Uk0pdBFrrnvl4oibDRNfqbPpap9TXYuU/juFLYAHC25/
p5x8lzDQK9WdUiMCjnVPKWyZb60uzqQ/kqJHKakQZZVkXhv5S8+KYsh5m3zruFRLLuGh5wJ3
a8Ho0Lq3hmh6S89HODOge3k9VkOY3LSoqpI0E04znXP/CBBCtXUdUzmEohIXinP6hlhc3EKR
TtkQi8paKNBpGmJRQQsGipohFpWyUKDTMQqMiVgo0CfcDkZY5yR2F5mNNBgSGGkwJCrWwCck
0mBYeKTBsMBIg6iQVZDlcuzni4EThN6AKb2QfQRJMMwCdXKE+y/ihO7+0LmfDLtPkDVPDvxF
EpcotPFDX5dqNqLtvPRuXt4YpyOYbDS3/eYEYtbA1GYpvgkeb0Cutgt0+sy76JO37OyJgPH7
wKgU6O51wt2tU3uhHiNRzRs/DRGP7+CKodvNdqtoRMMjwn3uux2p6omMuuq+0ZdUqs0TSycw
FlUfO7XpFYN77uiMHwOvLJBk2DlYEapf+L2k5J3Ez6+9RCh+bT1zm+5snKIeEdVqD8urKTUt
jNEL7ZYswxS8gD7RimTnsy2H2ZbefVSsEcdj16dNcuDzUCYrnLlO5GvNhdpSJS6ukjeIRoPy
31fGqYsT14aVPm/9XunRXhXDXpHl0AkfjZqOBp7cAZCPPRcSjnvUQi5KmNjpiAmg6D47p39o
pKv6z/N/VRu6rmEJEDSqApFoJwQCx7UgEu/kQOCoIkTCnSgIHNWFWLhIg8BRdYiEO4Fw4TGN
iISP9qV0D4UGiuvEB+BxXgPwOG8heJSXADxedwAerysAR4WhbExm85EwXF9qEIgzYSiYzC0L
w3CpvTSULA02cZ9yhZf7s29+AUH9/loVRnQ8mhDPZ3/ktxV3R1RVY2c3ihxpjdMzMLk7ZJkE
eaimVw7+9WM5Drt+KXw57n/wY+F3ZD2w+9QRfHNXbIQbelxB7kCQ8Pn0SEx/k+I7D6WJHhkL
0iokNvw6Gzj3zt1U3q629PiC9ZcsWpUrNim/Hy09x/Cv+o403w48V7EmlU6TKtIkk1wwFkiD
bds/z1hla7K8iTGWoFHGikQ7xhI4zliReMdYAkcZKxLuGEvgKGPFwoWxBI4yViTcMZYLjzFW
JNzvC7QSsLTY8CLxQXjIaxAe8haGfV6C8LDuIDysKwjHGauARuWIsarhCstVAuY6Y6ySGQsc
qTonD7olaMOYi4x4KTO0FzjF+7+QEHAlcDM2hDD+Fn/lxt/0hqeHRtaSkdVnRrbhK1yLkWUq
qJkDGldsYCotUYEhKjBCBXagAt/POeNc2doL8yqOlOu2v6e6QdIKe9gF+ynLc9Q8OeOKDXXI
Ha3ZCoftmy7cnHTNc3pKW7SdpDHI6+A8c6QhGB59aYd2rWSOx4LsWg1DIdgTzbJdo6hM3TJH
c4axZceWdhvz/tonqeUJgRvFRbXJK/F8158439WQ75bz3Tjq1ZDR3C/aKc215S5JOUWZRMZw
eoVz3I1TrTMKB4dda31O4f8re8OV8A/Ha/ZmNM7e4WjP3gy/wd7heM/eDMfZOxzu2ZvhOHtH
wh17Mxxn73C4Z28Jj7J3OHy0L3BCGLXtddqvwHFOr8Bxxq7BUT6uwPFqr8DxWq7AKF8XFs6T
HfjaeB7KhYeAtj1d3z8xx6od0E6D17zAEw33t9sqNGDC5lj7Sk2OTNVLwdTi2L1Fx9obL6cW
i29wyapksYFBth0oQMsCUJIA9Kk8FXO6r9hyxdiGv9b0lwkKTJi/9KRIlR+tGWxewTavZpun
Nfs8KjfYdZPs1jfplGi377jhbiUt1G7vfm25sXT1VaolQMBzCQiwW78f09sRowwmUzGTCXoC
GUDTu1kuThup4wZ/rb0sajscrSuCEjRKUJFoR1ACxwkqEu8ISuAoQUXCHUEJHCWoWLgQlMBR
goqEO4Jy4TGCioT7fQH6esNfxvAhs2F8SF0E97kJ48Piw/iwujAeZy1DF+ZNl2lHtCXWUPzi
M391il0lvgMtvQPJLL6gfyik9nBgIykdrLm4YUvG5vWOLN97Yrsrahu5KeOdZi5Ocw4TRKvy
gL3a5J9qgbRqktUftJdNb9tGEIbv/RU80kBqaJekSJ57aYEc2qJwzookK2pdOY6YFP73nc/d
pTnDxCl6sUy+nCVnlvPwnUrO7G42PKFWy0uVozOThBUIQ1f09d/An8hw/BF6mvAYkY96foLz
PbOczgNjyNs8z9ERbxtgwnfZmiaOuLEeNVj1qWFHJ2qwvEINOz5Rg2WfGnZ4ogbLPjWccKUG
yz417PBEDQl3qWGH530RCYrXtouyL8WipkuxqJgh5nosxSLbpVjkshRdQMQBTNCwDoj+fwfE
TFqdQhfTH3z6ZVybDX7XYzXJiTyZRp5wQo0e7InPfOZ58Dq9SbPhfOAJuSBBB18CBOYVKVty
KL8Dklq4AZ58+oyp4JgFdqOnoWigekSasvASVvgvr3SSGDqofjnMPU+fEm8yFJFzI8TcFcNs
RynB0hMkeU8P9QBVhkfbT+cLSSf6y/n29dGZajdpqo19Mn0ju0h41errdYcLNXpcnQ9YUlj4
kX/h5nITnHhlD3q9PO1BTw/c0Ey6JPXX7vqmOj7AZp8nLMGFFLn9JIfHozyX/n59Dn2N14tj
m7/JC2qL6lLbiVZqi+xT24lXaovsUtsJV2qL7FLbCxdqi+xS2wlXamu4R20nvNiXjTL95TBq
imVNF2JZsaVY1GMhltkuxDKXhehTO3S328LWZWjrLDpkZv8M9IGm+FjtHwFLATEbauQ3dAJC
ZAP/vMVxrq3v6FK0V3DJofp1x5d9wMPXYfkLo3SvEP6Es27HN2wBgm9pPGV7JpcIxmUwU5Dv
lNhnPrYp3cVcAXkC/AiNEN6wM6QjRHAr5/iDNFI5mL5BPlpIcbziSlaV/3KMXMTywveFpvkP
GIldfgGWGGHVx4gdnTDC8gpG7PiEEZZ9jNjhCSMs+xhxwhUjLPsYscMTRiTcxYgdnvYFapYN
FfDmReFNOdfVlHPdbDnVxZRz3qac8zJlFyphAPe1Laxgn52PGIAwZqy8I/MHX9UL/6LNgoZq
yc0M0nKtuMBOznLTtbXEnCSUT2KnNaucicmSbHq1f/vj+QsFHm9wTDuQj6Pjanq+odHtIzDm
Hm5V87zY07zY0rw481hp8IzF4NnRNDnQMHlF9ojTHMi2xPrhwEfVe/4lX9LXZMaYXmBF9hx4
hvuOBLZIJiwKzqJpwqj0W32mUbEGd2lgJfq5/FUZnmmT4APV/ONPzI//WfM838ipAETatB6n
RHU55UQrp0T2OeXEK6dEdjnlhCunRHY55YULp0R2OeWEK6c03OOUE677Ar/JDL20O6aYamqJ
qWKmqPWwxJStJaZcLNEnE3x1yyG1yV97NTxxk8mEXYsD2gfyGDR5wIzA7kF4QQJMRQ24HFb4
YnBII/V09f74OsPzD/gG7HCxJwu3wscyf57o4FENz27i0QT67tOOLzyVl9/OrUZ+lO+zGiFu
ViYWUf0WtqNTC7O80sJ2fGphlv0WtsNTC7Pst7ATri3Mst/CdnhqYQl3W9gOL/YlGRH4aEKz
Lypv6WVlLb0snakXtbH0MnlLL7OzdLevh35mOJqQ2zpIW4eXbb2lTg1lW/dFWwdq6yht3cvF
1NYB29rpaXY5Tf5uXnfT+XqP30zom6cfQgR/Dw/Tw8cJ5pc+VuAjxoj5vasuywxD20BrQor9
FsogKeLq9bOs+ZsVNGDq8yA80yXYdNLmhJUOinD3U0Xo6MARYN5QCBmgOvIZHVuQtn44T4qB
16cT4wgXGelwsVZyiug8/UhyJfAsACoTa99ItLFf8SQsujyzYxVnrPo0s6MVZqy6LLODFWWs
uiRzggVkrLocs4MVYxLsUcwO1q3YZsIVDBC1b3AXnFBblF1k0d9F+7Yq20vrJrO6ssn24irb
i+s7wKr/Dthrq2yvra8Iq/4r4qwtsrO2vEGs+m+QvbbK9tr6gsna7gtmr62yvfa6+u8ApN9O
ZwplbmRzdHJlYW0NZW5kb2JqDTEwMCAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQg
MTQxIDAgUiANL1Jlc291cmNlcyAxMDEgMCBSIA0vQ29udGVudHMgMTAyIDAgUiANL01lZGlh
Qm94IFsgMCAwIDU5NSA4NDIgXSANL0Nyb3BCb3ggWyAwIDAgNTk1IDg0MiBdIA0vUm90YXRl
IDAgDT4+IA1lbmRvYmoNMTAxIDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSAN
L0ZvbnQgPDwgL1RUMiAxNDkgMCBSIC9UVDggMTI0IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAv
R1MxIDE1OCAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczUgMTUzIDAgUiA+PiANPj4gDWVu
ZG9iag0xMDIgMCBvYmoNPDwgL0xlbmd0aCAyMzU5IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+
IA1zdHJlYW0NCkiJvJdLk9s2Esfv+hQ4kimLJkCAj+PEnqRmy2u7Iu3mkMpBlugZpWRJETVJ
+dtvPwCQGqG13q1USlUiiT+68WL/2P39cvZ6uTRKq+XnWVd0tSrhRzddWZS2rFXT1UVTl5Va
fpm9fjM4tR6oU6mG9ez1jwutHofZHDqXxqnleoZ3Du7+nP2S/TOfG1O47GM+rwudvVuoOd61
mXr31rep5f1iqd7cLe4XSuW/Lv8xK9W8AcWU4OQtuYNZeMfGsuPFHbjWXWGzRY4D/Ov9j3lT
VJl6eP/24U4tPvyw/Pnup3v14eP9T3fLhw/vF+oXtXhYfPiVx4BFt7zoqjBWq8YUttVdHLCj
AXms9SGfO5jpPq+LLtvww/a8vWgecgvTKNj7/XKm1VbN2q6oW3DewG6BfzWn/1M/+3xLgo3X
NUumLpyZalrXop3WTTTUlS1qO1WN00Vbpi2NM4XxXl1VtBdiVdbR7UtD1GrLGqzIXIqdKzoj
GMJLZf1s6gpft4lo67KohBFRa/2IdDsVndHi7tzSwmHUHW43q1rj/eWmC3rcWkGPOyjpYaME
Pe6HoMelCfr3y5eh7YrKYGjbFjpxaFN0VSHOyobffWMUxJm1DmL2Z3zfm+wpbyHQ+j1f/uDL
SZ19u1qdz6ftp2d6OufQMuSwvIwjwxSNLnF2hXZ1HcJNmzCubnncFcZTm/E/BBpe1tvVud+o
P3MD7zYE4BNEvMmUv/bqh/s3MJLL5jB0l+1Wn/odD7r8jvnkbBim9Rj5kusKGLLK5wiPY467
ZuN1i+M22f5RrbnDU17CyL73/rHnm+FVPm+huzpzf+7lxYg0WLG1tGKai+3CXJpuMpcOvSMg
cQ4lPIYrzcXgXPzdAAL6H3o22J+5XT0Hk8G3nPJ5hxvE/bx/P9qgfKeDN5rOd3pCOp6Qn+52
D9uus812DafCh6Cz1dkTEJyDdaXgpLQljrvClE07wSrQfl45R3PGwbXBr0HgZwhJ14p8BEnm
Y8Iu8hG0G3xMWEY+gibzMWEY+QiazMeUYeAjaDIfE4aRj2go8jFhGDe8GRkC99cbm9bH7Uvr
4y4JetyMtD6uOa2PS0vrIgNreJ1cPTLQNviOUozqAMFqAsGnHOKkQf7RVa3UDqiDDDEgA3Po
SX3JDYSAbz0et9TqbR69KTcORMpbeDSRW5gI4YxO/brfInothDXMP9u8UtvP6FbTjA6Ho9oO
eZ2pTX/u14DNVxGFtMhqXGTFLgcI4A68mTDPClMdjfOEJWXoEXzBHbiD/y22se57X7K21JNQ
39MX4MAJ3xkm2iDAARxb38YdCgBCZEAgCPC57rpLgnwrPEpMYUV+sCojJG0dKcLyDZCk7SNL
WJZxkjaPRGFZhopgHrjCsoyWtHmkizcXAZM29+cC5wln61VbF+WLnZf0sLOSHrZO1P3eSHpY
vKSH1Um6zBhrMSTGPKuJAe2jD0I8IuaBAtlmnFIBahAmmmBSMkz21P5I/xTnGH6r3alfbb7m
Bjvdwkk1iUwPEgx8jV9ztdrDw2YkSDFhSCKXobTKRJhAukhuIUdrMcQprM/0D9zUlJ7w9bhZ
cXufV4gaXCNCFB8Ylx2CBbs+8qUANJkXcDBFRcmjnwhxEjERykS1oKoQx3DsziLVMD9TOWS+
mFbuciQQrpdcA5Jdc7VnpZlsGpWALSZUiD/cG64FW6oFTSrnS1exe9pfsrXERfwSBC7yBwM7
ABeRymrR8/OGRQB9Olkr2ziQPw9IhtHG8Jx1toMXdtevBny1NAQlJdoWdhpTQxourKIrcIMr
3hTwD+vTXRc3A0G8/G3C3BqAZsWczasicwXrwFwvy8wV7ANzvSwyVzAPzPWyyFzJ3DPXyyJz
BfPA3GAuMVcwH88lAMvh+C+3/Vqc7Om1ONmxhDjux7U4We21OFnLtSji1XXNRQpXxnzJ+HzJ
4NtfZ44vFyUtpiJP8N5DubfroZra0/2Ge2756ZH+MbHiOKo5jly2kzjL9WYV681qUuM5riCN
rzOreKXKroYajwpKX9thx/3G91BPhxc2XJpy/YbPz1wHwiL9IDt+HEKHizzQuPghcjxD+vaQ
O5zoSeGnxoVHfphzlyU4rCbXdzkXkJt+ferpi1VhlowW5y1fH+n/MlFs7YSs7xaYD7rsI/jE
rgNOvv3rMsK6bG5khF6V6ZS2jnRi+Qad0vaRTizLdEqbRzqxLNNJMA90YlmmU9o80smbi3RK
m8dzqW9nhII+7mxaH7dO0OPepPVx8Wl9XF1al5EFE59mhCKy6r8NWZQadjGVK7uALAN9sZCl
vIwAlcNaYAT8f5VT0GP16LB69OIGcwiIvyNkeZami63qD7pgBYmNh5OQKSXK0yXhyyJlcDr/
howOdgWrUCCW+eYaFRLTBh5RwR5P09L1Ko8y8VBKfyiwHMzJLa4ELzDO4QRZMmfhmSLeQRr7
aRey5Qm0fAY1QstD75vIBd+3G3mVV0VyCdaBXF6WySXYB3J5WSSXYB7I5WWRXJK5J5eXRXIJ
5oFcwVwil2A+noucVyXFyZ7KeVVaHPdDzquS4mQt/0teBfXRNK+y9RiWgVLNZd1qMJqwsKs4
tgA7GJrwCACBwPvU8xOWexVGCrVywVdxlNZY8JU+uqFxgJAyNwva6yzGl7UtMQl9bZRPQWDJ
x93X3NAA5wMA8tT//sw9B6oEzxcZUtlFMOuYw3UExLlm5mpCa6aIvAC5AzeeMGeyF11OMCI/
qgGKvAELvjr7Cg5jMRcSs1grljYsiaZZ8zQNTPMzw+vEhDtQygVk4l5HHt33BVpCx37l+3Ar
ZJklGhDS8KDSMHbx0EMxCceC669gHXyejT/P1rfyeRJ1NZ6m5rNs6Cxh34+nw3FF7dz/TGJP
95sEjOfjt8kz8xnWh5+S4XzCXJkKW0fj0wXOyKJaYDrZvcgfYaxG6/8rf3TgVs4fvSpTOG0d
KczyDQqn7SOFWZYpnDaPFGZZprBgHijMskzhtHmksDcXKZw2j+dSjflX3V1o1tpRu7IUVH+i
Xr1xoolxgyi4Dsft5VvHnXAeRMF5eBe8fONdSPgOouA7vChevvGipHx7UfLt3yIv33iLEr6D
KPgOr1jwLb9iCd9BFHz/F/n60woks/BptZWDIsF/WhFAgJrlb0ia/wwAHM15WAplbmRzdHJl
YW0NZW5kb2JqDTEwMyAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMTQxIDAgUiAN
L1Jlc291cmNlcyAxMDQgMCBSIA0vQ29udGVudHMgMTA1IDAgUiANL01lZGlhQm94IFsgMCAw
IDU5NSA4NDIgXSANL0Nyb3BCb3ggWyAwIDAgNTk1IDg0MiBdIA0vUm90YXRlIDAgDT4+IA1l
bmRvYmoNMTA0IDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwg
L1RUMiAxNDkgMCBSIC9UVDggMTI0IDAgUiAvVFQxMCAxMjYgMCBSID4+IA0vRXh0R1N0YXRl
IDw8IC9HUzEgMTU4IDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNSAxNTMgMCBSID4+IA0+
PiANZW5kb2JqDTEwNSAwIG9iag08PCAvTGVuZ3RoIDM5MDggL0ZpbHRlciAvRmxhdGVEZWNv
ZGUgPj4gDXN0cmVhbQ0KSIm0l0tz2zgSx+/+FDiSWxFDgAQfx8RxZrPlSVKWNjmk5iBbtK0d
jeSR5Dy+/fYDACEJrdmamS1XmRT+aDwa6B+7X88uXs5mRmk1u7/oi75RJfzRS18WZV02qu2b
om3KSs1+u3h5ubPqbkedSrW7u3j501Srh93FBDqXxqrZ3QW+WXj7dvEl+zmfGFPY7GM+aQqd
XU/VBN+6TF2/cW1qdjWdqctX06upUvkvs39dlGrSgmJKGOQNDQercAObmgeevoKhdV/U2TTH
Cf79/qe8LapMvXv/5t0rNf3wdvb51c2V+vDx6ubV7N2H91P1RU3fTT/8wnPApjvedKlaGKAq
NU1G8+AUmcpn/4l8ow1tGR6maouGHFO3RV2zY3BtukfriX/FZcIzn1hbZtfz2yG3RZut1E1e
w7b51+/P/NztobHP1M/8K9fQ44EWejW70GqpLoztC1NrmBRdo/oO1qAmujBqO1zcX7yeRSus
bFt03fEKT7fWnT32yhZNx7ZsUeJ82jYNeioMokvnx8LYCgZxR1bb0RnuMtwM97A9k6npcLen
tyX936xVVdiiOz6ZCQ+Jk9Z1c/54yqLtrSGHmK4P94ZOJJuuCuqOq2lNFW+DerXY60v2fgNn
hXeI1tEVre1V1JOG4nHMyTh8/9tw/1ve8mzIJ3XR4PlO2kxdzvNJhwfsmnkmrQvbdtXxXNE+
caIKout4Qt3xyqd7jqXhacdDwmXSsIbDfeoQRdpF0RX4v8++Q+Q02RMcyrBQN8OODuU5hzPJ
VnuFYdZU0O3DLSvb4Sv0o2n6oqv0qT/1uHwY7hkHgU3Aza7jJU3Gvng3fssN3v0572T7a65x
UrcfiIKuh+sI91/DrahVWdSdmtB/uv/nVbjTugmqaQq8KqOsdXPOWus2NtdVTbE3djBWF10p
2htrCjMObysIzlivyiYe/9gc5aYOMuzUHOo9HKKRzQHf9bg4PMom1uumLCp5dpS7cXb6FevW
6HO++wPZH1vZwyfGqaYCAB0djKAHxwt68Kyke9cJevCNoIfdCfrrmYxZII0BzDZtC44ZPyJ1
M3KzcR8RikHcanYNUQEhYiBQbodVTrS6yTsIlIEaf3/OwdFNBkHcQajuuQeEVgVfSu7CCv/n
kR6cDf1QrDxy28aNx1MtYB0wDockdNZldxz7OqQAnvrz1bfc4McNIhsclP3I4bMNRIQR4eN/
t1kDfSys1OB6lvxLvb26BB3ShBlMWYNynYPXsk8OmICmpomBCVwq2y5g50sGqcSkshZN0Xul
NjjbEUuaDjIbI9HCqSItBGtPCyfLtBDsPS2cLNJCMPe0cLJIC8nc0cLJIi0Ec08Lby7RQjCP
ziXAIoEDSY89m9Jj1yX1yDcpPd58So93l9IBBwIE4JRbEyCAn24HAW1cJmEgANpsJMHsMYfZ
WohaiAYIlLe5xq/4VU43/TI3JQTPNUaezj7l2mJgQ+BVmbPb0HjP/GOVg2driG+aYx332LOk
trnWxBCa7t4ThX457RwXXE6ASZJLjfeUbUHO+w3HstlyteCGu/nWvSEGdn9zyMONliOeRDng
k7Yh3kk9E+5J6xDtpMrBnjQOsU6qHOppYx/ppMqBnjQOcc7GYpgnjcNRmJEBqSgX9NGhaX30
maAHt6T1cedpfdxcWpejvIIcqBw/9WUoF6CWoCtc+QIkRDm8WQjZBiNdufpkTT9X8CHtMPJd
6xM/9suDXnP8ZBuoOnkk/IwCD3Zqvh3OhWt9Wsr+M8fI2jypSxgDXnBgnVF+0MNk9MB8o+GP
dumyFVjJJ7JUc9dpoT7OueMjN/BCyoNCD51ivHtgfbSEr5SaQJ2y2dIciI1rTlCOMgNTVBD/
fwETFT5FTrAqgyJtHUjB8hlUpO0DK1iWYZE2D7RgWcaFYO55wbIMjLR5IIYzF5GRNo/OxYcc
uK8+RkZajv2akGO/peTILwk53ndCjveVkEVYWHgx3QiLaozI0kVkfcgJfD5SmjzA2FAJ0OvO
pdc1BuaSHtykuA3imALgdsAywRAyTLYA2KxpgBX1+gGS+H2nRdnKR2vnYLbPJ24CWFqF89Hv
x7yktGXSYgSu3ct3p6pH3//J2/kX19M9tvkEywh17/v7hrdX+QQLosu/OXEo67HEOyUCqzIR
0taBCCyfIULaPhCBZZkIafNABJZlIgjmnggsy0RImwciOHORCGnz6FxMdyaLEPTYsyk9dl1S
j3yT0uPNp/R4dyldBkMLyXkzgsGELKJ0gWcPuYApf0f5A1GBXneQHECuoJb8gqGvgQnzHD/b
EPxz1/5uTf0f6P8WP/mNN3Y9zjGh8StzwKJYpdCFbzYTwVJFUnJUY8aPGNBQxlAwXxbwdHPM
/sEcjAL3M9gj8rIBWAUJhsIH1CQwABQVXLZsgIOAooocQNsFRswXi2Gh9puDkXUoUXzKs38E
Ump03AaX1UO2g7/3yzU9H+i/2s9vWYUqCrw3vFDL+5wys2DPTzfIEz8O5w65jna5zh317mhK
k63pP9RiaLjc4XmVmesBmRxNZLI5d1OGBXDIitfWoX8Ruysh1zpNReGu8Ok8c/K52/O8UENa
n1UuuMfAv4pD4NqibdGlfxa4toNBawm4ThWBK1h74DpZBq5g74HrZBG4grkHrpNF4ErmDrhO
FoErmHvgenMJuIJ5OJdyxHHTH7s9IY4+TYijx1Ji8EdCHHebEMe9JESZraU5SLpMIBhgma5u
c8RWuLhI12akqwOk8XQ1jq410bUFur5gvGJJdK4GKwMTTOdjcvdMhqs9V31ddp8TNh+omQKx
zfYIKPz94GchDFjGgCYMuPDuMh4QwzvmkbFh49axG+ssZjdYbWhLFSGuAyAM6pmewDYsynB7
mqgLFsPcd34ahi3RkYY6nLALE5oAX4TosHXYrhnw1JZj2fid3nESSGa5M1SnOIeiGSwCklYQ
ZuKCNv6EYLaINL48ohdwwTT2kF7/K7i0PpMpOlUGV9o6gIvlM+BK2wdwsSyDK20ewMWyDC7B
3IOLZRlcafMALmcugittHp1LyLRsWzSnjk/IsV8Tcuy3lBz5JSHH+07I8b4SsoixuoYbWjLG
uDgLKOlcdLVUNfE1Zpy93bgmKqQgpNa+YT2Bz36FYMMkTfsOD5Qsuja1wjiy2ZIf6193L7AM
Q/pwhx0nj8oN5VrXP3KIof40jYxykzhcua5lwjbZ3qdz24EZ28G4mP0thkK9Iwi0mVc4L9w+
oHmcBUXENcFNpc/C5k/z2xUSe7XygEda5ojOPT9o+gOWnWTkLr0eyGNbzqYhAV1ydg156Fxx
Or0EmtVZnHSvqCWRux8BC3pZxNSfTbdqQELTSdRyqkgtwdpTy8kytQR7Ty0ni9QSzD21nCxS
SzJ31HKySC3B3FPLm0vUEsyjczFOrC2u4MTxCTn2a0KO/ZaSI78k5HjfCTneV0IWqVX17UFh
W4YcxLgcpMOUxUbM+owUwRKwweha02NMdyynO/WY7lhKd6yvZs4kX5D/+hhuPHruhuVXCMGa
4thmC5/KaJpzA8kHJiqZWgz74W4/gH5QuBIVJr7awiF3kLxVBKYOYr7H5DCfGMyUVnkN8+CQ
MBi9w4j8XCjuuuGu3Lqk/7AaHX7czWPJ9WbTPyp7XaE61q/kPmx65obdftie8qfp+7/An7I9
U+45VeZP2jrwh+Uz/EnbB/6wLPMnbR74w7LMH8Hc84dlmT9p88AfZy7yJ20ezqUZc6q6KcoT
z6f10bNpfXSdoAffpPVx82l93F1alzEEC/fJUxpD/f8ZQ1Huc1qHBQxxOtEghuZr+v0jN9ig
Fq4WWy2BASFzsJw5QFkmZD+1DoBCJuBk/+W+bHabBoI4/io+OhKKYscf8aFHbqhFbTlVHEzj
RkEhRI5BiNeAB2a+dj2WZwzqkUuc3f/OrHd29+cZZMeOMAXQGKiBSSGy4VOX7LX83PZ7YNOE
CUAcuOyvZ8IW9tjPSUR1meBYByaI7DPBsQ9MENllgmMemCCyywTPXJggsssExzwwIZh7THDM
1b6ELzuEryjmgTdkHVdD1nGzZBUXQ9brNmS9LkP2YQBLyncjDOapfbbB81sUJZVQPX4zKUtP
4kWtJe/fIxC6WEaMmfybxUSkwhnhKlKqsU15AqjFoOjAdAMv0Jl64GZiqSAtnLNOf9D/AWoI
sGRDyCkuXdczNAAfMRl4Si/9VzYgksCV7w7U7DueSKYzpx2SjttYL6nUh+vPKtafkk1dO2bm
eU9FZhXLTfhH9WWThva3gXMPsRgHSv+RHy8rRIg0nnlsy4/pwGB+1hwU5tLbFpUCFdSrCCmY
HIl9vbb85yAda5yhSqfcA6JkRTnl3r8iLy/Hz9Uceaz6yLOtI/JYXkCebR+Rx7KPPNs8Io9l
H3mOeUAeyz7ybPOIPDF3kWebq33JAxDL2oy8pevIWroOnamr2Fi6Xryl69VZuku+vNzhnyXy
Zf8L+Wi2Jq5Pkh+hYYM0zISFjbCwTPmXXwSeBL8mwI87obBLuXuPL5hN6y4j3TpRPtUCyPIU
4kWt5Msqz9Ez9V4unHOdue48SPkpYzoaw/kY/7KVDGM5aSWfmxB6q5nXcZJ6gPFF2iPhmtB3
vc5Ql1evQ11e1Ws3uWPRBZ1tGzjHqo852zpQjlUXcrZxYByrLuIcYyEcqy7gbOPANzH28GYb
q63Y5iMdqnm0DVmH05B1wCxZhcSQ9aINWS/LkH2sbSABLFR1FzOTvBCs4UEv0pwfI+IeLtxz
Og4JVnqEHezojz/l35m6k+/0OK4yQI8oJ2q0w3E68gXoEMf0SzDc7iItQKQXfbfK8D63K6zH
GBcAontwiVcdO4G2Dbx5hxceMjQasCYiJ0buY1PwKXmPAIAMCMh5c5PcdgxFJCusQIkfveKP
3JFjZETVSAX40GEUCI4l4aHMN8i2X6ssS2/v2BsEpqxn0dhoWt3ffXiEXUIfb397Od0mYzKd
VyWngHA20wE+LZi9HZ95Z7CPB6w1sJs1LmRcD3x5sobWg3F8/KyZtmnWde5CjVWfarZ1xBrL
C1yz7SPYWPbJZptHtLHss80xD3Bj2aebbR7xJuYu32xztS9wwWPhV1YTOauLhXLXUWVTRV3c
VGvqoDvew6aLvLzplv+gO/7DoRB58VBY7oPuuA+HRuTFQ2O6F91zL4dK5MVDZbkPuuM+HLrg
funQWe6D7rj/izz/eAHBCmBeViFA5ePF/BH8/BkAEwRZJwplbmRzdHJlYW0NZW5kb2JqDTEw
NiAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMTQxIDAgUiANL1Jlc291cmNlcyAx
MDcgMCBSIA0vQ29udGVudHMgMTA4IDAgUiANL01lZGlhQm94IFsgMCAwIDU5NSA4NDIgXSAN
L0Nyb3BCb3ggWyAwIDAgNTk1IDg0MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNMTA3IDAg
b2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL1RUMiAxNDkgMCBS
IC9UVDggMTI0IDAgUiAvVFQxMCAxMjYgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgMTU4
IDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNSAxNTMgMCBSID4+IA0+PiANZW5kb2JqDTEw
OCAwIG9iag08PCAvTGVuZ3RoIDM5NzIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVh
bQ0KSInsV1Fz2zYSftevwNuBNxFDgARI3pvjOB3fOHHH0qW9SfpA25StO0dyJLpt/v3tLhYQ
JBFObqaZ6cxdO7FILBbYXWC/7+Or+eTlfK6FEvPFpM1bKwr4nx7aIi+qwoq6tXlti1LMP01e
nm6NuNnSpEJsbyYvf5gpcbedTGFyoY2Y30zwycDTb5MP8m021To38sdsanMlL2Ziik+NFBev
eUzMz2ZzcXoyO5sJkf0y//ukENMaLLqARV7TchAFL6wrt/DsBJZWbV7JWYYb/OPdD1mdl1Kc
v3t9fiJml2/mP51cnYnLH8+uTubnl+9m4oOYnc8uf3F7QNKNS7oQNSxQFoo2o31wCymy+b+i
2ihNKcOP1kXeUGGqOq8qVxjKHx9dmPiEYepCZFNjCnnRXfcP4uR6vRnEVf/5qd8O4u32jmI5
m0+UWIqJrjSsp2BdzF6oUueQ7lTlWmz6yWLyah5FUdZVbpuDKEbCb5492tLgIuTrPArcTxlr
sRphEVVwrXJtSliEj6Wi86bUFR/4Vb/ITK6lmPU3Az0t6e96Jcrc5O1h9aduSdy0quzzR1Dk
dWs0FUQ3bbgbLTrI2UNO0zGaWpdxGjSrxlkf5Ls1nAfeE4qjyWvTimgmLeXW0UfruDtehzte
u5TnfTaFs5DbIZvWUpx22RTWlVsedjsplZu6KQ/3ivLEjUrooMMNVeMinw2uX/rHrVuyylsF
MeznqUKnKO6UM6h/K3+H7rDyEQ6lv4ULuKVDecrgTOTDILCVbAnTLq+dZdP/CvNomzZvSnVc
T7ULH5Z7wkUgCZPDdRQHGbi5eDc+ZRpmyM5lsvl3pnBTzgfaoGnhOkIDqAJvfpFXjZjSX7r/
z1vhTisbrNrmeFV2ZqXsc95K1bG7KuHoqniCNipviqS/NtCsu+VNmTd79rKw8fqH7mi2VTBD
pnrf3sIh6rQ7QHS1Cw6P0sb2yhZ5md4dzc1ud3qL7Uar52r3FbM/tqIFGmGrLgGADg4mYQ+F
T9hDZVN2X7qEPdQmYQ/ZJeyv5mmYBaTRALO2rqEwDNGIm3qHm9p1qaIexFTl+SrDQkoxZNDi
8t699eIiUxp6uAO+KyWwCVnFSaYMNDESixu4yhp472nW5yd23kL7N5JnULfpHI6rOWxrHdCD
+RvhwMq7rJEvIECI6R4eewGNDJcEYoGmkysYugWwk92w3nxBC7I6TC+h1y8wgkq+dwuJbtO7
/ed/ZXAIeFoSnsq/CUISb68CoEHxvaaoIT+AECO328493PGAOEf0beXrGOaLmF8iUKX1G7fq
mzP0qOQpRV7DUhcZXEz5Pl4iqlRZhTMsGGlvPmYCT0lRZRSeCp2SwkOpcwwaB+FQULfgmdCJ
gFm8pTf85xzv3BR6Fuev4TBrGeoGeyLwe/wFBrrINK7zHu6C5xtAdmtLYeHu1/U+O8AtUkB7
5Pq+3ywXsFkpv2Qgp2AXuIgWaoUbZ9PSFqBJ5CFA2wYkoU5BMFuTEJzw9hDM5jQEJ/w9BLM5
CcEJdw/BbE5CcMqdIZjNSQhOuHsI9u4pCE64R+cSELgpsP5HlR+zx5Uds8elG7VHtRmzx8mP
2ePsxuyAsePIalr7NWTVfw5kLcK3kfbfRiD/EbIAWPELBqEVX3tAyOVWrOiF1CrY+PfR/QxL
fneTAAIVNOlDDBCFbiKAeOw2HUA2FBnCLyDSod/k+0ABSamy/MOBojDPAYWzpoFi3DsAhTM/
AxTj/gEonDkNFOPuASicOQ0UCXcPFM6cBopx9wAU7J4EinH36FxCo0H9jD2u/Jg9ruyYPS7d
qD2qzZg9Tn7MHmc3Zk8DhYWvxsIBBcGDUb4fG9Y6JbSRQjbe4UU2RRpeZIgO4urpL9BuFbD0
lGh51aMQ+X3Azzy4+fdr9n/06yz8yMatI1Bj4Kfhqbjv0HebAoypVyasfFij3KDGqRG3AHk6
97JyyqdGBaZQk4kFbacQO2jgU6Zg74vZlbgKcwZvpPFjkRQpMxJlP5Mm2xdBaHWfrh5Dyrwy
GKtPIEBebTyIYKwVFqSBzZeAG/Cz+ILfgRYLrwFRUHphsE8CIwfA6ZyTn7XlRVYuG694jNv8
AHZ3Ko1PuXNoXxHaK0b7mtG+9GhfJ5VjEU6l5FO56j9jQI18AomLjDBg4A1KVJRtIFHvnMG9
U+1x+rcLy46jgjvVrUgZCvhvX0ZXISx2unwixT1sB/DBp1tXtuWKJT3p8YsMteqUiM/Ze/f2
sL9+GWS4tT5tx0Gf8bZZSF47ZxzbZoWkKnDexkt1w1LdhGPzG5iQQMMJcPtUrn2gcG/wuhgJ
TdRCC+E1qCHQFTUg1tX9eq/UAR5/UEStYdmtzVE/NHlRa+JEUBmqbXf94L5RdjxnavBtUjzH
1iTPJbw9z7E5zXMJf89zbE7yXMLd8xybkzyXcmeeY3OS5xLunue8e4rnEu7RuXgSbBWEe1z4
EXNc1xFzXLcxc1SXEXOc94g5zmvEnCS4ygKixgQXrjkLuAouuI7IDfB1iY1YIqGRdkNOQhW7
WtPU1fQTIiUBGY5vqENKQI7CD73AVtzNf0b+6taH44EYcKiBJe7o78ZJWFDTluAD/yJQK9hv
BsgH4YLO1oR/OP9W3NNvlyk/e9Pf9MtfabSH0ds9NfzNNHDMA6j6S1L9yql+p/mtZPsCoyTY
0XKzL8GPcn5zdurSWGQENpz2mrR5HbITT/TziHjn8xsyJL9N3/m5j32/Ef/MdztG6BSTMoCG
tuYZVQFXwugCaxzRrpcXRLqlJ93ak27zPUk3cNofTLV8LP9jBHvMgN+VavcU7H9FtU31TVRb
1Q0SUYJq2Zqk2oS3p1o2p6k24e+pls1Jqk24e6plc5JqU+5MtWxOUm3C3VOtd09RbcI9nEud
e2Orc+iXg8KPmnd1HTXv6jZuDnUZNe/yHjXv8ho1J6m2rOGONvG35FFDmdAZ+3SLXUPfjw3T
LUDrJ4TYSnKPcQcCyUKH8NgL/FyqmGhx2dWU11rd8XyeuU1+UhIhBUAtNPcjkpcmiq2JYhWT
UMMUi+BVABchCVURySLmFkTEneBF3ETA9n3mtTsyYBAg1G8d6iP8C+LYlji2dhyLuW9hUEue
skD+KAlxEKYAoCzhk5KnjjJ5wiZDiYKEWgZg8nQcTqngQCjTytFt5ejWYqZEtiqQrfZkK9jh
Fh6XOG9vfazpTagzrj/cQ5SAz2KNgNzIFb0+AKeipBiBZ3IuQ5i1W+ajfOi2GZZs+JhRsKUL
Fu8SDWdlCFaRbirAhoeq4VBtgNqjb80iKBTNTL1BhjWwyhP4tciwyxU93dFfOO2H7trNgCun
gMUWEI+VazcGB3N2+nVNskP7/2uSP6EmOZYM31mdxKLhO6kTX7PvoknKxuSwXEKTsDWpSRLe
XpOwOa1JEv5ek7A5qUkS7l6TsDmpSVLurEnYnNQkCXevSbx7SpMk3KNz0c+IkpQ9ruyYPS7d
qD2qzZg9Tn7MHmc3Zk9KE90AK1gnTQjWw233sGJ3kuScvkJLZnzCBaWINgzRRhvxvSW+r0kH
aMmkT5Rf7yh/XHVUEfRyEG+7x8dlhoSxwhAqACb6EcTbmpQAwkhD/zp64ynOJPa8IUyc97jm
d3zheXsEHbBbs/wZiLY4n5Y0DAYvr91w794exJVjRU1irXXCDC0E7pbEEL2/EB3SoZEDyIUE
lBYmgLZxUSwHkFoIiYTJED5A2ooGBqgvR1fDcbCdMNs4zK4gupOM2I+H1+5ngyDYAAwnYHan
Vkq9R2SaiKwJROay1T5bkzf+nakMA7x2D/xOe0P0YvgP62XT0zgMhOG/0mMqQVXHSZwcue9h
BWjvFQ0QCVFIC2j//c6nnRBPuOyFkIxnktoz7zzzzOvnvS6kXieE8zb2n1uU9gGSr8Iw2I0+
6NF5S5RMzRozDjOXmzUc/C2dND5659U9L7+w+ScOgRwvQ4g0FIulrL5jyD0cMGbcM+FUrxRU
8clj5yROgiK66JI1GPGpJHwkccSDA/VR/H2QvFImnOaeK8B/62c+IlzTcSREJaJpYk7pu630
XeCO4WyQ5xJgP6naqShC8TIcOcJus+HtqAsF3F8kEXdEUrcGbHqXzt3pp4LQdXSoJWAds/bD
M5ykK04n1Bo4UUizzQc90gezoo64XIYJdft0RoHPqIEzOvE95idnbz0FPM3Ih8jhTMQv/eHc
b6BKv7Yl8thAbwhYlzNfFyvb1XqoHZftng8V8lXqBx9gXJKxPosok9MkKWqUohqhKLzukH2a
7CyBQTjdGWcwedq6nvPMAmXKDgS4slBGrCbKGN6KMmK2UcbwV5QRs4kyhruijJhNlLHcBWXE
bKKM4a4oo+4Wyhju8VzKBDoOK7z5vvXGgrS3xoK0e9aCuD/GgrQDxoL0G40FJtG4psV/ItFU
SUWcqEhISHNPzN+ALkG2Y2GN1BCCsoEr+BbpoMRJAbUdBwWebUmEaxLhUppMKxNhpROhTm5L
2OHxJU4vaU5ClHrHL4OW5gp5cMa3VgUNK57AwrM0kJHrvJM67xB4aJ14bV7l+adcaTTycy2r
ytT2TuOxH/vjbtb+oMk671WfHclOuWtcLZ3kTz8Oj1uM+xexJ6BYXDcgMERW177Zl7HLJgVx
IexaS0DYaOpH3lflg622euS9VTzYampH3lmlg62mchjOIhxsNXUj76yyIc6WauSdJ0cBeMdW
2La6WW53zj7d0Jx9umdZ+2RbcvbpL8/Zpz8uZ7fVwoOGtpP5J5bjXlpym8TihkvulYgda38P
hXRH5HhLVJ/GnxrIFAcTXvvEHgf1wTGo+XEMKpNwCXGTsNQqLFDkyLNE9oi/QLQO8Z8UrC1k
CU5IsoCf898DPXkSD7rhpRJkFmMGLRF4lETfxtNDj2CCb8C/iD4DBNvDp8mFCKYsjsPh0r+Q
OLTFFZPwPLqL0TvFqSf4FMdQ1BbjEXWtAxY6nxHP8H8coVoC6UAavpE1YiYKQygOJOcV6NJl
7A80mXVZEsq3De4ELOkHvvSb0yPMtfR2ehD7iHSGu21T/L5adpXjQMvl7okv5ugVN8XLp3zh
2OsJLGvtRND2aODjuY7aRqmjKN5/0FKc0m7wk+O6E19oBoP20h/5nj9GlR+4N+A+/Gflrybd
fSn9bLW1P+8dxZ/NK+qf94/yz2Zb//PusQGw2e4Ahru2ADbbPSDvHpuAuJtdIO8+OZdSmwSM
iVNb8Mm0cMwb5TzZuHqci5eqMR9Yj5qt6ye9CK3GfGjNArauJsEishrzkTVB2LqaH8vIYjQi
S+6wdTV1FpHVmI+saSWR17JqEVmN+cjr1n8DAG9iy4AKZW5kc3RyZWFtDWVuZG9iag0xMDkg
MCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDE0MSAwIFIgDS9SZXNvdXJjZXMgMTEw
IDAgUiANL0NvbnRlbnRzIDExMSAwIFIgDS9NZWRpYUJveCBbIDAgMCA1OTUgODQyIF0gDS9D
cm9wQm94IFsgMCAwIDU5NSA4NDIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTExMCAwIG9i
ag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9UVDIgMTQ5IDAgUiAv
VFQ4IDEyNCAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSAxNTggMCBSID4+IA0vQ29sb3JT
cGFjZSA8PCAvQ3M1IDE1MyAwIFIgPj4gDT4+IA1lbmRvYmoNMTExIDAgb2JqDTw8IC9MZW5n
dGggMjM3OCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIibyXXW/jNhaG7/0r
eCktxhrxU9Jl2skWs5idKcZe7EXaCydRUhWZJLWdFvvv93yRlmPSHQyKIoAj8eU5JA/F5xx+
t168Xa+N0mp9txiaIagW/uhhaJvWtUF1Q2i60Fq1/rJ4+/3Oq5sddWrV7mbx9oeVVve7xRI6
t8ar9c0Cnzw8/bG4qv5dL41pfPVjvQyNrj6s1BKf+kp9eCdtan25WqvvL1aXK6Xqn9f/WrRq
2YFiWnDyjtzBLMSxcex4dQGu9dC4alXjAP/5+EPdNbZS7z++e3+hVp/+uf7vxedL9enHy88X
6/efPq7UlVq9X336mceARfe8aNsYp1VnGtfrIQ1o0oA9D/jxqV56mPh+uoOBhmq62ewnaXus
Q2MqJW/beulwXdM9NbMYtYlfWVLTPq1YN9qHQOPT0Dhqper1r4vL9UKrSS36oQk9zLSD0MNk
1ZJ+t+Pi7pwEu6gDSyY03sw1rUPRTusuGWrrmuDmqvG66du8pfGmMeLV26Y/Em0bktvXhqgF
xxqsyByLg28GUzCEL9TJbILFb3cmutA2tjAiar2MSI9z0RtdjM45LW5GGDDcrBoLZ+lV0At6
Cm1BTxEs6TFQBT3Fo6CnpRX079avOeEba5ATtsOTQ5zAk+M6/JAJDLrjQzQoPLS4wOpDrS2c
kg2c3r66Hh9qD2dZXdQ6VNdP2z2/fq6HaqQev73Uum26atzVPRxz0b/UMDEvXVjhX3Z7Lzb0
wifNNJ1u+6PjhvMb4nHXmmc67WAEX6nNwx+18eSxrf5Xm7YSgf+N0PpIPNjDIKFSdzXsPiIA
eFI9wfxwAmr/C/UZ56fduTS8TSf+qnqBJT/XS1wIfCfg1oKD7bgBVxg29TyOW3YD8YMlWGUa
22qDvnxj2q5HZ1cVsHRpvXeIGQh6i0dEYgBAid+oC7i9JWawWsZG3jqRg+Uz8MjbJ36wXEZI
3jxRhOUySArmkSUsl3GSN09EibJ9Za1hj85Y63lkQ5tlTt72sKUiQdzda+bkxNl2nIqzYGfE
QyhPxdlST8XZWk7FMmFa07T9jDD9gTCSpnWLX7tzPiLGEAsGQYxnxAB4BDKeIAPvI/VizPSM
GVdJD8JMkC6s8C+7vhcbejmHGZOqirafYaZnmqAH+F6AJz3Mes/e9k/qZsMtN+ODkkcEERY7
z9vxd2qYnl7ov7ijOaz/wUPpVMoMPOjD5hqrEUTrEpnyoE5btuNv3PJSY7TG3R4hho+bvZp2
xyOcVGfPaOvYm6UKKFS33Dbx2z39NsxJtYaOHnz/Qq1jnE/ykObjaD6B5hOncFV9qakSlM67
3Ya9y7uaZGi1f/idBPB2R2lCemx3EOfYJ87haIU2rVAyGQ2p2UGIQ9r4LkMC+XfjIwn7GitC
fuYxbDYdLI+3zEo6euJa+aXGLdnv9vAd4NMtN0/8dk+/HLzAkzMxdAfrFLqYPwKc4a47zh+S
jL4uiWgNjopJhNVyEslbpyTC8pkkkrdPSYTlchLJm6ckwnI5iRTMYxJhObjmBPOmPPeUBcQ6
nwXytrM9aWOO6FuM/UnUc/o8qjl9HrasPotLTp+vPKfPV5fTi6khGH2cGtwhNQiUoLRLqeH9
Xa0NXtI2CtMC16FekoQW4htpfX6eqPUROe8Y93AMnraIY3oGHmNH9bSvGWPUOpL19lxGaF0C
S+BZIiIcXxcDXTZ7PODpshmkA4TjYbMfb7lN8BUELe6AUKGgBw7MgXaaiYASnEJGziFIeU4m
2/FmnDjNcIK6fYPD0LvaYB5NrpfHa7IuwbJnPpvIZ5kZviuosG01PTyoR2om1kHuVdf8ELsh
SikoNIljhtnGhWH4doYF255hmKhFhhWsI8NELjOsYB8ZJnKRYQXzyDCRiwwrmQvDRC4xrGAd
GRatswwr2M72JDEAat42E/WcPo9qTp+HLavP4pLT5yvP6fPV5fQiw3zn4AObMUwfGCZ1ANzz
jhhGV0JkGOwO0coQwxyfW65msXqD62cHB4fa6cjy47laNR5iHc+waaVE1VRmBvndUMt9HTXm
RjhwQ9pv1eYOKm2YBlxgkR+zGqtQ9XxFJQOl6A7YuLuDFYZqgpGAK1IWvVHToVY9qrIOGUIg
ccuEh6q+utlsb8fbE7x4hMocL19JFt+7ElZQKjIlZxeBglqZJjnLiBLUihzJGUaIoFYkSNZQ
8IFaiR05uwgOsstSI2eVgm0xnHLkPB6uV0HN64fQ5fVDhAp6CkRePyw4rx+WltfLyDD9cdmT
QYb925CRbkltuiXBwjQBwBEuBvnd1FxJ8SWMyqmJlUO5EZVbdQ3XNd1iYWBhTtuRyw/7p5c0
qYG6eC1L18iOrpH2FUF64IeuRrm6vXl1TStedr/qsgqj3B73GqV6g6VvHqlfep1dbVmRyymX
g3ZWDjrpoH6aTSM7gTwEW88oY1vPA0HNipGGGpBn6Kufam6gYNGN1uONFsG3eRAbbr2nXyrp
YDMnCqGXstQf33jnZfDJ1kHJODD4ceOoZKS94Hc1ySapJ/6Pm3fYr9N9jw3SHdaHBeZR+rE+
ziF4KYnrZUcpj0IJER1gCS9U1EvbjjLbHq4L2vPsqHW34Yd7aThOJnhinf32WtXb7kytKmo5
r+StU2ph+Ux2ydunBMNyOcfkzVOaYbmcaQrmMdmwXMw3eeuUcsQ6n3XytrM9SbXeYBq4A51E
PafPo5rT52HL6rO45PT5ynP6fHU5vZh4nIUzH2aJxx4Sj5XE4w6J50OtIWdQunGUbvwh2VhO
NgMQxcdUAw9fECFIAEMHraPc0VHuMJQ72JReFJRvop5LUG2fMGN4jnsCApy2a/5PwNCVQK4n
yMFcJn6DKe+euaPYcfsOMlJ0tPkLitrY44n/Ia2Q/oiZnqlmGIlkgG9HKcoe9qKVvZCkOlDE
NCVVLAXQNQwDoTa46hfqACvEvdrB0nBPHBhvpAe3ndTGYRi+HWf4gbTFGlnUIs4K1hFnIpdx
VrCPOBO5iLOCecSZyEWclcwFZyKXcFawjjiL1lmcFWzTnrgD7GZXV5Ht0KNSMC6osqGintnQ
/NBRL3iPGy7yuQ3P+496wX/8IEQ+80Hk3Ue94D5+MCKf+WAK7kUvuZcPSuTyB5X3HvWC9/jB
Re+FDy7vO+oF338in+YnoJ6D/GQhhIy/L0ijmwVwZ/0rYuf/AwC8UdesCmVuZHN0cmVhbQ1l
bmRvYmoNMTEyIDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCAxNDEgMCBSIA0vUmVz
b3VyY2VzIDExMyAwIFIgDS9Db250ZW50cyAxMTQgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNTk1
IDg0MiBdIA0vQ3JvcEJveCBbIDAgMCA1OTUgODQyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9i
ag0xMTMgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvVFQy
IDE0OSAwIFIgL1RUOCAxMjQgMCBSIC9UVDEwIDEyNiAwIFIgPj4gDS9FeHRHU3RhdGUgPDwg
L0dTMSAxNTggMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M1IDE1MyAwIFIgPj4gDT4+IA1l
bmRvYmoNMTE0IDAgb2JqDTw8IC9MZW5ndGggMzgzOSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+
PiANc3RyZWFtDQpIidyX35PbthHH3/VX4JHsWDQBEPzxeLYvGXccO2OpyYMnDzodz1Yrn25E
OWn+++4PAIIkrOo6M02nczM6kl8usFhwP9h9sZw9Xy6N0mr5MBuqoVU1/NHFUFd1U7eqG9qq
a2urlp9nz19OTq0neqlW03r2/PuFVh+n2Rxero1Ty/UMrxxc/Tb7UPxQzo2pXPFjOW8rXbxZ
qDle9YV688o/U8vbxVK9vFncLpQqf1n+dVareQeKqWGQVzQceOEHNg0PvLiBofVQNcWixAn+
9vb7sqtsoV6/ffX6Ri3efbf8+eb9rXr34+37m+Xrd28X6oNavF68+4XngEX3vOhadTCArTVN
RvPgFIUql39PYqMNLRn+GaurvsfANF3VNBwY8rJB63m4RDeNVuXcubp4s7obt+rnzeHT/X71
WzkHy0L9MH0kZ26XM602amacrZpew8C4fKV1XelWzXVl1H6cPcxeLBM3bGurtjl349L//ure
Wle1PdtGC12HyMDU2rVt2IbGxQVqv8Hvx4fSVaZQi3F9oKsN/e4ela1cpeuzaMMe2c6CG5lg
z72IszYNzXq+C3XVDc5QSEw/xM9jwJGKxbbiceBZZ+y593WHb30o3u5gS/BTIdf6qnODSt6k
oXgcczEOf+Zd/Mw7jsJyLOdN1RbTAXa2UC9X5RzGLSb/mGfSunJdb8/nSgMAkoUkOp9Q9+z5
4sApMz5NPGRTDRp8OF2njsmi/Vd4C1syFP+EBGmLJ9in8V69Hyfapy8lbFOxPSjMJviihuLd
HSv78Vd4j6YZqt7qy3jqo/sw3BccBBbhKvgg1dkK+F38XD6XBt4oVryS/T9KjZP69UAi9AN8
kJAC8O1DrteQD2pOv5QB19UB8yWqpq3wUznKWrfXrLXuUnNtYeua9AXjIPFr0d44U5nj8JDL
/Ylu6zYd/9wc5baJMqzUnOoDbKKRzYHSzdE53Mo21Zu2rqw8O8r9cXa6S3Vn9LXY/Rs5bFs9
wEniVWMBQWcbI+gx8IIeIyvpIXSCHmMj6HF1gv5iKYMWSGMAtG3XQWCOZ4WOBxqnqAYmFZSE
uNbi9WMJHDl8gt9RvSnxnIOMqSFT7vDFka/hQEHebOi9exT25dwC2uCEMQ2eMJRVpoJt6S+o
wscVXlnPic+l7sEKRjcwyDStPgIJ2nD/DP2he/Xd7Uu1BGfpTC/74ie18Rm8/AsNrnsX4QDj
gu8GolY8gg2e1uAr+OeK8By4BsnXFzv/fE9lQ1/87skJjGpbq8AL4CMuAABVd56KUDXMrXMN
nkIwTg0z6OKcJ20PRYyRiOFVkRiCdSCGl2ViCPaBGF4WiSGYB2J4WSSGZO6J4WWRGIJ5IEYw
l4ghmCf7EoEB8XPtZeRzehrZnJ6GLqsnscnp6eJzerq6nA5IEEDQwJ7XMgjMnwCC6IPVCQg6
SvyAgYHvPAQG8qbHGfDpna9L8HpLZHDgO79wZEOdVnZ1wgdIeyhM8OewoevHssWBNS6tumAA
ZPi3McDhnokMYFVmQN46MoDlKwzI20cGsCwzIG8eGcCyzADBPDCAZZkBefPIAG8uMiBvnuyL
OaZQ01wGPiOncc3IadxychKXjJyuOyOn68rIcvLXUAX0Scd4zP6BU8FibzIkAAhHLR68mFAO
EwryA7/vldqu7thgxGzpIfkg4bGiRxTgO/cs77ERMYQDVCUckCd98CkgCUp2TWUAomaCYRv/
u6InH8Gr3qtqvXqkWwjEQwnFoPPCXh124G+oEY5dG03psUOwssVmS17rYr3a+ysKQUNMGYgp
l3WBPWWCR8vXgQG+tFjXXYKBVRkMeesIBpavgCFvH8HAsgyGvHkEA8syGATzAAaWZTDkzSMY
vLkIhrx5si+mv1IcCHoa2Zyehi6rJ7HJ6enic3q6upwu8sF1BruEJvDBdDEXLX/PTVIaUII1
VB3Qaa2+K+EbK265JniJhQOmjYWk0ZDjkDU+KRtKyr7YYxrbIknNPBJ0dEN7NyaoASwe2Ziv
43rzQJXJpjTwu8b2AA5wBSjowK97Kl/Qwf0ItQBZKpZ2PMApFkzEQs+TIfZ8PdBR2UO4obtQ
bDj/0k/qiXUCHlQk04isNMXhmVptt4GXR/vpZG7t4kIdz71Cf3XBv+SuK9ab1WG8V0SrgYsu
ZKr/T91RiXOoFSwYYpspfrDWanEuLsBanuxuxEGhjisxKgf6/QSRbYv7/YqUR7o7pR/suW7c
t9PP9fpKa+RVkX6CdaCfl2X6CfaBfl4W6SeYB/p5WaSfZO7p52WRfoJ5oF8wl+gnmCf7ElsL
12Ujn9PTyOb0NHRZPYlNTk8Xn9PT1eV0mX5wwqfV0SX93P8J/c4KoUgd447EG5h4DRPPMbGa
SDzjX/LE8x1fH4jnkHg7Vvh++zs2dS0FDO9Xh+iE0AUSLJO+bjVNO37ABORrrjgtcZBK19gg
Yul6ss4mrtMDDzrDAzkJbt3xf1qm86P2vo5tuI5teZGDr2N7WllziUPT/hEcwshyMehVGYd5
64hDlq/gMG8fcciyjMO8ecQhyzIOBfOAQ5ZlHObNIw69uYjDvHmyL7GYApy0l4HPyGlcM3Ia
t5ycxCUjp+vOyOm6MrLIwcZBxVJf42D7X+NgUrCYWJjVfezXMCmhX8NOjcGHuUs9oGH04UVE
Xx/RV59T9n8EgnGN1pxA0BAEIXxHDJoEg8YDy3gM4kKh3ISInBaYJiIw1Hy+RuTSz3ni9Ug8
KvkcUa7PUe4PFX1NCzvXS5Tzqkg5wTpQzssy5QT7QDkvi5QTzAPlvCxSTjL3lPOySDnBPFAu
mEuUE8yTfTFyzSfIaVwzchq3nJzEJSOn687I6boyskg5O/TY616hXPdnVHvGRje6hHLdGeVa
TzkbKGePlBuwvcUnO6RRl7S3ES5HwjVMuAEJ56ufIfKt868Q31puaq2nW2hpwZ+50GH2xw7T
E3tbYgO7KmnCke/U59IYWBA/fXra0FPsNPviI/1OUMA2vp0lcYcsBLwAtQSa2wRIRMbOl3KW
S7mOFuMLuY7obL8CcV9Lt7q70tJ6VaZb3jrSjeUrdMvbR7qxLNMtbx7pxrJMN8E80I1lmW55
80g3by7SLW+e7Mu1llbS08hea2lFPYnNtZZW0tPV/UctrW3qk5a2MTEltS8w+iPlgF2ciAaS
gdNzoMKiwyqL7g70+wnJZnyJgKJiFRMVSg/+N9Iwj/wq26kHpOOAuQepUOwg80PWCTTsIw29
uwQ7GFzd72BurHwe6cFErdhhP65gUI0uPY3jHnF7Uv+4hAtfwNAVTwhJR/Ya3MQaKgxyTgRY
j7b2m4hgm+FKV+dVkQiCdSCCl2UiCPaBCF4WiSCYByJ4WSSCZO6J4GWRCIJ5IEIwl4ggmCf7
EnsjiJ9rLyOf09PI5vQ0dFk9iU1OTxef09PV5XSZCLXDsqcJRMgc0sORCDclVAE6HMD8b7fj
sxkaEX8uq+yxTmgwBR/nfG5/IsOADcPYcGH4KxzQkQMBW/txPW5+9aAhmtw/U5sHmACmXoOL
HUHBYQG25/dW/N4hmCnorcatyhcvOraDYb4DVD0dWGNDV+AltXbID8cuANdWqbyZ1Bf4P1Gl
iH2aK57J/WcbJ2ySzo/8x6LMQlG2H7fjasIqT3GDCUVYSZha8d09G3B3CXOesK/RR/ZrnmK9
2+9HjH5XPO2I1BBG3JO+8Hcf+R/tcE8ng/E7zGVZx2WZf3vH5eOB5NPOtklbxC/TiF1rhw7r
Or4bOAvlWYcufgtndXOl8vKqzNm8deQsy1c4m7ePnGVZ5mzePHKWZZmzgnngLMsyZ/PmkbPe
XORs3jzZl1i5tMNl2C/ENKYXYhqxSzGJx4WYrvZCTNdyIYpINRY+2PZYZNUmprInqv4X8eWy
GzUQRNE9X+GlLUE07bfXUSIhsUCBHxhlDAQNymgy+X/qVlW37bjKA2zYYNK3q6afp+viXvb5
Tj44vXXdCF4DeKVXvZer3tFVZ1/Sqmcp5WL3YsCCupY2n0CAAgsAAgE7fB2WCueH5AOHaAQ7
GsaXIuQP2QE3c8BVxmeE06KrTje8kQuO1gvGVzLyWRbxAgiWsLjSS6Y1y3Jc8qideNTKOF6o
Iivh13p6Nmh1KSX+fSTsdFJ00qQPe2ndc2umDEOgMqwFw5pYe7bCMAqUMGZUfG1W2F9jOLH0
UzHQEmHWn4sP/MwsoFXd1A1QNYeW4u6PyFXWzXTmVuRS1SWXEx3JpbJPLic+kktll1xOeCSX
yi65vHAll8ouuZzwSK4Y7pHLCU/7Uk/1I/Uc2rcrb+vTytr6tHSOntbG1qfJ2/o0O1t3cRZo
4vSf6zgL/x1nkR1aGtaRZmFHNxWu7oGuPIWnYrGVSq3iyrDk0pVrQBpBw6NDF6lPm3xBq2qY
6mSlJpvZVsxszWaWgcTGtGP80LpylST1b+rK9pL7aopn8DHkZFe52w8OHLP7Aqt0V2DAt0y4
6370b5AThv6m94gjogscOzbyRlQfN3Z0pI2oLmzs4MgaUV3UOMFKGlFd0NjBkTMa7GHGDp5t
RRWrJ8OHevp8QS19vmamPlsWS5/P3NLnk7N0nzI4m/1EGVzex3fzYiCADm1eymeizEeYvMAm
B7ZxzM7P0uWV/74UOOpskg7Szle+yY/k4LQlkxRnXDsuddBId1LKl5h3Czpv3SG7vlf2h/B+
3+H/LozB/FiAgeN7xWL0igydmn6IscNIxIAqVDaqLABUJs7tlHNPL4zKTD4jYaIj5vTsCpGG
CjFMpufq5TSOZ+3/DfUQF0JUsxB06NfAHPQDxLg62i9LtW4q1Tp1pwWcJmqwng0h+85fAHmj
rafTE7dyFdZJFUarguoO0Oc+qNsqzACfsSij8ey48qt5rCXgioekorGuqzYeVRVm7Lu/E3N5
u6Ql7XGom39ylYGIkN7QNSlF9VFpRydWirwBSzs+0VJkH5d2eOKlyD4wnfBITJF9ZNrhiZka
7kLTDp/tSxmZ2tDbvVR3DX3dWFuNeyrq5p4av5xkO3nacpG3t9xIn2Q7fToRIm+eCCN7ku3s
6cCIvHlgrOxRdrLH8yTy5nkysifZzp6Om2bfOm5G9iTb2a/I6zeQkFXTG0hTLnf6BIJGxJ2v
P5d0kyYi0W8BBgAu5aXbCmVuZHN0cmVhbQ1lbmRvYmoNMTE1IDAgb2JqDTw8IA0vVHlwZSAv
UGFnZSANL1BhcmVudCAxNDEgMCBSIA0vUmVzb3VyY2VzIDExNiAwIFIgDS9Db250ZW50cyAx
MTcgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNTk1IDg0MiBdIA0vQ3JvcEJveCBbIDAgMCA1OTUg
ODQyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag0xMTYgMCBvYmoNPDwgDS9Qcm9jU2V0IFsg
L1BERiAvVGV4dCBdIA0vRm9udCA8PCAvVFQyIDE0OSAwIFIgL1RUOCAxMjQgMCBSIC9UVDEw
IDEyNiAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSAxNTggMCBSID4+IA0vQ29sb3JTcGFj
ZSA8PCAvQ3M1IDE1MyAwIFIgPj4gDT4+IA1lbmRvYmoNMTE3IDAgb2JqDTw8IC9MZW5ndGgg
Mzk5NCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIicyXTZPbuBGG7/oVOIIp
iyY+SR5n7dktp2Ztl6U4B9ceNBqOrUQeTUnyOvvv040GAUqDVlKxN7s1VSOJLxtAN/k+aPyw
nD1fLrVQYnk/6+veiwb+wpe+qRvbeNH2vm59Y8Ty8+z5i4MT60O4qRGH9ez5TwslPh5mc7i5
0U4s1zP85uDb19kH+XM117p28m0197WSNwsxx2+dFDcv4zWxvF4sxYurxfVCiOqX5V9njZi3
oOgGBnkZhoNVxIG1pYEXVzC06msrFxVO8LfXP1VtbaR49frlqyuxePPj8u9X767Fm7fX766W
r968XogPYvFq8eYXmkPpkAF8aNNBtpinC19CniGdJqXTxHS0FtXcuUberG6HrXg3bIfVYRA/
Hz6GQa+XMyU2YqZ9UzuvYMS29lb0ru46MVe1Fvthdj/7YTmZ3jhfW3s2fRMmxjmlqJb/wEfU
XXxEtq11Q7EpQjUU0uDUynk/VtOGvEKKKib2brivXK2lWAzrY/i2Cf93D8LUrlZqzC/MCJkZ
W8O0pm4gsaa2XcqMW6ryBh8pBrnad+U85/AITWumC07pxHe0qdve6VBN5fv0gvQ4klxsaxoH
rrXanCfetHjXB/l6B08RX5aQVVe3rheTO8NQNI5+Mg696G160Vsq4HKo5lASeThW81aKF6tq
DuPKQ7wcXzpVu7Yz53NNCwCSARudT6g6WvniSKYZHg80pK17BWs4zVMlu6hol2t4mr38F1jE
y0d4xMMdvLyH8Ii/VPCE5fYo0E/wkHr55paU/fAr3Bem6evOqKf1VHn5MNwXHASScDW8j+Is
A7oX37TPlYY75Ioy2f+zUjhpzAdesa6H9wNeMa0AOyK8XJNX7LIKr6fySdW+xlcly0r5S9FK
tdNwhS+5nd6gnaq7ho3XTtc6D+9M8H3WTeOn45+Ho+xtkiFTfaoDSHrNhwOnbV4cPko/1S1Q
yfCzo9zl2cOvqe7g+oXa/Qd58tggKVI14MM+fTAlfVr4kj6tbFGflK6kT2tT0qfZlfQL4IOZ
DXLPd13aRgNDTNpdIkNUsCBmKl89VB0C6vgpfA7iplJNMA1MLcPeU0HF5BB+4y4UDD4IMJdC
PoTrdJH+U+RHGi58f0aO03Wrmu4JcRo9Ls9oWh6sBTYymOPH6xdiCUvFYW9gQC3fi80BplYd
LAl8rWEFD+HmOzS5lqvjjr7sEYdO/laB0/qRisAf76dUBPg0bZfY8kFCYzA3zlncoWDiRuEM
58DwPSzFckiIKosEJnpEQpR5JDDxIxKizCKBCR+REGUWCVx4REKUWSQw4SMSxnAOCUx4ei5t
JkLB85yeK1vWc+kYPdWmrOfky3rOrqyD5xmne3iB7SWn6z+J0yebOK6zT0YPPYZAczs0NC70
FnsmmJh+bSMBvKSbAgF2dMsjfRw38fdDGC4Ogx3ad3V9a+tWs64nlXd9OTq5nuQLri/HJ9eT
zLu+HJ5cTzLveiZ8dD3JvOvL4cn1MZx1fTl88lwSE0quZ/RpZUv6tHRFfVKbkj5NvqRPsyvp
vOstND46ux4CRl95ep8N2sHL7P28kZpgow5thG6xUqzEdnVLAcFy0KLDAui8ecHNukusidt2
4ATxAwnhAy3w/ypc+RjmJVWsVw/hJ8x0jxhyUdiL4w5WFOZd/mVy4gpTKproa6UtJLLZ3uGy
lVyv9vFbSNLCuDdVD3e8PyWAruFoYb6BAFBLHgBB5P1fjE32D+oF9xejk/mDynu/GJysH1Te
+eXg0fhB5X1fDE62p2DW9cXg9CiajAQom/Pn5S7ruaBlPdeM0VNZynrOvKzn5Mo6b3p8XN1k
q2+T/Qy9wnay1QdP2bjXt9hJV/BqyetqjiZ7UbXkFISBwr39/ehDG3zYyT06F5uF5MYJBaxN
FFBpGSouA1sDgzszWnRYb+7BiVZuKg3/19jRVwAmcD+0OvIOF4hfhv0A23qIFCTtaACau3nS
SqQzA2IIp0Wqedr6W+ogOsJZmzoIF296Lx5JD2cEaD8OA6JQy+MzsdpuRxzm+MMJj5RLKTua
O3RKStL/HR081pvVcbgTAVW93IQ8nRTxMxxtwrlFrCB1qPJ0hqfP9naISA5PBcY94Ro8WmXd
N3BN4UvPgo1Unmzl6IQ2ki+wrRyf4EYyT7dyeMIbyTzfmPARcCTzhCuHJ8TFcJZx5fD0XGBT
7qLq2kLly3qubFnPpWP0VJuynpMv6zm7ss5CztnupLN5agT3f4PchDa/A+TOWpyEFO0yznrC
mSWcOcKRTTjT8aaIM4c4M0gtwplDnO1Iod/b3yqF/BPh2AXHreOUrhHq89OTmoktV2BiOKtV
cw1LWB0OO7pAoKPviDuDnRnMgOcxET8D7jiUP2nv4Hx33MV+7pY+MXU5dqVjr/ddGehcx/d2
JLIELMeOACSV5185esQfqSz9ysEj/Ehl2ccER/SRypKvHDyCLwZz3CsHp0fR5t6ogD1OzwUt
67lmjJ7KUtZz5mU9J1fWWexZeM1afwl7/o/Ank5NVtOlgxceE+HghUcu4hx2NeEwp4l0+CWR
rvtzkQ4WMT9tH40+4ZsOfIOiZcLpCeF0JJyOhMP0oGGEOhwKKC0/ytjv/b4dnWuaWlsWZ6Ty
PCtHJ6CRfIFo5fiENJJ5ppXDE9RI5qnGhI9YI5nnWjk8gS2Gs2Qrh8fnYvsenM6jjdPHynL6
WDpWj7Xh9DF5Th+z43QebUbDwi+hrf1D0GbSMtoJ2toztPmINjOizWS09XhSxSs7hFErM+YS
WzLgLAGuR8B5wluf8NbGWwLePJ1KTYTbeCaF9cynHDUBCfMpnLcVnjtXVZhmoF/ic6U1pEFX
Hx834eoDdKud/Bj+H6A1tfEUGsQdAhDYAoA6OZPaCYNGcpW4pf0Zt/5LZFmLdOCQFVUWWUz0
iKwo88hi4kdkRZlFFhM+IivKLLK48IisKLPIYsJHZI3hHLKY8PRcoELZ8f687iU1V7Wk5qIV
1VSTkppTLqk5o5LKQsq09uTYCZfGJsXSC99hd2FlRtVNFXsWQz2LJVMbMHU8pQAlBPUnYOIK
JXEfeLEnXuwo7HOl+og8vHO4SC2bqOVpXV8COB5xRC/RkMfKgLf2wwqMr9Bvj8OwRxwGfNlx
/Cd9irGZJzHnux0w0UOuD+FwC6CQRxpYp4FPzK9rA9b+35sW01n+CEYi6/9y7Gh/Unn3l6NH
85PKer8cPFqfVNb5THA0Pqms78vBo+1jMOf6cnB6FCYfYaBs1p6Xu6zngpb1XDNGT2Up6znz
sp6TK+s8AkyPfYpNfcoTq/XZ/FeVQgej3wT+2+0egrlE2BOh84DTxDCCAHdJ7Bi8vGRtc7K7
rofNrwCYocIm5+4Zmhd+ifVuvx8OgROPMGUv7zb4HzZyeXrI6hO/1OR442AwpJTcHsJ+j2zq
iUNKHsWX8PMQmgA87rhk0YnBlTHfYHDbX9jio8pbvBydPE7yBZOX45PLSeZtXg5PPieZNzoT
PjqdZN7q5fDk9RjOmr0cnp5Ll7ZLKJ/z54UvyrmuRTnXrSynuhTlnHdRznkVZd7mDez0frLT
q+SUnl5khS9+Lxv6wHfZWkeeV2jx6KSe9vuutN+DmcJhRGzuobmGT2zvnVxUWr7jGDA/7TtM
hA7YEN2+o48BW3MnD+BcbB3i1aP4iltyh/2IDt09irgEhQchuonWPRlkKw4xbHNcf6qou5kw
xOYDhooHjLvVEe7DI4bG0kQahQYEaKQw5btNuCP++kgfgsJ2WDA9/vpE2gDFAbxoqI4HpL79
zsBRoFsWOKTywClHJ+CQfAE45fgEHJJ54JTDE3BI5oHDhI/AIZkHzr95L7fdNoEgDL8Kl0RK
LHbBHK6jROpjRDFpLFW2ZTtpHr9z2lkwM6hqpN4Yw7//wJ6+nbHtChyxu8Cx7TovcH62K8Rx
9Dyytp6HztF1bGw9d97Wc+9s3eVObId5heFxJ/wv7kxy/6gfUw2zDKSnhKGCLXaBPdstMht8
NkJVA6kTVjVYFhyhPKg2KR+pbtOcoGULFi0NxcWiBT5MihbqAIakCqkpz1S5wGuenx6hj/Uy
JflWzRG7wa85WHT5YHsTHlj16WC7ExxYddlgmxMaWHXJ4JgFDKy6XLDNCQti9qhgm3Uq+tWa
w9PzgNp6HjNH12Gx9dxzW8+ds3UfCtCorzIUYq/7MAoUYgbBjzc8Mbd5E8JmgRfDaYz77XTa
Yw2CZ25PCMAyAbChO7mnnQwlw2oVstVDv9ryJ7whfyJub9yZuL0jbsKXYneE/AErBihBMCkB
5ACAeBNTk9M4njWloJia3ghmft/BXmkgFajKPcKtLl/vHjoI+V7I/QWpAt04YPIQART0tJAr
Gkd2FAf585XavLPlRL8FX6SNXM5IBSWK5D1xq5OQRwARCOGAOcAjBhGM8cuB+LqDTIj/XQjC
4/mT7nBigG17vhvnFVqn/K9nFVrNfI/E9ythvYMYR9b4Fon/Qf+wWKulWKtLqhNbYvKEvhPQ
V1rUxnb21pbfurVOFUwlw6IUBPR3IXyDu02zUgqK6pPXdit6WV5hr+1X+LLs09e2K35Z9vnr
2BOAWfYJbNsVwWJ3GWzbdV5qLaja4XbUl1oe0aWWh8vQdCyWWu7oUsu9WGouaENLfzJoFUS4
Iwi09S1o6xvQNrSfuwTalkDbCmijgHb8pIfjKmSbOldWtSIGEVsRX2vcLkTXDt534I9BvA6w
E7fUjCCL7fgxkoha7fCboc3xeJrhJmiHg3R4j5kXfPYOIPN6HXf3t5kdwLJIjWYQ5zNC9vpl
RHw05eE6x0O9adphmOPhL8kQumbjgoFFlwu2N2GBVZ8KtjtBgVWXCbY5IYFVlwiOWYDAqssD
25xwIGaPBrZ5MhV1ymiadlMZw23p0wG19OmYmfpkWCx92nNLn3bO0n1QBEjh2gyKoAdmaLVM
g+VTNnyZQWPAxQwnMKY0Y3E+cpMPuscKJ9COKnb8fMSECg5c2H/ypOAQVEgNpdipIoqTuCtg
wbTqVSs6quMobwglZgtAj/2Brj/pt7jy2R/KX3eYR473qcYMlA3Mc4EZArb6on7IHMCS80DZ
V5QMjZImSB8HvYeMjcNTfXqQP1/J9Z7an5Iv/ZGWcuHMDQxvyaBPlpkPUytMqPX8dPeAedLj
AlpbRNW/QCv2m9i41GLVx5btVm6xvAIu26/kYtlHl21XdrHsw8uxJ3qx7OPLtiu/xO4CzLbr
vMAZ2i4JIHKPMTyvLcqUsrgyo/Z7k27HThPO6tp829GTbkdPy4HVldVgB0+6HTwtFlZX1ooT
XHQnuCwlVldWkh086XbwtNAkuL/O7OBJt4Ovq38GABlH6F8KZW5kc3RyZWFtDWVuZG9iag0x
MTggMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDE0MiAwIFIgDS9SZXNvdXJjZXMg
MTE5IDAgUiANL0NvbnRlbnRzIDEyMCAwIFIgDS9NZWRpYUJveCBbIDAgMCA1OTUgODQyIF0g
DS9Dcm9wQm94IFsgMCAwIDU5NSA4NDIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTExOSAw
IG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9UVDIgMTQ5IDAg
UiAvVFQ4IDEyNCAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSAxNTggMCBSID4+IA0vQ29s
b3JTcGFjZSA8PCAvQ3M1IDE1MyAwIFIgPj4gDT4+IA1lbmRvYmoNMTIwIDAgb2JqDTw8IC9M
ZW5ndGggNzUyIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJhJZNb9swDIbv
/hU8WsOsSrIk28e0TYsMXVPUGnYoeshSp8mQJYWTbvv5oz4spJvVIYBN+RUfihTl+NxkZ8YI
4GBWWUMbDQx/zmgYZZJpqBpNK81KMD+ys4uDguXBTWJwWGZn1y2H50NW4GQmFJhlZi2F1q/s
If9MCiGoyu9IoSnPb1oorFXncHMZnoGZtgYuJu20BSCP5lPGoKhQEQwhlw6HqwhgIT24nSCa
N1TmLbEBvtxek4qWOcxuL2cTaOdX5uvkfgrzu+n9xMzmty08QDtr548+BiZd+6QZVSXjUAkq
a97YiC4XLYeQTQjJMSBOylW4A96lVJjMDC1Gq3xFuF3CkRQKR2uCIJl3pKjt010wfgcZ1vsA
ehmAq+FJH4CwCM7Dg2HCa4AMcJeToBVnNRSccqX1UDsea8dDIss1lkrni527PbtrZxdb5gei
qMg/YhS7nu3iW7eFvtt2Cy90sPEGhLH38qAjbsSwFPPBRZSlje3qyUsf/EiUy8JmZ+014RbR
wX6LoyfYhTGxaf72AzsPwsT9C7x0XQ9YazGA+tg3mLqUMXVWxrapfPSr6QVsVgT7b7n3FdwR
7fIuaZN3/U83WlgsJrTxw84WItbbKtvTgCe1ZlUMGNLtu2NnQ1RIcxHL3A+xkvDqrAORNsiT
Vz2ZlxSxJUiquXTHAMvNqtrhPRkPS1EqJe1u2O7AUyqD99RkHDaQ1Q3VNbZ2hYcVuxsKd+27
bPWehOeeay8JTZU41TjXST/Oq+jIS1y5PFWF4rRm455CCSoCVZW0fiOWTEfs345W09JrmJF4
KzaKNiLhaKsVVqMlfaNJzbHW435WG/LX7FRRgicr8542bIRubKm9qqp/ZDz1TCadx9VhI72a
3stE6KiP0+N2e/mdHU/woz7Oj03h5XRfJPBRH8fH1vFyuntS+EFP4IcG83KyxxL0qI/TYxsG
+ngnJthRH2f/Rz43qc8Ehv/D4TOB2fcUvozMd/su+iPAAHC/waQKZW5kc3RyZWFtDWVuZG9i
ag0xMjEgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDE0MiAwIFIgDS9SZXNvdXJj
ZXMgMTIyIDAgUiANL0NvbnRlbnRzIDEyMyAwIFIgDS9NZWRpYUJveCBbIDAgMCA1OTUgODQy
IF0gDS9Dcm9wQm94IFsgMCAwIDU5NSA4NDIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTEy
MiAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9UVDIgMTQ5
IDAgUiAvVFQ2IDE1NCAwIFIgL1RUOCAxMjQgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEg
MTU4IDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNSAxNTMgMCBSID4+IA0+PiANZW5kb2Jq
DTEyMyAwIG9iag08PCAvTGVuZ3RoIDEzOTYgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0
cmVhbQ0KSImcV01v2zgQvftXDHKiFrYqyfo8qraTTRonhqW2WAQ+qI6SaOtaQSw32H+/M5wh
LbvJoljkQIscDofvvRlOPpaDD2UZgA/lwyBzsxg8/NM/Ms/1Qi+GJIvdJPbGUP4YfJjsIljv
tJEHu/Xgw0Xhw+NuMEJjL4igXA/oV4S/Xgd3au6MgsCN1MIZxa6vrgsY0a9UwfVU5qCcFSVM
8mJWADir8mrgwSjBlcBDJ1PtDqMQx0HIjoscXfuZG6rCoQM+31w4iTtWcHkzvcyhuD0vv+bL
GdwuZsu8vLy9KeAOisvidsVn+IG+AQ72mlGKt+Zr6tuM+VA+b1k/4HmeG6v6pd46owRPXtc7
7WtWDnxoYKA9+egoceMQoshNYeS7AbzUg4fBx7J3ph/i4umhHh2nwCn/Jkri/6QkjO023uHR
UX4UxwQZkzE2mPkx3wEA7uaL60JTECtkYDWEMxygeK7XzihF/Bq65hhXG5mouqbdng0h397X
L7xxxysytNshTNt2U+F47owiN1O1gxGEanP/A+kP3UTRmoaq/IOD8zMbXGCD07sjpU8JVH1f
d109hBIDQkDVU8veMKQd4Z+pIbw6pIDW8cym72jiKWi28Cwz7aPxJ7vMZoe4UZAbw2YDfpZl
rtUg4hmGGk/PCuE9sP3E3ueAdb6c/LmCmQvLVh+aqBpxyF340sg3xR8jOlX3RBAtXZhUmw0h
ejbfb7rm+aXt2jXbthu4rr7Vm2MgDynnp/bk4tVJMceaTnMYqSfiAyndPkL+wvl3stLVMtHt
xaDmFWT+K9KSUgA8I+saafwkrBcyJ1inGmvyJoPGGnP+ij/37GjzjxMQsQR76tprnYJtJWNr
gJf1MGZ5jLHSeFhMVvDRhWn1s0HhXBFusXLptAwLTkVoJxS/1uh2zeto+cmFuXxNNu3jk5iQ
k78cP8TQjZNl/V2XnQSR8/DUrhbboRgc2I412xcESGb3H3P3VoYid5kiEdCogUOEFq5NsbPP
kneSZNCajBV5aAdC/ZgJDjX1zGOkGgfjfgKNXKrmluGIGQ6VpDkzHGqGf82JkdGc3OCge1aD
b9TgS+alSgZ9Kaz7Rf3c1ZzTgfpWi/GwL4ejRHtXGG8FYYQR0RNEyhix+y+LFdy4XGpCxJCW
TJ0KdJ1CAV1xoJVeNWvt/vgaCCNJGwoXPrUHB/d7e5F8aDI91ZkeHTLdBHciCCtx/yBxJidl
chImJ+PMill/sSlnKLAzKvCwl2Wd8ZpnyhD4suDSkBh9xKyPhAytDk6PYh0kvUzPDLeZZHps
4jFhnEvN/SZm+0p+6JyPrN3xo2DzwYuZZjAluUe3l/R00CvHR7oMrKfoIInZzSRf9AtyoFMU
UzzCnzpFo0OKj3WKJybFI05xNJi6mj66TfX8TGxOtaBCkYyUGEq0EHWwrdZ8lgw8K5UhsseK
g/q+ld0mila7fHV8EqOJ4dfsYAHZe/uHe7PWdA3yae91ox+hSbvtqqEIRkpHV2lZyDtK7dRs
KzPtfV8jIWtkzBqJDvZWI5HRSCQaCZQMQ4njij/37IhfA3rUf0cTqdXEu1XhrQ7jTlqM5aqH
QK+44uS82jS2v9DFNtEdjWcrbdCvtFRbuzUboV50xrXbk1amMp1L/W4hfaN/WNabCkEhsOGm
7rhXIHXEog0pRYl5pCkGUkugjowsJ8KI1OPE7CY+FNzih5JWo2u5HP+fYvxm5p0v8/mMQwzV
Lati+WnVb3h6LFB9rrkoj3V7pIk5fzEd4Unm/HY/xK9qap4gRMb0YvT4iY2p0Gc5FzHfNDxC
ImqBLdvTRojVkZ70SSCNnHRIvKabOvviYivUb+2w+U+5+WfEx0H0FuL4X8e/AwDPIhzsCmVu
ZHN0cmVhbQ1lbmRvYmoNMTI0IDAgb2JqDTw8IA0vVHlwZSAvRm9udCANL1N1YnR5cGUgL1Ry
dWVUeXBlIA0vRmlyc3RDaGFyIDMyIA0vTGFzdENoYXIgMTUwIA0vV2lkdGhzIFsgMjUwIDAg
MCAwIDAgMCA3NzggMTgwIDMzMyAzMzMgMCAwIDI1MCAzMzMgMjUwIDI3OCA1MDAgNTAwIDUw
MCA1MDAgDTUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDI3OCAwIDU2NCA1NjQgNTY0IDQ0NCAw
IDcyMiA2NjcgNjY3IDcyMiANNjExIDU1NiA3MjIgNzIyIDMzMyAwIDcyMiA2MTEgODg5IDcy
MiA3MjIgNTU2IDcyMiA2NjcgNTU2IDYxMSA3MjIgDTcyMiA5NDQgNzIyIDcyMiA2MTEgMzMz
IDAgMzMzIDAgMCAwIDQ0NCA1MDAgNDQ0IDUwMCA0NDQgMzMzIDUwMCANNTAwIDI3OCAyNzgg
NTAwIDI3OCA3NzggNTAwIDUwMCA1MDAgNTAwIDMzMyAzODkgMjc4IDUwMCA1MDAgNzIyIA01
MDAgNTAwIDQ0NCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw
IDMzMyAzMzMgDTQ0NCA0NDQgMCA1MDAgXSANL0Jhc2VGb250IC9CUERES0grVGltZXNOZXdS
b21hbiANL0ZvbnREZXNjcmlwdG9yIDEyOCAwIFIgDT4+IA1lbmRvYmoNMTI1IDAgb2JqDTw8
IA0vVHlwZSAvRm9udCANL1N1YnR5cGUgL1R5cGUxIA0vRW5jb2RpbmcgMTM0IDAgUiANL0Jh
c2VGb250IC9TeW1ib2wgDS9Ub1VuaWNvZGUgMTM1IDAgUiANPj4gDWVuZG9iag0xMjYgMCBv
YmoNPDwgDS9UeXBlIC9Gb250IA0vU3VidHlwZSAvVHJ1ZVR5cGUgDS9GaXJzdENoYXIgMzIg
DS9MYXN0Q2hhciAxNTAgDS9XaWR0aHMgWyAyNTAgMCAwIDAgMCAwIDc3OCAwIDMzMyAzMzMg
MCAwIDI1MCAzMzMgMjUwIDAgNTAwIDUwMCA1MDAgNTAwIDUwMCANNTAwIDUwMCA1MDAgNTAw
IDUwMCAzMzMgMCAwIDAgMCAwIDAgNjExIDYxMSA2NjcgNzIyIDYxMSA2MTEgMCA3MjIgDTMz
MyAwIDAgNTU2IDgzMyA2NjcgMCA2MTEgMCA2MTEgNTAwIDU1NiA3MjIgNjExIDAgMCAwIDAg
MCAwIDAgMCANMCAwIDUwMCA1MDAgNDQ0IDUwMCA0NDQgMjc4IDUwMCA1MDAgMjc4IDAgNDQ0
IDI3OCA3MjIgNTAwIDUwMCA1MDAgDTUwMCAzODkgMzg5IDI3OCA1MDAgNDQ0IDY2NyA0NDQg
NDQ0IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCANMCAwIDAgMCAwIDAgMCAwIDAgMCAz
MzMgMCAwIDAgNTAwIF0gDS9CYXNlRm9udCAvQlBERUVHK1RpbWVzTmV3Um9tYW4sSXRhbGlj
IA0vRm9udERlc2NyaXB0b3IgMTMwIDAgUiANPj4gDWVuZG9iag0xMjcgMCBvYmoNPDwgDS9U
eXBlIC9Gb250IA0vU3VidHlwZSAvVHJ1ZVR5cGUgDS9GaXJzdENoYXIgMzIgDS9MYXN0Q2hh
ciAxMTcgDS9XaWR0aHMgWyAyNTAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAyNTAgMCA1
MDAgNTAwIDAgNTAwIDAgMCAwIDAgMCAwIDMzMyANMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg
MCAwIDAgMCAwIDAgMCA3MjIgNzIyIDAgMCAwIDAgNjExIDAgMCAwIA0wIDAgMCAwIDAgMCAw
IDAgMCAwIDAgMCAwIDQ0NCAwIDUwMCAwIDI3OCAwIDAgMCA3NzggNTU2IDUwMCA1MDAgDTAg
MCAwIDI3OCA1NTYgXSANL0Jhc2VGb250IC9CUERFS0crVGltZXNOZXdSb21hbixCb2xkSXRh
bGljIA0vRm9udERlc2NyaXB0b3IgMTMyIDAgUiANPj4gDWVuZG9iag0xMjggMCBvYmoNPDwg
DS9UeXBlIC9Gb250RGVzY3JpcHRvciANL0FzY2VudCA4OTEgDS9DYXBIZWlnaHQgMCANL0Rl
c2NlbnQgLTIxNiANL0ZsYWdzIDYgDS9Gb250QkJveCBbIC01NjggLTMwNyAyMDI4IDEwMDcg
XSANL0ZvbnROYW1lIC9CUERES0grVGltZXNOZXdSb21hbiANL0l0YWxpY0FuZ2xlIDAgDS9T
dGVtViAwIA0vRm9udEZpbGUyIDEyOSAwIFIgDT4+IA1lbmRvYmoNMTI5IDAgb2JqDTw8IC9G
aWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMzQ3MzMgL0xlbmd0aDEgNTI3NTIgPj4gDXN0
cmVhbQ0KSIlcVQlUlccV/u7M/O8huAM+olYePFmUhyzBDY0SHw9RXHAXm0QeKpsgT0Wj1gQN
Lhxwi3XtUaL1UExI9WGqUWMb9GgaReK+1og2GpdWa40x9qhveiFtT9L/O/9/7szc+ee7d+58
AwLQCosgkT5yTEz86GFj1wANZdw7Ykqhy/10wfMfgBMFAK2YMrfY+t3wq4t57BpgPprtzins
Pac6BvDZBhizcwrmZx+eH9ASiFsBLNmSO8019Uvfv7J7w2X+9MrlDv9u7aqA1gHc7ppbWDzv
h/Vxu7ndBwhILCia4hIlv7ED+yK5nVzomuf2K6Zf8/xc9rfOcBVO67TSsRY4GcR80t1Fs4uZ
Nz/1z5rG3bOmuc9mRz0BQouBNkHGKmY1DMH8dpbr0AnQN/m9xe9d71D9wpgOmzdf35D+PPv3
/3mBMGzAB+iKRxSHI6jDUPwOryMd6zAYp7AbrTGf6qFgQzJ2IoyCIZACCxnYjCt4A7NwGzcQ
iTRcp/b8Hyfc6IC++h5/01CmD7CXLxzYhYNUQGMQw3aqsFMUr7xa18GCSN2gL3NrK25TV12L
VLa+RTtEoATvoz3ycUK/aMogslBNC+keQpCJCpWgyvV09MNeXKA0toZjvnG5xV4U8KwdZKE6
3ajv4E+KMI3/9B7KmPEe1Ike0mFsgxXheA0j4OLRX+EK+VOcTNIRepDezL3VeCyixBfSzDyi
MASTsRLbORsXcQvfkx/1pK1UwzhDD42m3U7DHCzgutrK2avGxzhAcRQnLMLC2bKgG8bx2GpU
8fqf4DSlUQbV0WFZZcR6B+oAHajvaI3umMgMP8BhXuMJxbIPryBDZbHqooqN+JeLOcKp2ILT
OMM8rnPev8cz6s64Kd4VJXqC3qlvMxcfBKMPRmESijAXb+O3vKtHcBT/pOeiBXueUseMBcYj
vZZzG45BzH0ke4/hf1fwLu3BfsZFjrIdWTmKPjSCRlMOraYNtJ+u0BVhEiFiprgvPbJeXlO9
DEMn8p86oAuva8ME5PIOvMvZXsvx7sQxHKdACqdojugiz38q+olkxg5xSlyXS+Vq9cJY5r3h
/Zv3uS6HmatsMOdhDj7iLPyDOjCHbpRPs+kbZr5G/EG2lm2lTfaUr8uxMkOWyXXyS/mVmqVq
1FVjiOEyaswu7wzvGZ2ml3AuCCbmFQE7EtCb6yebq2k683MzZmEhFqMcq7he1mIbajjuz3Ec
F/A1/s47AAphznm8eiFX3VJaxdhMH9NhOkbH6SY9bYIIZUSKXmKgcIgUkSOWMtaJ0+KiuCs7
yymyRC5iVMp98oqCUkob8YxUo8KoNtWbI82p5iyfky8evOz+MuPldS+8Hb2/9G7wHvbe0eP1
fOYfhmj0YKbLmeVmrsEqxkdcifvwBU7iUjPXxyTI4IoPIhtXg513bSANpiGM4TSKMY4xgSYx
XJRFuYwSWkTvUSktoZW0vhmbOLYq+pD2MT6lg4wL1Ejf0n16LLiIheRqDhMRIkb05UgdYrAY
KUYzckQRwy1mibm8Q9XiE3FAXJT+MkxGS5ecKTfLXfKIPC//pYSyqxjVX41XOapUnVJn1GX1
3Ag2nEauUWkcMXUyJZjGmfJNm0y7TXdNL8wmc7o5y7zQfN6sfcJYrf7Mce/FT58Y0ymabQSo
eaKRz0WQdBvLaRxnzCTGygK5Sp41sumRtNJVKpd5crreIVPEM1lE48XnFCqDjUSZjRXQVCNu
iifijgqkseIeRar36VNRJB3C1LSIcU4FqlLjLiAuIVG8Q3XimCyVpfqPSDQqqdGoFGdgVTeE
Pxr5VC8XG3nSVyJPVGCiSjCeI4/z/qExj/M9QJRRd3leVeK2tInv6BFtYNVooKGqq3hL9KUa
VtyX1AUPaCbctB5J9Bl9TftBtFNW0zDRknfLI1pRb77GGmQInZe+yGjiSOEikNLFIzFOHjKd
lj2JWCXOYgFJiuXa+e/jxQw+AetEBGuak9XkHMUjCBtZ7594DzUptnHZqOA62y7tGI1YvCnq
kchn4zZjIpYhHge5BssQKzZhoV5EU1n3h7N+CuynfMSQH6ulhbmV8H3RQYSyFk7mVZ+x/p9g
1U+jh3ibrHyy6hCpmkZWKCcrUybrbwVjKt7k1hasNe01zmEkWQBl9VZylV/DW3znfMPrd0R/
5jcJ25WdWVtZmWfyjC3eVCQxlqGeBN5hzgP4nKerVFbeDTqfI8zjO2oY34nHkac3wsF7N1qX
6gpM1tv1G8jBGL2T9Xeu3oNeWG5kiPFGlEpgjT1OR/k++gtVsG6n4irrURgF4T5jFzMaYHyG
cnWJtXOgXqEvIJDzEcoZyuJb9BYK8ZDzlirr8Kp3hKjVKdLNN1QjRulqHUy+yNUFrLyHUGU2
WHsWoYtRlZSUNHDAa/37Jfbt07tXz4RX4+NiY3pE26O6d4uMCA/ragsNsQZ3+UXnTh1fCbJ0
CPBv365tm9atWvr5tvAxmwwlBcHutKVkWj3hmR4VbktNjW5q21zc4fpJR6bHyl0pP/fxWDOb
3aw/90xiz+z/80z60TPpf57U1tof/aPtVqfN6mlItln306RRE9lemWzLsHoeNNvDm+01zXYr
tkNCeILVGZSbbPVQptXpSZmbW+7MTObf1fr5OmyOab7RdtT6+rHpx5bHYnPXkmUANRvC4kys
FfBpxaQ8HW3JTs8rtuQmBh4Z5nRN9aSPmuhM7hQSkhFt95Bjii3LA9sgT5uoZhc4/s16tcBG
dVzR+968fbshNl6bv23Irpc18g/zqQ1rCmxi78ZgGuIPZtd12jWYCOMmoeKT0kbBKDEkD2hD
2kYEEYRQmyLchmcgrWklZFQhlFZAq8qgfNqmJLSlTSBCUAmi+vXcefuW9UILrWr57J2ZO587
d86dO08uY+q1plsu4+vi3dB2X3/5oLFjwEsrEmVZnYHOjvaYKTrivEZuGdatMyd88+OJt6uY
PK82ti1dWyCMyMQuH1cNY5vP3N8YS9f6+TcexxymGowmjCgW3gEXNjT7sJbaG4+ZSi8W9PE+
eE/27lYFItySWOMzHwg8ElhtrEngYPINk5o2+Y/k54ePWx9SfsRntMQCfnNhQSDeUVfYP5aM
pk1HJ4V9k0ZqKsr7vbm2W/tH5yQLWdnphVUpnSzJ7lxqaEr5VWGLAotAB9O30gdLYgHsaS7/
rJpLxsq56Ia/uIJRZifOo8t8oDZheGvQ7uXxpivoDfiMG4TzD3z6yciWjmSLHvTeIC4yS1JE
g94pm2VlZmkpE8RdixOFjQtkvaqifOOAagbWen0QcB89Dt92xGsq4Xy/n493+0CYVqBi9jTG
7LqPVhQcoXBlWdxUE6wZdDTjlrGmx9GkhicC4PEx4i+LcaanOPWf4x0/JrK6xlTG/wf1Klvf
0BxoaGyL+SJGIunbhpYRNVs/N6VLlhRbAYebWhCeWhQA9ZraYtyAf1cwGoh0JeoRarDRHFMb
EwVq3C6pBUJOBf62p2bmSiyL59KCuuR/54DbAwLLFsUXNb2Jevs3Psrvv89BA9ZnPEqK28OS
ezJrykbW542ojzAvyxAwWCtWG1raDGPUCF0Ul5VhRAO+qJEwOgasnhUBnzdgHBcxETPWRhLO
8Q9YP99eYEZ3xLGJ1UpNBb8Rye0fjtByL32+frjJWyMPK+3Pla2HlEIuqQ7wOhV11Kvh+wn4
mn6I6vUQMtzXqRG6FmA62ndpL1AQ/Z9GvRlylxoigfbFwGdAOdAM+IAVQAxYAjwHNKKvCXyb
53AgdlK7+yvU4TpNXlcrFQGLUQ5oH1Gpto78KNdzHevNFpOpFOUi6Erck9H3tHWJ9ehXJPu1
Ytw66oF+AeoPAnnunVQAmQOMQXs+5jnINkM2iJO8V+sqyhthxyKUP4eMwtY6yCVoX4ryfCAb
Y76ohqyVKOeiPB++yUU5C4hg3E0eg/7ZsLET+rGoq9wX62ZDFnBfzFkiLigFyh68Ry5Qv9ZC
Y6EfLYF9856dPbH9bNO/QZTtS4dtnwTbqt627Q6oGVglZsuz2pLc6171DK0V+61rKAf0sRRh
uC/QFOzvEyCkddIk92Trr7BxkesYVaHuASZK8Jx7aau4TmHoyvTXwJtOWqDOhKLKuqV+iybr
QXoU+4W/aRpsjzP3wIWp6Ncsx3fSFO0S5aMcZniI/pzyE3yDs2+ArIXfr3jI+hRz1DIwz3Hg
JMZPwPqV7AM+d6V1uA99L0P3LLAOHJkETIB+u+QwxvB4rPMwr2GfA3klBwHmHjDLQfJ8HDzo
QPr/kMR4YAIwB+B1XwN+ATwGfI/7YN7x6D8FdjzPnGFuMj+YG5L/4JPkLJ/jOviGOWbHzA/V
J+klYCxQjgf91iRK0VfGC58j28yxwHMzt5gzjoS+2Oa9cpX3yZxKkwFXuVxbxiBzK02WMPdZ
irDcQ4k6SNXMWdvXjpQ2RDgeOSYc6djD8SljBFJ00xj2HZ+7Ix1fpOR+CkK3xPUuParNpOXi
FPjfjvLjkHPgn30yBq9q36eP1V5S3YNUjrPk2H09Q+5muIeUNZhvEL4s1s7Q61IOqUXakOJy
9VmXXX3q8zaccrrMhDJo61gy0nX/bfv/AvW8q4+eRPlvriHL0oboVeyV3H9XZgA+R6L9CNAD
lHrKlN2ebmXAvYy84M114BktjG+/MM3RBmmhNk7GXRDtyzB3pdZN8zBO4CvnZbGMDuh99AUx
hHPEWup5eoHB80OuTfEok3N3cklKh693kRwD2Y6UMRWy/iDjKmT9UcZkyBq2JYU4N/D9LPMD
ybs51+FripdvULG4kcbPDJ6m8XMexnkzeZkmR7NM5pZsJ04xZjznGt6/vB9bZTzJew66I07/
TJkaf4gG1EPW+/IePkNtTlwDM4Eg9L9M3iO4h3HenDN3Wu36s1a7WGy1Y58/1bdBXrOOqtOs
/lRODdKs5F2W7+RS9pPrDBWm8miQlibvsyDnU+0gcridR8fI/PkXmui6Ju+2WdJejkOOwUrc
e9OQx/9h3dLy6GnxMpFAXHI7ONLIOs1D48SfcOcupvVin/U7sUveQRExTHFRhhjGWPhsokul
QlcdNWAMyfm4DyS3sf26Bn7yXVCPOs7KuZf57PVblA1Mc13BfdSKPofkXoPyHt9NU9kPcuwG
5BXM5S6jPE2lsmSfoBzzFN4L0h+4A9N8kczNC3hOvUlyNkeOmW3d8uRRiOF6k6qxflCuVU81
nhAVu1qtK/JdkUePidM0Q9TTQyjnS95vQ44qQb6sR34ExEfAMLjptesyV0tp3ZT5frPM51mu
Slou3xOs02mKXkLTGVoAugRViDcxzzPg1S2U37Is+T74PeXy2miPJt8n/E5QZbz8FuPeoQqO
MbZB5hu2Zw/4do4e4pzoPgAfjuIYVBT4uzCZB/NQVyG/k4ZXkm2FtlT86rvUKnUt9KF6Qj2s
nrC6+R0o3qOvih/g/A6TX7Qhf59CbpyHHL4YvvoNxcRZlIvQvg/YiLffesrRcqhTXES/WdCt
xbgzmOMA9IytGPMB5Fs0X/yKusQg3gcX+Y1Afm0D5BNAHdUqP6Zu9SZ169XIyfOsN+T8jPXW
lyUOIG9eTI5NQtrq4G42b8Lb7i72SlvT7WQb72Ifz8HzynHoo2mUQ2R9AARtOdyo7qQ+YL/6
Hvp+iTYpB/HM30tR5RKwN4mfUL2U/UAjYqxKeQ6YrlXRz4AtKJdDngAO23XaA7wP9GLuk5BH
dXwqMNRHwGdItO0DdgO/dnTp4LXu1p4OVwGNrL9NPQzluvVPRmZ/bQtVY71qbT4RQ1ymVxj6
Zmpzb6Q2gftBm4I5M+pYZ5b2Nq25lz33gnKOZkgf2gjfzx7vFxy7nJ//X/PdL3C+m4EnpA1X
cB/bHBqtnKciyFbIVrGBvsFAvQL1uONP5Tq4xjhI35XtqfOz28EVEpyzM9oz65nneq+6ehRv
3TQ4PEjx4VV6kaEtRH8gs+55h15k6KegO3VnXfvRPdCGN8oeaRNJjmXU9aX0FEOdClvz5Zgd
jFT9HL41AO4rx2fTToaMXUA9Rl2MlL6KtjPS/FrNfsWaUu+cj3MumecD+8LaWaAN79mzNAOy
GfJhR6b4nbwvRnC+0eZ7qs53yaWMPrdj4nZs/Iv7qo2N4jjDMzvnvTuO9R2OIYAxc/b6wMZH
bI6m5uOS2zN3UPus2AkUbLfK+QOHiIBsCiVqateglhSapHYLBQINdtKYVrFdr/eAnAMtVqom
ShQVV6rUqkJgWv71R52kpUprcJ+ZO/OhGjWR0j+90/M8M+/7zjuzs7O7M3hW7pfz/wl4dt4H
3gXe+V/3RfF+EO8IDyD3qGtJVH0Ye8/NBMfVmx8QMpkNfQDfBTx5k+Mo/w7lJqAY5TdhOw49
CEWayVuwT+E7gqV065RtIfbvhBwEkONWW6rtzRvAs6kcN88T8q8/pLEn1X7yRWA9fFiFk2cA
rN7JnwMRtJnO8wPUd0F/hfqGVK5JlG9eA74LxIBjKZ38HiD8TvTxe7EfmeEc+rnq/c4fn1bT
54zgtP7HGeKz6NpPpfecOabv/3/T6bPEDCrnIT1+9a7x3O+Mc49i/ThTf0JGpkbZtUQ0GjCS
0OKHpFqFRQHpsBYuCvyCXVMGyFLCYbhqzcuRnitWeXm68MVVqUJi2fLA1fAsdoX8FVDYFXaV
FKZaJQofCkyENRgo+xZxU0o46cVO1gQUYrA/JgqWBHousg/gf5+9R7bKZu9Z2pwAEr7L3iRZ
2PGeY2fTnrOJzDkBEt6NSaBkFDwGjAMTgI20sp+STqALGAKwBQNzoASoFhbWz/oxzj60d4NL
gFagC7CRTewN2J8RzH7GtpN8tH2RHSFzoS+ww1Jfhy6Evgb7YuirqAvtSddPQoX/RNr+Murz
oMfTegz2HOhR1IX+KF3fi4+CaLcnrb1st7WYe8KL4fcCpQBD6QhKRzB1R8TXGkzZt9kO2dMw
NADdmVJMV4eVp8t71JF4cEGgF1PaganvwMx1YOY6iA2u9umY9lTMctaOmHbEtCOmHbNSynaj
v91i+YA9gBdgmPfdmHdhN8GjwJi0fwfcDfSKGnsW81iEUR1i261CjkW2LbHaCITOs6cw1QZ7
KrEgN9B1p+acJRYiNDOtbhHbIr0tCedsYW1JLMxNKaKeCWeyZvJNQCHZ4ALgC0AEsLFmq6CE
v8UeIzsdxMjknUon67R1ZthKIzTrIguQGrxbOcliy0kQAUU8HqRlDc425z4n8zi9zlKn4axx
ZrSyTtbFGGclLMSqWZxlJKdGLfualRBjg7pmZber12W6Rl1jrgxTHVXH1HF1Qs3wqqWqodao
DWqbuk/tVntVZ7fabVcaXG2ufS7mcXldpS7DVePK4HbaGz7AmsRXA+wB2oBuwIY5jsPuZU8C
cdyNOKbiSbEHBRPUPMAYyuPQDNTciHMjzg2rG1Y3rAQsPDVAA9CW9qq3PdNtRPyE8ABiu5IJ
aybmdhw8IUpAJWoaahpqGqLGlEmM0AP2AjUAk7ZxAKsGPO0rTfsbAFX6J2TMtM8QbZVJo3Hp
aBE1i2hvEe0uokYwFA4Y+aCsrKy4HvfFC+N9tla91dda2Npnq9arfdWF1X22kB7yhQpDfbYS
vcRXUljSZ+M69/FC3mfrqhqqulh1qcoWr2qt6qxiZbh1Cau4NCA13yf0rLVgYaDMHX4EZ0NK
4uAe4CrAiBvMgRIgBLQCGcqQtA7COgjrIKkG4kAGWg2KVwyYp33C3iN9oiT8yj1+hosfsNas
rA5X4bUbB3oAhtwD8A/I6FRpSNpN8Li0V6fje6VdRHFgup14CdbL1109HsN6EgLiQBuQQS6x
LeQqgOxgDrQBQ4CN1eO/hW1RBvEfUAaY39BWzOVk3jxsabLmODxhjzIba0HDNljwccmHJIck
FxiZldqNSu2XldrzldpSFJRCEobjiOQ8wxXWzoS16rBWFNaQ7UGSRzRlrmRVMP2L5Mck+43s
PO2TPO3jPO3DPO2VPG1XnvZInmi3CM+wpmRLdgmmRyVXSl5iuLj2Dte2cK2Ma2GNnqLonZRL
Xiw5RzD96Iw74ibO8/QjEkEmagWLeFIhUuiUFQxDblnBDZCbVvAU5J9W8DC/QD+h8tNGb1gF
13l4Lv0brbCJ+sdp/ZBWkH7oBHQb9DQJUh/0dSu4X8T/BO1PoP4ayXeI+FdJjWzXQyuk/ZV0
ux9b/ib0etLyfwO9niB+2esxy38d1sOW/xDkh5Z/B6TL8okBbreCy3h4Dt1GChQR20x8ihhJ
VbrHLyHzDuiGVOOo5RetIqKDJF1n6SsgS8UoL1Cd1MjuuKXLi8wlukyxiOhy0DnEJzWTuuXg
NZIv1WHp+5FFPeO7zv8RPC8unPyduq1T/M8XcH2bUf0TrbD6+W9HxHRZ/JI/SX3n+G/08/zX
BUm62eKj/qQDjov+pELP8mFMsolYhZ7jQ/5tfFCX3j4dXtzqnuByflKv5y/7ULf4fv8FMQyy
E1e8Ge46/6O8KtjP1/uSFG4jiM6MWXyN/jW+GuZVSVqR6OcrCpJiKKXI0X+OL0OPS3Q5lC+X
vaU8TOz064bfvsfeZN9sf9y+1r7SvtzutefaF9mzHVkOjyPTMdsxy+FwqA6bQ3EQR3ZyatzA
tp6SbNUjRLUJtsmyRxEMEm9/hToUPDvmAyymxDaWUzMrRmKbys2y4ljSPvWEuao4ZjpqvlI7
TOn361AzlYNJSjbVYoEK04EcM2td7QihtOTASzlC2w+8VFdHY+ZoM4k1ec0bG3Edsx6vNzP0
8vlk3t7Q/FDWo3NWr4/MQA1pLr7zm198929+rnk0trHWfCO3zgyIwlRuXczcsNH71doRZZfS
Go2MKG1C6mpH6HPKrugTwk6fi9TdDiP5ShvCsCdvS4UlSL4II/k0IcOqZBiWaX40Mpyfnwp6
m1aIICyft2XQtlSuAnSBXDVCEKYsJgUyV4GyWIRhPaSSue9ONptQt0zmnk1kskUiaNjnQ4jf
J0KGy3wIGPaVSXf/HbfuSw2njvhkPz5aJ/uh9E5MYSoGqyAdozgQU/x5/lrKP0MwTTRe3toc
bdGjDXq0BWgwX9j79HxzX5PXO7z1snB4Tbakoan5aaGNLeZlvSVibtUj3uHG5hnczcLdqEeG
SXN0U+1ws9ESsRqNxqjeGKlLnO5cF7unr0O3+1rXOUOyTpFsnejrdGwGd0y4T4u+Yv8mu2qA
mziu8O6e7uSzZOn0r7OMbUmWXEvYlmRLYFu2Tsbmx8IuYJpYDMLCBczPYGNkNQVMbEIDrSeJ
oW2AaRjstpSkpa1tIKAxbUgplDSZDpmm6bSZzoS2tMM00YS2DnQCFn179mSm05v93lvtrva9
ez+776isGJV1Tjony4qta8axNV3Teag5vmzjPL9IVPmQD0mbPd5sFvY0ycnRYLc+a5tRILi2
VN74lNrZPFUAoFOV0coonYLspFMaGNYuTFmfbbDbZvBrC1MCDOuczciLrK07Wj5vqVRqkCKd
9gIdTFvlsUFIWntnbGr52g1dU+GpcOuUlGyJY+qO9MKzrEsSroVvh0l/eDg8Fh4PT4bZdDoO
w/prjtsO0u3odww7xhzjjkkHRyc2dl2WwuOOTxxMGqIJD8LT2iLLTAOHRn8OplP0QSAgBZgX
5017l3VFHejLUPViqNArkQHgBNQAOgEs+iXQ9wB/BfwboECHgX4L8H3ARTrCVDKVrdYdLVRi
3EsPHSsTuOgLBpZmgG/eNs87N8zz1o55Ho4GrMAvRGryo1oowDGaAfo24APAPwCfAVgmwATk
zdPzURtPoZQXg/oIfgxSkvIOYi90MDX3YMrrRRQ0wMEDsNSL/zfuEU6lEZgCHAIMFsmjKfq3
NOWfr4N7EoEFaM2MlKh9muCr5A0oVpXk2gXEKjLkjUsMylfSzusYiXkcew3mCWJwBeLxLrwJ
Wb3Cg/BcuEOYDbfPhVEE+sJjIH6fXWfXuYDA0Y8elzJvPpZY9AiVKt4EWbEnf2YfsbuQHzWi
VTguuVHsTowIMcxpeJuq1KyxlYpRboWn3wZFb01/834bpwjgGK1fjeZayqXFGn1thVRT7ost
K+9RJouSFcnA1sY9gcHGD0rV6gKvgWsKRCuK1AXEw3EZvFpyNBUZm5qKGMXiqkpftRLXFHm4
xd4mQ5Tn/acQOQUXfoZZe2npcifDZ8iwpBJW3DabBZUfrJTBvouo1c39HMqVJnwLiaiC/OpK
UaQkZrEUFmTwYckglrix+1AyiINXG6b7S/aUECgEKiVbS7hb7BeHxTFxXJwUr4m3xQ/FT8R8
UWyDs/PwRfv6DXDPdMwm2rOzCdr2CnMdrVtb/t4uzGZpewAGpXYVskI2kp2Vud5ShwFHNVXe
g8INrNPXQZMh/Nrvwwnw7EACJ/YOYLuJ44jSbK4JhJZYOM7pcJfLNFgbWuIGuiRUEzCbjJzS
bAkFa8vd5a4QcLfTwZmMZoObroYO/Fthwmef7pzqi7+wojVpdLnO7l73wy1DtwZ+cP2n96sd
z/YcfObE8czw6FSxuSL33NCBePPTccdvvrat8av7RtORNLPDpYzkro9u74ytsr14JL6z70tT
+/f989D25xvPb1j+Yu/Oie6//Oy3x6rKbKyq4cTGlZv21fv3zYmXzh1oPbd51/cCtFxYyzhx
IcSMGq2VbPmakeLekMrqCdaqlwLJqN5S/UF1T6VQowxef4VjNOAYHhwalPLVan43M1Kw/iyN
1WxddbZDoAZGkXYapngvJIKBoRaRTaFkzoQstZWVDYUhEPiFA16pvsHnOp77I9Vhfa6NDLEv
IQOql5wndK/qyBH1N3Qk/xSvQ6ewAbIpn39N41jDYW7EuH4TFZjIzoVlD4L3/D4EbsEmd7mb
BAW0hDrHZLQUEzJ0cuux0zjw4MCZDnth28Fcv2v1tuN49Hc4hJ/0eVo+zp24+fvJ0Ve/AzpU
gQ5PyTrUSWUVCk/eSpYB4TpQwgA1EJ8PCpRyPk7iGG7E1HX2/5XACUPQbDHrTQJSBkMhPTi+
ilSd2jp2Onf74YHxdrsYG2K3eGLbvpl75v3c2znc52r9CO+6+f7U6DmqQV/uPHwAvYUsqFMq
j5O45YaZ4S1J8V2R4TFSKhTaPD26rJfUKkW91lRiGjExpgz2QEGq7dYSrWg9DUrBiZFon0tk
Qae7+jqIYUsd1QwPGIIhORSdDuVCpM6HaF/vAK9Uqlx6o78+FmruHcudX+wYW2Mo4I18fY1/
eaq7d5r6qBOPkC74vGJQRCol7MiiLaFhFtOic4phEBHwGpzEx/AEfhdzkNi1r6MRBU1CyLQE
tVF1FqicRQa7yd5J2LlHxHKS7nz8yV3cj64jFfJKRUjiVIzES/VBXooEu3k8zk/yhH9evXM/
3WsAwoq+m9/nkrWffxOMqqVoVVU0el2mVdUS3Zd5cpc0gUcZtE7iEftOSW8IHJlhyqUCwhgJ
AbXhDFJBZJdIxlLGxySZPcwEc4fhmKv4J+QdRQb3T38oR/csNWg4Ej7KykeD3+fF2IlJU860
Bn/EvvTZU+yPYC/U9uQec4XdjgRUhmYubM4rhW+WCyxroqygoDCDtZKeL0RuyU0kd9I94b7j
Vrh1dFjTjfrRMBpDE3BriK4ZXAymXfAmJFZi4EF7diHMlu2TVuMyZ5mjjHAEM5hwSleRbZGt
2MZwBrfWpXJbRYtIOLtC14NKuMIebNRAz6yGXhku7cG2PCB6wdSDxHwgckVHiUeGx3PIUKun
B5jFrDMSsHC5e4lgkY+6kI6eZXIIkbYXBjckTw+98vX3eq4f2n2jtW4gNFhc5Surq6hvCa6s
JWfu4S+ui47fzE1+nLv88t9+8TB3b/rlzXt/jOvuvZLy2Rs7c6fBR/fhiuTAYmZ0UjJK1qR1
wnrHqkBWyUq+go4gooka8A4chVtxAjngfqT9POg7wcH/QVq8A5lhBOF/SfDNqCU8wSyfpyYM
msEPYfkqSa/RaCVd0Kcd1h7TTmgVWtEyQ8rw3QXjesPtQvaufBNEwjqaMHXo0+xj/KnXK58q
AwmDq0ZnNJstJnuwiQSpAej738dtdkN4Y44kl5rzla5CV7Pi1ncfHd27tJi4XGSRfz/507c9
pcUlNA4Xwzueh3csxsul55RWVZ3FWtRY+1+myz24iesK4/fcfWklrbSSbEkrW0ZrWZIt4QdI
cjD1wOURHsHBZGgwL9fGyYDBJGAnkGBgLCgM79hNAyUlBSU8wiNMIS6OMExoO6UNLVP6R1tC
Ox1c6iZxOm77B52UFJuelUUSz/jundWMZnTO9/3Od7wMD8047EVud5lUK82VzkgiCyzjl5qW
eZZ620wvO152vmX5ke1Nx3uW92w3hBuej7x3PHe8A4EH/ANPfj74eU0oyNfcmsfvlWSPxWvx
J7TZ2h5Pd0DyapR6fJpVExVOo4Lo9RgUdvE4VluZLLM869SUDHKGizOrKvi6NTAGKdX6uTgW
7kAvUGtRBg4whYj36l1NrnWuLhfvyoDEXAx/lI8EWCAV4JoD6QANaFfgAfpMAcbymug62kW7
6TV6i96l/6Imqo3rh9e+1vNg7ZiiG59GW6mGsYZHGttrp460xwYNXmXbgEOXqrbaXaqw9Rc2
NBy0dzRiP4x0FQNOTxIyNk+lYHVuwIgSlfSJ1dVPcOeaHg7ACggcffH5Y+GQduvIyb9UPXXq
wRRoWdswywfC6P9CMB0On9l2akP75V/+vmfVqncujf57kjrBCLML0cOLsFsToe4yMT8aeN9a
IxvBqNZaM01+0jzLMq+YvyVDWdmkMpZoTtxKDCS+MEskAdPkrmBnxdmSyyX9FTcq7gbvhv5c
8XnxUMg611SWgf29paUqydDB3t9VQVWGS1ziBNUN7gwcu+RnscqEPwMzelWlrPQKtJI8ItO/
McsCrDDtyVYY+9R7wQrWDPTg+/JUOe0pT5fTcnx/qUnqwt+eoX9nZpaAdOKnCZpAqk35gLmu
uahLixs4+eyr8mdrP9zYft84BjFhIlhiwx1ThxuHnTjGs4SprqgsCpvtvFisB/USPaTzohCy
hcNmREclX94CRXa86ZZIC5jlCrGqBcYpfoMlam0uNUe34V/WQR2kHaNAdZYo2Cd3tll6bgR5
0FoGW7IpCa0VNFxmdFZqnXxxx/GG6f1bU+tfH/3Hnucqdc3neNUTiq78QdA3LnZofqD+2Jxt
zUda+af2HFxTv/SNoxP6Nl/YdnpmxD/eJEwVLUfX1s+b5C+dVmT+zo76VV2nDEIH0IuXsbtm
opDbrNStgJ08qTA7x+wQtUK+hDgFThZE4K0WhfBWhRetCnqmkDklU54kmUwcL4lWExmngHIF
3sJUb4FjTBFAlE2iaBJ4q5W/AnPRDSZYySyybOfgGPdjjnIZ+IJ5YWrWPHZoRhoN2Dm7yCSQ
NNs3HNJem+1QLdoDr5+oRv6fWlOp4vzElDrSUeuocWQdsqsixueCqt1uR151YAxq74D8oCPo
0JMQxwdwl/tOjvycbnjx5GgJ3H9t9IewMsVtf7ifvj3SZNCpBfW+SagjOohsxgkenEuKVhd1
CV1il38/f8AvJWlSf5Z7NtCgtxVuFDYV7qJ7fXsLj3On5XRwIGgnQbCrDqcr3+0x5eFc5YxS
OQI6DlQ+oPsKCjnJywv49lhvIKC7+pETXs7FsKZwj9B7uo5rTD9MIQUw+1JKShs6hv+gjoPA
gs1BGkSDPOhTaVoH3fgSJgeYmlapqhX3w0EYylZssBEhrjYa1clKe/CrXJ8VNDLdwMouU0VM
wHKRXCZqR57MWL6YWdr4dc7ni9YL6/1C4xKMSpIu8YZSRfEbSSknUtRoBLhN80dbl4B8ZGfD
jmde2tS5riLoi1TOe3rDxaP7XrgKvFB3ti9ydHemrS8VeWLhxMKYqicudm3+w+RyidoNFS7G
ml9EFXpJKRlm0Q3yRvMrtu3yndBQSBQ52Mp18p3unR6+1lQqClxQK9VELtBkAhMyoi+AC1HY
jhHrQK+XCEbE6LUrgEVkRi+Y0+IjURalLNocTUcHonxUG6svfkRcqivgqnIxV48r7ZJcWtnX
QeMhxsbBXNLIIgGxjNXDzclYi8ZqhmAYXxiSnf7CokIqOkJKOCQH0fpqQQvRbXgrMYdboNAZ
aCHFVjzI42hh0CDLAsi3cdJjYBvRwpFwllTHwViHHpcYqc4d2vHu8baSnu/tu7lqy819Kz58
Hez/bRu56Zw9Kz63Yc/ureEGoTWk1L/zqz3PDVw4u//s8l7w98Gc0cUjM3ctbP7r9MoTh899
GTD0XfdokDuJ+raQ85cJ/2ig11UwRcg8GmAxvGgmELioPJ0wpVlJK7+GG/Rj+JgOKFhEsABR
mMJRgcck+H3m42gex1GeUwQ2OyncQ7/MTor3AAWcgTf70hawaFahn35GOPopsxJe5Rm/gE/z
An+VfkKsuUobW8NgFsT3jckXU4djY7lyl23r4znXgUXDlIwRU8eoJUV+S2+P1q6Hg6P72qu+
HfcLdeEvP+SvF1Q0WxBnZAuqaS+qSSNhEodO1r8E15X4uHg0si7eWZyypKwpX6pgeygV3hs/
4z3pezfUa/2J74Pwlch183XLbcUtETOICvXJEbfi8YWUkG0e7IfvKjttZ4jtW2QyzCPzYG5p
EyyLLI+vIWtgNV0VXhNpjW+GLZGN47fEu/luISWlTNsd253ded3uw/wh0xuOQ84j7lPh85Hz
8QzfZxqyfG4dsg1FhiaWSYocmUxqYNJEYaaJWH0RPnuonmxeFoVy4+FS/NNkpLOMujb+q/Cu
IlFVkmRJypLNyXRyIMkng1fxAw4VHkWFm6s8zNPj4Txaoh/+mcODEaHvZ9EwPHh/LEUbcoac
oifGKouKHW7elB/ShSBGZsnfAuPzoi2kwolzrZjHQVdkROaYu7yFVDrKx3SdE7Yx5QyUtBtd
C3+9Vkluz9h+EjHehapzwjZk7hKNR27mwZ63G2+eOfHR2nMXaur+dPFnaxdtggmvso0rV6aS
E6oXLjjwwtrt4dn03I70oh3X3u+oO9q2e/7K9u7fbFrx0tKLf1y7tX71KxvrE62Vo5/OOtm8
7Uhnw5yaNUiYZ1D1p1ETHhKB/zNe7bFNXXf4nHMffiT2vU7i17V9/YivH9iLnVw7IcYiNymg
lRWSggJJSJYAZSCghYSuEF7J2o3wWJUMJjZgpZnWrOqGNkh4JLRjCFVoZWiCTmOkXVe2CQpr
I21ahEbBYb97nbJM+2Oz7z2/c871Q+d85/f9vq9QkXeEx5nfB8bD9Dq6m9ml327YWrjN1F28
1XdA/0qx0aDvj5I5eibs8IcdDCVKNNIx5/Fq5MDK6XAD1CfgHcWQkDZJoG6RqMJjZoCBvn3a
bkcmh8ovAubOoSK+yFdEFY3iNcA1USXaG6WUaEd0MHorSkexylB++Jhi/KWRGJ2R/1AlE3lZ
kstzd8009fCTAJXG3poi1PCa5QrqLYUhXnKHSkNek38V8nCqtdFDz1cggr+xQBMwSDP5RwVK
Y3x7urKyqCrP61XTkoQAFWEVoDxCGg9tfPnW9ehrPf1Xv7bj8ptbD/7x8g8vELmorntR857m
2vay3W6JfB0Hf77mo3PDB97a/9OHf57q/sZ6Mvby4pV/2jZ4/Ldbl8UBhZPgbAeok8A9dlR3
inKOYknxmNZWDjgHwaApSFcIdM0pVjC8qQHroJVY38ESVIX3McozxaSmjzXbh9tieIblLZ7R
x37V9MIdT9TWqZE6qQ3hzhXX5Xt1KheG0dv0Cvq7oFl+pxRUUdiOHCwQGjVKhZUClilhKcIy
JD82IFyCKBph9jwFX6bqhikfgYych0D+k3EguXFQUzSep5QpDK5hNjE9TC9DMwRjGjEKQwYY
3MB0MKQDponCbGYIVCuGAEMuhXz9u2JDHHuNJe1sP0s2sT0sYVt1TV+FZU+2ge6ZeNSmvjqz
oHpQoq1zQnDmcoIDAj8xAaXcoUmfJx1V/OC2YmzFcIXp1KNV1PGHV8kl/P7yqRem1rfgG2rd
lfCHdCu1BThTh3aeYnWwzrNMPd1OE/oC9Qx8gKLCsE3oca8yJwMWoxeRBmgG0TV0CzGIZRmG
EB7jaxgnsYIHMYUwj32Ywq0GHQ0biVr12hLuZzW1dh8W0KV1UU1bZyyby4Ksy2XLk0Du2lui
qx6+p97UliWTS+CvJUCoWUPotmJyIDtLYlQ19T8xQipGrIYRPY0R8wQjAhjFFIxr8Cbcg3sx
jRmacLgeE3Xcj1/H9CaMOZyAqXZ4+gVAERbOzEVYOVFQBxqAbaB5+LkkaoCShzbDxvx7vXms
NNAAsv8PMaxSJk6rF9388Cr1+qOVdIq8OlW2DB/Eh1dMzQJAWh/fpuYwG1AAlaG7Zwx6LkmI
WrxnJ9OpRLImWZ9sT+40HDAMFQ4JP3IZQvpCk5nibRTj99KYMxcbWYameB2h/FQo3lOMwcCe
PWNc4ATgRqkliqtUiRaA30KhuO7Uxx7MebCnL8Q/b7sTT47i58+FFF88GSfxt4kJJaAEVY34
f9DiiMWAqO4AN4FW71QJKgFJmrufBb3ZhvMO1l6NVMKyzJROgt2tL3RJBQ6TBxkEnQcX2o0e
rHdDg/I8BRwFWd6JwdNWzagYTxI9T1cgS1ndzPS/HNWVL8oG+1Ytfy5b5p81/9KPf7Pyy7Ur
vlNrneYDrOweOtTZPbfn8JKktNEdLF+6sPNn25o2PH103Rv7JmsTKkMkatUM4RFiTsJ+u5EX
n1BcejPHmXijaPA2+FkrV8wLFsHlcjs8rH/08cVhKa2GkWRTSouxMi0OR/PTvlB+WhDz03Zt
etiqBeV7fHHKxBXAj1dzC7kF/NNivb+ZW843ljSJ67m1/DrxJb6X7jPv5/r4vqJ94l7vMe4Y
f8RyTBzjxvhfCGPir7kr/K88V8QPuZv8p9xd/q74gPsn/8DzQIwbuK+4iBcEl1ckyCOKboPZ
6DLY3HaXTU90Lr3VUuKybhM53seLbnfAwpdYNluwhefM5lHynmIhYgkhotczBOccMoZArTuj
FOp5jrLabHq9Qe8exZ8rBg6+Q4bMimWUJEfqRSyOks8Us08xN5j/ZqbMb/o27NeSwynk2iYc
gupPJtT6Bm9oJ8Gx5LJ95rwt6WszQ2b0MbvejTkQP4H5i//d9vG73s3qsnBp/iX2xQuD8fPr
NHFh9afh7FRhGdvyA1VlFBDqrdw/WgNzVk01NjrlufijUnyzum1p7t6z1ZEX7nyGL9+oD3sT
OkniHMlDdOvD7+99lpEkuswfb8cmEsz9QdWZAYToO6CkRRRDs0mzkmxBLeI+tFfcJx8RXguf
EE6E7wl/DX+SKJyNtoe75aMVR+Sh4E/km8LN8M2Ikc6Mkk9GuLWVGfVQuAMpNSp/sdpTsuKP
Q+MUUxVKaQQalyc1LzhP2ieM4xvBD+Tbko4OYslUwVNW1iWUiLagLWJNllXMDy5MLcdNzpbw
YWLhEZ9pxC3BjszmTG9mMKMXkkJFA4LsF4JixJmgWUKJdrFe3hs8GhyXdb6MkmnIrCarqQ6m
g+3QdSRfYrcIW1ybxReDW8LbI99k97j2iP1yb+ZK4oPEp8HPg85mPed1GfwB3uuy+UvlIHBv
HKVj3iAViM6Oy1RZIJJOG2zRiN1uI2UR9aAMgFtTT30mrYU6NfSO1NSm1OHIUwu0qJTA/DPt
bmwUk27ibqRj3tnxcvUBPz9dpICHIAiaWzRFq5NGkyUFlddHYzAm18/GAzx3vDrzDr6O/Ggl
doB0iC2ezC6ayEHNaet8qmkMlVNfuufSwkRzjAeChsPXNaGdna684IJbI7Jp9rLkeSsW05ir
NpEqjThErBNcThdh2VAQhKAcijhCMk7oymVcKoZkKoXLZSrsiso4yZTJSPIEZCRWUGkZfA+f
jWVniDHVD6pk14m7urpQV+cTQY1AouG8dGZL/Wm5oqoybQGZXFqa9gP5qfOSTdVneXbUWaY9
o8qUOmr41QUrez++neuVGyW7J7xIJgvfWH34+M7cDqm9+uChxZfOP9fwYueZC8su9c9tcpHT
Yl3rt9aMNUqVpV3Uxt3+uOQIntv6L7qrBraJ8wzf9519P3Zsny/x79k+313OvsRxbOIfujUk
F0oIP4JkbcjUTlFh/LQbVNihhFCEEqaqKYyJaCsIOpGlYkxsclU2SpaGldJN6sS6rlRQWLdK
ZFKHQJCV0hSmgc3es0mhlSpbd5/ux/L3PO/zvM+77hUHTbf+aNmWI+7bG4VDA50/7TaZjfS0
5O6/zA7wxlritj6fDSVQAifIhLjPcSB0yHGIH3f8nrcyIfj3aDu5zTXg/gm5y32Q3OcvkCdI
toq0m3BwEfk4aU4wnLNWgKHRfBwLCE0SE+TS8fDLZi1Aogl88bgzdpRD3ATZdnyP7Rc2bJsg
E3pdDYsLBEKoiSu85kSis9WJnX4diottDnuRwyt6sXexumZ1JU73LZtezvXe7MvD5JM3mlN+
pnfmUuv0tRmwEWMYOl3mNewSqCpa9UesEbdKCWycqHLBgfGZ48jiscUJ4kvKKvG5L9+LqpUy
2thVwxvgz/VQJiVsTDl8rdGfDMrmmj4QxZZLrwz/Y3v/9P7n/7JVXFe6fqL02hu7xlHrmz/b
U88LNX6reX0p9f74ztK5ixOlGyP5IzXHj/xv8s67qPvEIne1kIRupEA32gqO44bCfl//nlWw
Bl/g9nIfcuZ+rr9mmNtffcB1WjgdPMcxXidfEwyRtAsN+18MYY2hRIGQZFoUbJLikXyiZrfb
sE9zuwkm0NzJo8qwkuR13swvVgxZ+VszuoLCCsopY8qUQiqSR6apUXlVBdTmZcXmZTCk9EH3
B3zvy+ZbszIJ+EMOF6fWREKOQA/yu+AQdIo9SKj29cwiuWMHYVR9bz711eIOm3gXR1NSFAAk
wMugtpVUT607YFSxBnFz3tuFt0ub/znYcxk1lf52/YlN6lxpE7lhMNyg7iqdPFv698lz3w+g
hciDfGhB0KjXevDr1wG9FPGpvkLPPBXYEvh58tfeQvJEcirD9PhyVI4eZAbZIWqI3sPsYdla
UQhKsioKMUlhJLtdZAWGljAWKYEOcAJGCsSBYIo4HGsk4lwcxyfwWX1RQ0MMauFwULgcCAQZ
tsAwVKGVHqQxQXN0J03S/Y2FhpgYT8ALG/yFsKALFwVSeKwrk8uMZcgMwclq7Wh66g00XB56
ICBD6fZOz/R+UoRcOd3MlbG+Br0STqVy0wSngseMmZCbvkZwX6DKyeAB/ANCmGRUYcqpRKJQ
rJKzBjzDqFW4RlZc5T7yRj3DChVQ/bPRNKWqdjv/6IrSeU576NKmp5Mtbdrm21eTyVjY46/t
Tppcjqgr1aStNePiZaXx2ZK2OqBopbYnop5womV7qaB6OH01md8R0tTShfVdLgcwIQETIjAR
R8RvtcQECulz1TVZ1sRajibI/bHJ2Duxj8izsSumK5bbptsWNmfOUYPAzZB5iNoD3DC0ha3H
tFRVNYEiuo0R6KAoeCSZAnKMK3VmgbKXe1JIFCKSEmvQLEwVzGJAWZXN5okTSoTQOA1rBmNq
NBrBbg8TjWkFog4Rdck6vS5XZ6oboSiRRp00eotGtJF4LIRdDgVHGx9QwEx5ornZmy9+AqwA
If/p/ZIPoAO+BitQ7GVGirNn4AWsA/oRcho8ADONWFGcNR7w+lTK9YDTz5IC99GhWys6baqK
ou0LbtksEMXnFCeT3RGvzSIC0+RnNsXfvvaHwMTVpRtLmc4laqnnKcnHe1V1Tvg5ckNlXTr/
5OOaoYdF4N+/Af9OI1XvtpgWNmJf1K9hzsv5cDirZ1dmB5icN+cbqB/xjviOeo/6rPFEv3XY
Snqzjf6ubC672/SqaSprqiJfsJ7KkosYQNv7ucwbXCjpsqMfKzs6OgZ5aakem/Nyg8frlSmt
gbRrMotiYkh2Orv4ER47+E4eGx40yN/lTTw/gf+rc5bmrghyRMQIjizOrNk16+XFm4ky6sVm
wHy6ddpAm5u18nvekw7HaI5RtWhdtD5KUlXQoh2S82EUFjknHbPECZsCBy5sf5hgo1QcWVV7
nKg0XSOOGi254vGxsoCMpmw4PbARNoJlxeqdRqPNSC4wJ8rlhA5d9n1QFUwmBpHwiOkK0Ne9
9WSpOJzf9/nQ0t1tYtuj2OZbHqzZNLWztOWvB3rW/W7vu0u2bnyoulogoQd0j31n83uvfvrH
0qm9ERW9uK5VikTS6jOlVS3fvvPmrWO//NMPvuutcykpYNDoBwdBR+3En/V8rmOs40zHVIep
umM0oGe7YImBCqsky6IQkOS0KDRKcrsotEgyFgWLpFSLgiAp4G9xScmIwjxJgZ9UamuFlnnz
rFYLbozHAwGB4atlrMvooozCclLOyWPyGXlKpuQJHNb9XMfKjlMdZLgDdbSrcqYrvTKN06ML
V33sjS3jZvoMiXD5vrJKis33sz58KhqZDUAQ4GHUg9h+v+bLsAKuXxeF9M0yufcKOoz7QR+x
ZBIvKDsVCKQhmSz+IflYxFfcVb41p3jinnTgDm6fk4xBZLiAnn+6IhgP17bmzt776kEHS6sf
0NL6Bx4ztJSCYXEAmBCJbXqvpGsZn7TKuSbLiAKWZK8o8JLsEwUkKawoOCWFd4IVMV6fzOaY
IWaKIe8yKMl0MSsZ8knmFHOGIZlV4Zw0JE1JZFLqklZK5CnpjIQNWJcDliCDfL4Mbtl0KgDG
Yuo3IDKLIR742qYBjjIY6lccwljfeam8NvYGc47577C3R7Cuf7bNftKONxBokNiMt9n7k1sz
z2XfskzamGcIxJvaG2HTWbwCr8VDeKc+gg/ox2yv2ydTk498aLvQZOOtiLRjCpubfkwMN40S
BTRm/6CJsUKSI7C5SmRDtnpCRQm2le1kdxPvpD8ibqQdrNVnTaIMTunz9a72X6FD+LA+jsct
R+e/R3xMnEHn8HnyKnEVXUdfWK5X3bB53Sl3Ot2UTHejA8RLtn1Ne9MsZaMFyvAnSU6IgibJ
zW3zhGazySSYHWW/+j/hVR/bxHmH3997/jgnsX0+O77zR+LzObbPSWwfzgdcYpqDFEoGDFQY
EIo1IVCXdbSEiK/AOoWxlY9KFKlqs25TxqqpAg1tEAaEtRuZ1HVjVBqapo6PSuMP6Bgs2lax
di3E2e89JxS6SYt99/7esxX57vk9z+95YrFIOp7obO2IdAIhqscdQIM0j5AxesFcqbcGdL2V
gLt1nn2BTua12jrcQGuqq1xOp6ffc95DPSmnzekMBkPH5WJnp6al53Z0ZDKp42lZkhwOe5ra
+eLLNo+u521Ddui3g32MzjFrTPdyNx1ywwk3uMfoJ2fzXjVWP/L4gregaIWX0Ex4mSzijBnA
BGNxR0Dh6xIq5WRR+OxV2eDEKeUxruAb8NjnyTU9L7yNi8xWmQgoleModGx5ZIMsRCtGtgx0
rzFd+ZbsvPz8bLet1Ftq6l63xqxql4PuriolYBTGpq6fEQxT8BgwNnVr1GMQvDJq7cZHBbYb
P4lLhduoqb3MLePEg2BQwia1Mkoa/i+Rfe2zyWwr2rBrHup0OOlGuLv7J6snd3e0+NvKzVb7
5iZ/+VBbz8/lm2NyYBtkHos0FmLwYfOiviXB0/QfZe/uXvQzaVlOtcLvy4sfmY2qXOGzubG8
3r8JhKe0eimBszbYtTBwDlmQQc9yFlmgkBfMiEAEUIgCprqafoXuoAeV15RjyjmlBtQxOGS2
eDa2f4muq6fIdi6uBmdHfHPVqlhEiCeUmEJ0YhKO/CXqE2g0QTkeabCJjtG3zeqgpLpcVSPx
9aVpg4GA3r3L/B6z1jdKzFozqRxgUilxnwuEtalpubTMXbvt1fjWex+0rErWWqb56U2rFaGm
sHfD97/RBzuc5cPJOcpW7mvMMCeh0Ry8f3xFrDaQ21ZhvONDvFcdfmXe8srgIbzkCbk1b8bb
aNOd4lyYm++VN0Of/Gx+UB6G7+YvylflW3BHdrtlTEoOfaHOtcvt+hMyF9TTckrnHLJdlySu
iWRw10k6JENuC7XpXYVlhT6yi2yXB0Nb9YPkgPxt/TUyrB8jb+hHCicK70oX5PHC+9IV+VJh
Qrot3w5dL3xEPpU+1pOLoEdamF8LvdKq/DPSztA78q/19+T39JvyTd2DnHbFVSUWCcfVnMV3
HHl8PCFYrjBucZ1ZEQIBIocIhGSZEf0xPR/QZUnPy5hm8bdL4VBIoi6eJ0TX0xqvP4U6H8rn
VEWJH4mfiDNRvh53xEfMAhQAMbxwRvCOzLJk+kFC+qjEiqLPyJcRyGmmVmYg8tNn7ONzTXbG
Tx75yQr5s5GIMr8F+Vhi9IvkhUBNF1ROgiHLPkMWRIPwsiGNTV06LRmSHjBYqiKVoxdKpBS3
WPYox5hpAXhoNjz0MXALJ+9Gksv1sqZj3gp4Fq+AIfgb3ICh/GrMX8nl+clxfXUiOPkv27b7
25+PNSaTrcoAt32tVpdO3rtms7b3Dz744OC9F3GKTN2cuo1ucwlJw0Fz8UERxJcAqLms7SUK
Yh2FNM365/h3+r9D/0ynqNOvqqLATIoaZyZF5RieiQDDMyGKPqBUFdWAKKrIt9dNb/o4VLlc
QCNhXnRxDAfTI67w+RRBF0yBE0YyLNAKGGgzoGTgSOZ6hmb8Aet78biuwrgKakhb/3rFYm6x
iDcTbrH4gA3argpoExP7KngR9PaGhZVTKLKgxVRTc4khMQNdxBCXkS+IXyZrxc3kGXGX+D04
Bm/CafEifAri3ykwW9lLMABsQWzPETp19FS92EXxd55CkRVRVc9gd5hRg5Wj00vEWs6EDDQP
rLxsekVDDIoGFWrxCBl+vDZabeC/uVRZ/n06YFDTNyPFTIutP9YepMRhd7Q+YhQSn28XKwxG
oJ+by6CHy6wpGu5/M5Jahh3COqJzbmddp33JfSfnmcH83gHb4/d/8aADfrqg2e9C4liJYycm
jhoSISfNWcPiUeexqmOCbQcMOvfBfqetm3drhKvVHC65GOPyHCWcwCmczpmcneupYyCGu9qU
OrOO1vmKgktxUa8r5qKunujGDTPxYGKpsAVhw8JKB1YcKEDEm6xOhVP+lKfGlyURkLMQcGIV
tGMlVLmzEKJ4EvnaLJFstVYYePC0mvYgFVHxfQKJs/Psdgmflk9gHl/0CZgfJ4CHveVd5Tvl
W+W975//+MxzBw49e+r8JweeQ0u/ufzH8sVyHxyCInS/e7Jn39HyW+WfndoPjTAP1v14P3s2
qLm2JstBNsMXz5Ec3urLHW353DZ5a2Rr9Otaf+6VqHNQPtvwc+1a5Fr0aoMjlBZyWspIGulO
Tc+tTX813Z8bylW/QyAczUQXR/8UuhaxH9Xgdw1XpKsNV9KXtTsNjqiZqNN4DxNDFWIRZzyB
UlkbT5A6pbmxTutKLEtgEHXWNmrBYC3lnbxIwkJYD5vh/rA93JObhoDkwMydyNEf5MZzl3Jc
rhlUr2ckmxuDHafi6zc8MC0zHFrajT2e4rJ/jVjLRK/lW4UJdCr5EgY4Q6xMNoQq2pCRonJS
S2WkVAs0RPGUDjW2QDKCmWcakj17SM/KQVOoR3lIdNrUeqUTgYkRsLIbadpj2Y0BjG0lFiv+
WwFZxxfwDgOOhJpKB1lUa2NhTnXCj6Kppa2Tb+LcDERwbsI/z/zh8LXfzhqY1/ZkXd/wom+t
bFlOd5e3DcVwbs6JbeU2sWrx6K43LnmeqKr64dCa4cV+1uvlzfZB7PVakiKTZmYBrHG+ApzD
A6uxehq2wwtwmLzK/8Z7k7hsXpPMB24Vzw3bxuglM88HNYEj9cd5nrmFfjJEbORJnndzTWox
5s/7KfELfsWv+02/3d+jzfBCMzWqhYuCW3FTrzvmpu6e9P/ixQ186hMlZEexa0K4W2GI6Uop
yWiquqaqhjrkZEMimaCOWK2ahTpXGCnhxVPKh9t4oD6LdxWpwcXFhzzBLCREPKGFLLK3BVAj
vqZRKNmZ50s1NDBvR9v+w3eZx0Zx3XF83ts5dr3HzN6Xd46dnT083t2x97B3Y+ypKgiHg41q
AXa8mIjggCD1gYsKiEIosIGixtA0EEcqpISrOMGAAENpDUmJhEQU0v6D+kchUpT0crEUt2pE
ve6bsUkvqbb83szsyiu9/X2/3893TkEuDHwtoIa8nkmG/b2TRw9WPqx80Tvcsb0MDgKEEmAf
UtT2q32HfvjtKze3lJcWfkGPnbbwxPrL64vfeAEEbwMFHKm8XPnoq8qr+B/3nKyMVa5dOnDg
p6Dpy9O7t2m6ElF72YB0FceyYEIdL4eBY1/0jngnaVgSOZOEPs6b6o0YTMAkRaVnsdWgD/ZF
doAdcAu3hd8a/q50EJT5Y8nz4Lx0LXozORtxk/xecCiyNzYSOQXegacjF5ITyQfK4+Rs0urA
PCAAHXGkl7piqqj0Rjamq2qMsLoauLkgLYQxKR7EUCm0CaKHC1YLogprpUgkDIELFcLIKOQh
VZM4RTFUO7WWMgxTJyhIYcHR6uw4OKzS9fFQqBrSNhuqS0aHoLH26py2qUJbDhMuCLANYQkU
rjB5oOb78/fzhnzWGPa4f5J74breJeaphCkNopSTZU2V6TlVpudVOQ8nk5MMkmVpMK01Cn+A
mXzaHoCjEPDN1wW5zBA7f1Wn+DTZJutYkZOSYjoD6li0pMK1GUyMKHx9BmBPB+OVV8AgGopB
nWiuYxIqDRatNExdchXiWqlw6TGGLqeuMAWFoVFwgbm8QjQjCEDX6//TM6VVDFA/r2gkaGJD
5Y1KLsNbWaY62prTla0TMfjLg49eO3ke+NYe7PvHAme16f07x79fXAe3QwAqW/9T3y3nvrNz
PFrZsX+1Bb4Ozu7ZddyJOHn37Kc4gTTeCFepfsePawENaGg2YDQexxKE3AbaoMleHAeL1Pv5
xnzAEMR7fD3+nkBPkCSshA2ruVXEh8xD1iHbVrqf7ef60/3KAeN+c9latu2ly/JZ/GyGcVgz
1qw1F8qEsqEcwlKYxHmW5xKJZKYZNMMWXPErrMIpwoLsgtxi6+KaDvNK6ypmZWKlHOIAB4MZ
LhfMd/g6/B2BzvruTHe2O9ed72qwGczmhNMcTIhmvvhMQikOOgadByLHqGPpN5Wz6Vvx2zUf
yreKU0XXcmNjEOuDwQvgYwDBLgDADWzcsEy15kbqqoOhPi7IsjdC2pOsf8SFhN9ksbksFpts
qbHhUZO+kSKYQa0iXmcQ4y4THAUqG84CwEVBdByIKpO2T9jhQzvg7RfsD+0G+zgsX+NGWZlB
ytTewB1PgYnU49QsChv12Zya+hjdGLAUn1JQBOGpm2ARVgCLgG9uyEsleQAZ3eD05AwKoJnB
QlqeowE9czTsRgsaadmm8TbG/HkazfMkalraVQkwA5PztpiPKJQzHjXXmjJYgtYCyYkWSkG3
VUlLBjNbauUYg+KJtiVqJAeKKGOa1AZe1qNIX+YoAo0+GvwSYkTTOnOv9SVmnYyXOksA5SM2
gOmEbzH76AKu0IWMQuvE1gnsYgqKYdKNJt7LQj2vNH4Pk5Roz7Bwbspj0Ug0msvmM/Wan+Yb
DOclR2m0e8OrcvMffvmDZY9vPpPlPgj4Q5QkBVZf2bzzcEMxVnnnR62P3t28rdEbEKoQo8jl
E2t2rWjOLNvZ+/LrK0YemogWNg0+OXJ47d6u+t5a9oOhQx1HfpPzc2lE81gzopUxnVbuqsUu
0AW7Ql3sJrAJbgptYo1poUVoE44RR4NnidNBCoIQi+yOEcImzQVFyidiHGRoozAOb6lOE5Ax
1WtrcdDo37VjF1DWjcP4NaMp7PVwMqvZm017GWMZtoc9weLsDRjHPPDWZf7Fkk9m/jZd0nyM
RW5ozmlvv2Sms+js5M+Yppmmaf3EMdWcQ39Pn3+u48dME8IJ5i5zV2taiBScYlQ7W/G/7EUD
Y3TcTvxtOmp2ci91TCD4Tc/c1kj4ZE88u5SKMkRr5f2OSLHhyfRT6sUtNufmbtCsnZZ59hFx
EZ1WCviuYwoi/Jp0VtFIn4/ou9rhqc7GySLZSm6jcUmUYvVifWyhuDB2KkYlYoUYbFeGzDvo
kdhE7O9RssmGIgQKYY4L+oVwDRcEgujkgj5BRDUW5QiU4lZTTUJrNw6TyahaCkYV0YFRMUJj
QP88viXHKKBfOaGMKY8UXOH4sMOxywn6nMDpT0/P16CSXoOWI4RD2IBUrd1pItIzYq6hLlux
7WKDEekkKsSr7GFBFCBJSzEpYuOTGGOPWhJJYK4SGCmJxc2SBtVgjhIQImiCQIOPDWj6AF83
EBepe3wU+fq/FxOXPuzzbm/4BDzKtMvuFZP3fve5wi98LgOXZjsi/lDraxv2/fo55O5ETJK+
yQ3M/Pbep2+P7On8K3TsXC5JucjgzMW2e4NLh648gNIuvlb7dhyolbynzTJ4V7VX0SQHHYwA
PEZz4ZwH6CHr00P2ciaX1ffatL6rR3kx+6XjCTclGG54r/t+HhgTvqKIc/7RwE3iKnmdQn33
DHmO+pn7jId4ixqmhx0jnmGB2Oh+0TuEb6vaLRBdnlXedmE9uZEinqc6jc9XrbF1uglVaMc6
DKuIb5EEL2TxRvcibImNkMgEFTfG3XEPgRBKUIS1wn2BwAgQxGg3E6RtRmvQxnnZIDc+W1bt
HorkjRSFwt+FcpEgSW0cch4vuvNyNGIIDFKk6YkXeL9QPKpn2DPlwT2/V9yqu9095p5yE7x7
rbvfvduNu8fhn67ywhvCpoMo+NFY+KdLn5Uwn07w6LdMzNko2n36hYwMVcOD/12R0AZK//rR
gx3x+aBmfqYqn6NAq44CrlVcpmA0OgsUqrNXnYWquFN7+uAiXXjayBANADdJobgXgabaGBoU
UrNJAOYcMZYj3lss5RKVmFTBY4x/STOsWdOYAp1ATRcXEhaiVbIKdeuffA8/3OXiREKSTKlI
/T8Zr/7YJq47fu/ufD8dfL6zY/vOsc/n+O4Sx747iIMvpPhcwogIDSmttoQ2NC0BhR8d4UcZ
P0qXqUCarZrQyiqotoFa8SOs0ihh1MAfRdq6dZomoUlM2v6YQGJs0jSNSawaBZu9ZweWbZq0
O7339b07We+97+fzfZ/P5od/IIK7ci0FHrIIYkN5dIs+ALHh4me9GEs10X6GY2mOsymXFhdE
JdcPm4JAwbCdME6iGIfRewR/dLEFayU7TA6xZ1hKp7JMB2/6TcmU25R203C6KFfutFdQvXQ/
36c8Tw3RQ8wwN+Qfkofs551N1Bi9lR+Xx5Uti3aTu6nd9G5uD7/fv1/eoxyI71Ffsw6RbzPf
jL9lvWVPO9+hj/PvSO9Ej8vHlKPmd62j9lnmHHuOPyefVWbi51rOWLP0LPMxV5Ev2j+37zP3
+Yct99WV49YGe9yZZsmisjWxLfnVHLmB3sCMs0Q/uyrZZ/Zb5LDyFetZmxikB5m1PEHSGAd1
Q7zZao+3JR3a5Vk2HmdYlotDJZBIMBgF8SjJIcULS6bVppiiP6iIRkJXDNcpKm7l0cSswnNq
5dE2L2QztOrneU2B3ytyPJ5gOQ7BNKzE4UDcamEYzbZCtm05FE2jN3HbgY+OJBqmCU0jhvMc
xzA0u+QH1CkHbvsFr+AgxnbXg6fn7E7bmXSOOMRq5yVn1JmoP9x07jqM8yfmj+waXvmxzF/B
VUwGX3i85x/0X/cT/jPdSyr45tkG4j8f+cvtmHA7KlTv1UVztnrniU6uhwYFphYcaFDgXz+Y
A/NI8b9ZMb+nhQU9DLxpoQedSnMXrJKwRCIhgZgSMs3mplICdaoNu2RU5Ev1Dxq00OZ4MUeN
Rg2tc0MykAlD97zBOcKkC/SBwtOJULZ22Kz9svar1tqrOX9o+RLwebRQ7AD8LVMNy01SLCa1
4UJrsTMHSIB3tDTrT0Eq6Z3pgw+uEusffp/c+EZEz2QytpZ+o0rjUzteWKhLTSJDwaG2RV+v
JvE/v25HTGZBBtXeAHRnP4L8KuHve8LeIGiKsXo32IN9LeUTYR276S0IuJYQcoWyl/XKRBkl
9XfJdOdubE9wnzaR3Zd7TzuePg1OCzOpGW0mfTo3Y11NX81c1a8UL5U+Ez5VPlU/c6+Vb4g3
1Pv83XJctARV1NTWrJm3rKcEW7TVJakuw86uwKB9K6tlu3y9TP4sB3blXrcOZactcll22D+c
Ith0LN28tFTul5cZlBjKg9b8htSp1CmoPVUL5FKqJWhBQRNLGMiJJUqgFUpWIaqNnAmhX+pW
XB8gFV9MjCoxXcsoetFarBRzmiBoIBcCIGeVRBFBfKlqhVTVyqeCGFnvgOYWizBxuByLUZSP
GS+BUhYD0GyowAYvglEwAc6Da+AmuAs4UMG/8AK96nPqmEqoCzHtpIZrFfwnl7zyu4/hfG8E
imJYwZ+YPXjXRXFDEtfxu2AOyP8XaOf3AXg5NjYCZdcFuDEjw3UQg+3Lhi5ZoE2zlhJQ9CJJ
tik1lt1mjZaRCIZHAHR4CNuBjcamIt4ehbBOC00uDs8CT/K76Sjv5mFL9zW7ut2Mxq9danY1
sxkdDDcvNLsh5B55NyqI6OVdjxfdHCO6miq6RfgnFwKu0QgiPEhgUBsh2whL//10eXJh9b6+
CigQkbWEsrBrMdQhUIYYBEBHzpOxxQDMO4gkqfFVYwRJSKIXpPe+trZ6pTseVljavlO7nRO7
VtWSizJLJ/qAV/v7q8fW4zsHl9jX/9Yu+QP5PnDLbe1auwb/a23g4kvwiAI8m5EikeAK8GLt
aLcRVtuJTMYnyEMvgKNg6sR6+ETk45kVtV8Ap8sMh4VwEMChQGRgE2KbBNk2U9eh7170YUCs
a8GzpYJnr4uuiw3aZEdkf2Svvtf4VmTaoGK+GIVjdpgOm6o9aPt8PrgKM4yTKUwFrbRptJqZ
vG1/CXj2s2CIXpsYMgftndROeqe5s33CngST1EH6oDnZPmmfaP8AfICftH/acqPlpq0eoqbo
KZMANK6AhjFI6qqSxMy8gjUsQiLaoiRa9WgkAu1OCIKfZhhEjjbDhE9mVI9YJm0zJm3oUV9S
ABiWTCaQpYg0ax7DfqgaaGliU0E1bMMzBo0JY9I4YtBGBT82ayEexKDAzcrVHjmKRO18FgRF
10VtipzTNeRcCQeiO0eH7DzAZx8rm5GR7duRkwM7AILyZcyH6hcEMjBRfUZdFEHQj2QNCgiQ
H/nrRg/MSZp6UYbF+z8sCMLVf5VsKIOvg9/K8tiantrluL6mo3oNWZLa209bK0M63puwVj8F
FMD1tHR1wRKd//LL1Wrtw8f+BJTx4tjCNJfJdHS0rqv1g/fX5eMdMYgSGXq7cxAlQYBfFD3o
CNBWviLJncVAUej1rQwcJqebPmYvBy4LbAYMYMvBADdGvkKPSrvIHfSEdJh8k56UZrAZ7lTT
J1gFfMJVmkIBAaLHRxBU0EfxsHhpLBeCqoEVGA5gcJQFbIXwvEUMx6eDQQy6mDRMOcuolE15
1AmKpGRLKkmrJUIKLlQFIHybiYnS3tQW6ACzA/eegZIUGpU7IwJK5jNVlM9qj3BHROmMoHRO
5bMwhRjMa31knu3LIvl5ERNgJmDhuBByucqjf3wUchs5AamFXYsjRKoAUlrDBr738BDeMTld
SHkPzhMbawNbX14U1uO+VQ+oiR9SteMZ8jfW8D7wHNzJs7XN+KhvC0Zj3/CiHgswmiVIn07g
Ak3pkH9sJCITSK54BaKhWggkHdOLCwKhEhPEJEFOEkcI/CQBiCkfdR6AQXwUx/EYw1aAM5v6
9dr64rfXnRnUJjvgjAeWb+i983gPqj11NKOFglQwFYYNH631gUrt90CrbabB6vvfg/Psr23C
ifo8D3qtHnuSxUdZAGdK0TrABB+p44RYghmC0wX/5LrqY9s4y/j7vvfxnn1n53y2L459tu/s
Ol/+Sho7ySXu7M5p06RNE9Q07ei8WKVqEWw09kRFx0bdtV2VdluDEOVDq9pCGdBKJKgfa+kQ
GdNoB/sjfAgKApo/goANS0Fk06SShve1J4awfPecX8u+557f8/v9nheiOZ6rJ0tDLkCS5XRu
iqtwbIWb4dAFDnInO8AsQIDk+TrsBAYYJwStpVoYqaeZoftKmmnhf1KtZ1oqOEmaaXJsJXlu
IXn+mfvshw9H+X3kH4fWqsw0MwvWgw1oZ+6gqJ3qQsqObqjoQbOS/Z7lhpVRospz4LmuF8Bp
8XSa9ytqn5ytZFmLto3bxm/SN4W29eWy037Basc6CA3BrdYhcSi9tSffN7Rhl3hAPGE5bj0u
Noyrx1QUzE5mUVHoAqlMoi2euk1mWwlIxHosptQqmhItgLcvLZOxEdHZsSgxei0cklgpQ9h+
L9cmmqOeSc9BD5P0HPEgz5eIWsmRAO7I5DIoE2On4pU4iqfbYh03mc05Bysm5uMwXoyALpsk
pVJdt+EBsA5EyI1cdhNEgpFKZCbC5iLLEVSJwMhtlCewuQkeQdN9Ex7IBXxJsxPn7KaOx3AF
MzKGyxiOYYjzj+Q/54lulykC5ehIdaUalVcpGqT29TFW/qBA6LOyulSQq6VstUy+jTrMel8l
q6ST6s2UP5wbTPdrYc7Z09vdi3iLYBUQb4T0EOLToqkDh9+pAcXZELRpMBTu50wN9AopHaZT
oqLJGrSHyKmPz2hU+sh9ifyRE3lH29vbjx49ShSUKCkslQGdIrJKzX+joMbTTvJoCWr5ci3c
sJs9up26OVVUnY6MIpkCdNFsJIdGJwGvSDaQotnTSqOVRCuJFhItJvg/u38MFCLE5MKh5nSK
GjpR2XAI8+5GV32tu2t9o9qouh0uVaXK3OOm6y0Oau9kEOhajwZfWte9YfKLgbZf/GPXjmyk
GSWbI8m5889s79cUa2ODLLkzU/s7++DXYqMDE73bjj/laHr+M/nOgS9MrJveHwrF+hLrU/GJ
mbbgo9ETD98+1u/Ctkzv2YGvwEKmKVY0t0wCgNYerC0xt7iXgUo6Yzl3WG6Gl/gb/HX8bpCo
S95W6NabP88cYl9gTrKvMlcEPIhhn+BqsW10BlwDnkYJsD4VyAY0HkPYF7GIgc4gZW6RcHiW
Y7j3JJXQdZ0kybYx25RtxsZWyGnOxgCbbNNtHeRy3rZgwzbS/q9l0rZi5Kdba40VJa1S0yLS
SquFchVkq6SLso5G8/3qv+H7tc5pbdIZETfrTECHXqtHA00eUdIE8inIGjpsEn0a8PM+HdRt
kbYluTh6lPQDaQFqrgQE1e3C9cpTGwzhlkiXw0Eh6f4IMdh/4psv/epbp6+MfWeiQfdo7Xbo
jHc9Ze45d25fOt2KPrj1z1+ufLXS18dcf2WLVw5Prbau/nF9192fzP3Y5yKKuJlUeJjojAGf
vyawUAlTpj/dHk+BMK1vo20XhzTnOLuD28GP492+3Ro+wB3iKqBiXCNbjgV9EfyFs/TAQTjh
2alNhoueonbIU9ZOKS87ZxwznlfhJTQbvgrfgHfwnaa/C0vau/oK9PBoWNmlnA6e1ivh5TB2
6PD1tUWgkyNIOh74AdWIDoJc0agYCBiyoRtjRtGYMmaMC8acMW8sGIvGsmEz9vvvN8CGO2rE
gv10xHWZNOR6FdPfyYjGO0EJjkpnJCQlZdABcqAIpsAMmAPzYBFY6AICl5/2HvOiMS8874Xe
m1DKKcs8BLzM1z2Z4/Oh/C30ZVCDvlwaqRbKpdVSYalUAz4azVarpZrYLClENHp7e2EvEXcK
ISjXNrLEcz2mj1D0htPkZNmE1FZkSuL5H8p1bkLiwCUyZYdDKJ0CNeDJdUttHKLEdNVpyAxH
7h175W8QXjv5g85Yf8AhhsOP7NvwiYvTe7f3pODj19+E/P170H5mpDnZ7D4UDAzvvXjpQT5x
mLAJDKwtsRxhUxDEYeIWSK7NXx0cTCUp4o9GE6li8ln2We4UW0nOJueTOJesJBFIqu3u6E5u
pzAePYvxFgz1ZI910Dph/Tr73fYLSTyfXI4iXQe68SMCnkhUaVNGH9Wf0Pdbn9Sf0c+D8/pl
fAv/rF1sFpwt0kYl4Bxw+1vUjVrAPxAkPxPZmBtECHrBGIzFgowYBKIh6VThFXdRraizKhNU
Z1Skvtc2xpNcr7YmUjS+Npjm84n8kTohicyvlgtE4OmLWC1hY5XyUa4REsgf89LbHGWFlkiz
0KaDKEtOrTiiw3YuVmMirHOw0EthJCCWYLlUiEYjfF0XFaKL6Y+pWFfHRi6cdiTQf3FCd/KV
4bOLH755eJRQ0hu1QUe8wVB9cfHhcoLPfCq5e9OeuSf3HNi84cFbb8HBke+fqzHzwZ8uDmqO
cOlteG9gyhz99N2f/46ito0wdAczB1zAj/K5JmXSU2gqgqLrtwzXpGtE/TVTzWlmkMJozQ+n
hCAlbrBWqdZUbXlPeyLl45ssu51PqJONn/Ts8WLIWHhsESTOPcRPoxf5k9Ip+YT/2+iK57rz
N+j3DX+QV9C/GKdCPFeQsSwUcVGYIjY7bXkD321YxhILse04YiwUdp7Anu+2bEaDltHgOBq3
7EVlNO2cbvqG85LlkvWmcN0yZ72D/ooWpRWrS1jAZEBcwEjHM/gCnsMsfo51gQ7VTXN1KqYy
6T7iPu++72bdbt+vWUg2vguE1yy1PicN93JbFJPtFMXHfdAXcWD8jqC2+swGFR5Uj6hnVEZd
cbkqAuwQZgTUIZwR7guMLOQE8gjCnLAo8MJlu5sF06S6N5lYTumw5+xjdgbYZbtuZ5bt0E4z
sZBi2vOB/EeST2aJkdUS1ftSgYQqGRlkyv8ylYBo2fEfrqs+po3zjN97Z5/tw9jnD2yffdhn
fOevw8YGG2xw4gMMzUwA56MB4hFokm1qtwmDmqzKHytplmVZq+KlSjuSKiBNzaLuj6aERbRa
mmyqonUfDdsfk7Zq6ipl0aoMLdOiaNoK3fOenaadzXuP3/fek/Hved7f8/tl23APn2mCHq4K
DUwIqiAlMhlidhL1j6/SBCLJ2QlVZuCX2ujfInTwZQ2BrFGJZRth6DE7hLF3wgGX+oqnNvPU
7tVnTG3G1GYGdaaYDNkmlstygiXbCEOt6C80/wkb7cT9o8tZJxsrJhvJD0QDVU3/CR0+fGr/
yZiv6Vc/fO3uP6+eu7l5Cl3Sstyhzj0nyJ7fPP30oWfspz9C6I93ke7Xr3ePixnlOPSRUYKg
jmlfIGTUrGx/XlhsWgxSBapg3MGdpE4atec0qC32rL9KV3VL+iXDBfaC5XLMwNKsjpyKTskk
rzetevVnWtCqV7dG6RVfwLvkve4lvRZRciK5BFIyEY1YLbRex7CQ9DW0+8oCyMc18sEKispr
iFUawxFkNVvYM2YzEnECr0xPp9TY3V2L+Xwtikk1Kg7en6qaEE77lKliumFaN9EmrvVtiqZ0
NbKfrGVqeAPSqQrHHIQ7k7fngGHyQDSbc7n8JgjHNllWucUqheyOoNQUlBxhngjZRR7VGQXT
CAHj84a3EwxvIN0BakuVWyrj1wgfRFZTRxO6yEvb92z+ORLu41ZWxn86++R4d8rr7Cj6fMG4
wv+d2rl5cb6lVRTDhYPk/h250+8cKcQy3rT/mzZb8mt/6NtBUMS2rUHqA+jvPcSXiAnyr8pz
VkfpleBiJ0XE2DJ5NHp0D0lE6Ti9+3lBk+8aLc90HQlWyguaBe0J53dcC+nvbz8xsDD03dGz
zrOuxdE1zVvaVeeq673Ue0M3yuvlv5TvlT1uoamDTds7fWXtj/XFzryHcFCd/qKH4PqtFtZs
ajQ2MAaDzWY36EHIWyWcArsxj6PSYG3IL0lvSNclSlpDFxTTuDzvR9Yl/xv+637KX9+qRtjp
x1us1SIqKrBaVGCpWLIj+xrSX9Wn6cV+1L9GJRUjV2TaOFTi5jmSu0b+nqAJAzVM5OAWQ+u4
XWhXa6t5+B0qAYLAC9csMUwlFBebQDOJhcRSgkqks3Fqfi/aK/nCKIz/z2anO7UQRqPhSvhG
eD2sCR8RyomyUl4GELRltZgajKmyaeHlQTSYFBzI7Kg4bgERrZHXFNtiHuWTCapEkSUKERRL
kRT+RVxzCser8CT15P7y2+gZkGHMm6fBQD6QscRUjcnG3G1Wnn0AdDMHMuM21OQGu1Fnns07
mIfy7MYcex8GPARcBDS0esv/oZ+cnJi7vwHNC8+lDyU8xzVssTpVfwMD4fjQ6hwbGuseENN8
s9OFtEGpPdmRTCUpujc4GoxL0eA+aS+P+B4vTwylhwWiD+UFYps2zxOl2DBP7Jb3CqjgGuTR
46ExHu0ba+72wHZPD7EzWRTQUDHdqZD9AjDFdk2ORyNtu3hiT2SXQAw4+3lVAtec0aOLenA+
e0XhDB1XHdMkJtNZlToVJs5CDaRZK7ZI9960qlpqAgXrDgaYzakqaDoQqAsq1b441XddW4dU
CwRv9SnUAhucNYEdCiL68zOYp/fu/+3yielfyCaK1lJm+VuZd18rPNbq8yf4yvvbJmeeevW/
Pz851GBJ66ZSchY1FQ8XUqWdBwc6tv7dlug+fG31Jx2pcx+hkchLE997V9HSBqeb0dI7KvNX
7cGs3SLoNJTW0FjZPXvozFh7p8sl9RkO+ZK+wAHy1NFjF8b65o4t7e/75HjHuJQQtz+7I+Vw
aKCpEI3Avv8CZddJ/EdpyyjRNJOZBhFglszB+Uw1o7mcuZFZz1AyjUqZ6UwFLykZJOhdEa9l
jTIrlpZYxBsqtjARL1sM+CPe4BplUuKBdCjem/KmC0gIdRJEc6tGB13CYmEZziUaqgy6zCAz
U2GWmFuMhsGlLsUIvxj3xUqx6VglppmPVWPk5RgCsondiK3HNLHproug2NgHk9hBbardFEfg
U5x20Gw5S7ZmonDW1bq0u3mtnpY8QV7L8Uind+uaMa3W7RKanQOlDadDRhbMozXXCtmtc2wX
kKwq2GidKtdgFYT0w0VQcWh45rnekYrHZmISytb2JqWdoXyFRPKpYlN2cKt7W8DuMvvcTW0m
ZNW+uHnw2MC+Lyuvb/1sDMyWKIaC7AgqvHygLTW6xR+I+0TRxmT2Udtqig70RQ4knA4y00C0
EB8oXFVE02JFrIrL4j1RK4glkVTwRcR80N6eUmOmuxZjiVoMSGpU4pw7BRmzFVsaI14r5CnE
9Qpef8HIGW1VGtFZgmgx6mxWpmpAhiymlpX+NA6KOZ+mvm40NnKNokuRsy685u7sTlVdqORC
066Kq+padt1zaV0rgZUfqfnBImUDJwW09Uat3wHjAF+w9eyAtFFPJmCPzWrdseAzZPsMaBXn
0EOgI9Genmg01/NtLtm71d8f9xh0XjcfNiG79kV8IxeN9mz5N4V9WUDWnXscPXG2VeDMIuD4
6aGtQbSgXQAcI8Tfrr7qRjSHZPwzsl3pRnkFil2RS3JVvmS61Lws0wJM5mWKhZV1mXLrwyGh
N+QNFzib2xDlPELEqHOsIZNiZevAGXWe91nzkg3ZsPNojdYgVB5LU3HZ6XQDdqLPVxWQWUDT
wrJwT6CElaj8Oz9GSx7BWi83zG7mRtiBrxTuDN8HyICZgaPzefwpn8taVLIFhnrkRFjeazI3
S7zZxyOvyYNpED3UCiAOAdYvglr/hLWCo+P/sA3LuZwMEM7/crk8nvS7PZYn/K644xHCC+rt
qJzbEj756t3bfYFAe6NuTBr7AfnCK7JfRRkRFoLQGKFau8ge5VNz1pclrTSL4O8lw1mm2lA1
njefs5y3nvMtZa8wTJbLuqfYKcuU7xvsjGXGd5403PVu+Mh5w3HTTeqm+WPyY/OG5R/W/zFe
rrFtW1cc56UokaIokXpSoi2KtF6mJethiZJluREdO3ZsWbESxw+ldasGxrI16SJ7yPtlFE3T
dl0m7EM3IEWcAUs3dOiidMHmDhtgZNmwAgViDHsgX4YBK9YFibF8yDYEC5RdUnbiAhswQrz3
8lIQoPs/539+hyhYC+6Cr1co5IbpRfIITcTRLkYICqF4rhf0MriTmQJ7mL0C5mdmwAz9V+Yf
jH7UutN303iT/AupZ40uxuf1+Xag22mDyUrbzRzlpXmLzzCpm8Im9RVmr3Wv3eChvV7eN4li
DA1Qq81uZzw+jvfEoLOFO0jUyJOqsYX9mXB8QOYzQ0gcMdkZJiD4HAJABR/NQAJAHQCgAPaz
PoW2AyyM0iTDuMksgrAr4L4y7qY+NZlIAzx3j8dNmhLUEoU+oMAa9WcKrVGrFErFWXbZDdyc
Lwdy0AuRQDyOxJhYI7YaW4vpyzGwFKvH0Fi1N7cCjv9YfP+rWgAtwOa1pNb1XcziP9Xlwzlo
kU99sV99Vej3wBCKqyWbzUH/679gibkjljPMrQvExgKBX3BvZCizDpjV1nhBfXcLx2HOLi4u
QBKdWwRz2oUsIAtaE8I8+ZvigMXU1wmxAN5eBerfSedQ1UZMOZM6WXN0azK2JgpO12Fga71M
ywxg9YWMq9ZTOR0Ky6LTYMBxu1ZvVUfIqIUUqP7Atow4u9WJJ+6OUYQYAhf3vDpw797+jkTA
s605GGrrbH7uiZWasWG/00RbBM7ZZQWM/uLj2u+HbBTl8KKCgMbyd5p/PCXGLWQgAJx2NgUO
NNcqvW4QCFhNrLhbt315pM3qV6P8OejJNIxyJ3Lpp3V2lX3A6litPxhOq7PSl8unAfuReT5T
ZoHCltkqW2Pr7BX4RZySeHysA0i8Iex3hM0Ddt4x5EQQ3EAiIGCmNn6G0gxWzqfrFChToErV
qDp1hXpA6amPXFsMtlX5Cv3PLBWijdYyQEf9ootuntEpT3qkWSjEOIvPzXVagVV/8d8D071e
zTF1yqURrfC0ctmQgOQ/A4aU9jS+Vvm7S7dUAdaKSgYRM6hXIAAIEu9eQR/f6MhKfBIuFFPH
uMSPjHVYJZ6FDHDDH5H4xIrOfMM/IPHDcKFs80+FSwN7+akhQsqWlJzUSSB4cGR6Bu+P6oNR
ijThBkyPjwwnE26WrEDzZKwBMSGAmtAQUGEFyAqdlWKRQG8iC2rZRhbNqnuu0sxAYHzcVyqX
0KVSvYQiJaaEllQ+drjSpepsZQXdB9PlnHsFzJ9XUyayabrMQ5UhPmtN/btUB0bU7qxf7dHg
p6Tljoq9qgUjT+liky86AhRtDvpDAUpsBxa6wxLcyhcQLyIAejEMVQ0v/gtkbISx1rnhOPtM
uKfb+Bb6+IJxp0B53tb95dT0aeeBi8XRBdFlJjPPNfvteZElsbbwtHxwHEWdfcPN5HjOpBej
Exl5stuTLDbzhR5Os/cwDRwR9P48Heqaf+l4sTjVd7p5dFpwQRhhGb+1DN6uxRR5pynSLGqE
AhNiD9xLKt5otuncl2kLBNryU+DFb0dbZQDGDgV58l8wdlKAUPpkyJOErEZNQi7LVbkm12V9
NwYUbb0EnxqyoSGvyWhDBlW4sSrrvIRL4ukWWkoSHxjrICTeMub3Sry/hZbJcNdAgk8OtSP+
nhTORVE84PfTtIVkXQG8ToAGAWiiRiwTtwmMUNGyTUp5A10+qSxVpZqELUl1qSHpEImRUElN
NyMME6mabuFl5P/HS5vbozNgQY+ObQd6g1vPbYoPtZ9bgB+IlzBVwf9kS6jj1s1nuZoCxe9+
q3hIcFlMye3NvF1JkdhA6dhRk0WVzzGchFy5od76zeJ0/+nmiRmfR6NKegIcO7PwWtM75/JC
fUbmwd6rOzlNHRTZ8eQz3cdQHRrxglllh23JCb7v+onrV+AT4y3vHaPB9jkJdhp3uGac58E7
xrfoO224T+mRMd8g1HDZB37t/IRDFR8YJZgggrNBwmTD1BOMQPufgLpiYE0dy1gVq2F1rIEZ
sPuUAl8q1DIscIP8YNEd2cU8XIyU1lWOjxQbnZPFRnn3vusUP3rdh43u2Tf7C4R6sopg8PY9
We3t7a0Mzv4c4XQ9CIY4dD13mbttWx5hglZUWFrXFMkAry1oCaHB9hAZNISstEOA/5QTgMsI
V24cruxmRgBtOjg4TayAePRwaNWfpxfMXKB6LJQQDM4q1iPoEcNJ8qTlpO2464j7SDsxV4F1
UO0ije2MNdcGb6faRJo2msgetXU0bDSImQzbofaCto1WEEXWzh48evvc7ZMHznw6KR/cvvza
y2e/MqK7dvnCtVOPl65+/cOzj44NFC6f/k3zT1d++fCdKtTtyaPmmO5nULcwkgOYcpbMq3rk
mFHmeeYtK/ZGFOSjhXwx+nz0Fesr0a8RJ6wnoq8TV/G7xCOjOZGfTVXSh9KYkgdxQtcp2ezQ
uz1vdNihg4f9SFicCPPIEGqLdOqwGJMBmYoBR/FY0GLyuC09SR9ZJ9EquUReI3XkPQHVMLdN
EMpiTUSXRICIjNgQV8U1US9W+24WN0pUP6Ml0eK6WqY0mLWyTzsAnYVRTVbTTIjLuJkIpkNU
KBGU8R4BxM1wSBkzAkiaYgJk201xtJ4NgsdcRBdMOTMazzoduHbS4U2XTLm2NGn6Vn71ZLWz
V90UBVxo5JsTb7+w8Gbtg7FMZw+bKzYFTzZsdzJ+3h0EaaPl1cn5bbtfUGYT8YAut/iHEy8f
ev1365fOOenu5t0XU3wwCFym5LxufyXhtpxrfnDY3ze760sf/3Zhl9umZtlQcwxDoFpelcqV
H3E0x08zOtCtlU/BHS53o0r3Uvf3Oq90YwkuIRa6eiMTjMIp4kTXzsgsXeYqfFnc1/VS5DCz
n9svHu46zSxw5/gF8VzkPPeNyHv0u9x7/Lvid7ouR37gep/7YfuHkf/wXfaxbdxlHL/fnV/u
xc692c692T77bJ8dn/PmuOkFaK5r06ZdS4qGaLMtS7ZuiMGANNVgiJa5oLWrNpFAK5UsgKsC
UhHSUoKWuqvapmOCoY52CFoGQmx/RFUnajZQ6D9VEp47pxvwB5Hunl985zvreX7P8/18z8Uu
Fn9b/HPxdvFusU0v7c/uz0+KJ8QTkYVS8AERpckWwA9zDT9UiU0kCUMpoMKwwBjZuBQMBlpU
FUsmW9zqGlgSTSF8DFXRLCLQ33JdXHRXFL8UvRZ9P0pEN1mbnvXaeN/EzgaUGMakS5cejzT6
l91CC/bajJQyebE105rTsbwIp2zM0JEZKejNoroiCa0EVV1fxD7iFrdeUMJA07Zgnnb2Es2S
Qiu5Fob4glTevtItro9HpIee3/bc71Dkl/ZYrq/yLfPx/vGTP9r/sYeJ2buf3dOtZbMcY4Ns
PTX0zyvvoayua5nlDvQyTM2Ll88tlEGzwlC0s1CvPPZj58sAGmw33s06uMN+0xd02tBoG0q6
reKRzWHDBEOYS5ibMZpp4yM6h3xS1bV8XAiFhgkCCwK7jAaQA+6wPdmG2jAe/F9SR1V9Sscx
nQOWWdDf0v36WMEleEjjhzQysbhvwssi15hojPBN6rAx7iPIm3A1JeoKStPerfHBmob8LxXv
2P+13sGejLE7KkRLnWL4vg0rxS1pmfaHDSVp0ihKzF69usky1w1ECo+sbNthgmBkYp7y7z35
Ca3p7B5fXcSvQ3a6CMopUJZs4YLQ7jC2lWdsKTIcejA3wx3P+OkgnacLY+XxcrUcYMt1pDtH
YL9fCV9peT3zevaPxo3Mn6ybvpvGzcx7FiP0WyPWl0oHrUk0iU8S1WhVqapV7Whpsj3MIhan
CSoU0GjrjfRvDFIjYhFBi8XlgmpNU9P0jH7MOJZhhGI4b223hsqj5WcKz1iHW04bs+VbxE0t
VCC7EtgFPIGSqAM8WR0V57AL7XWkOHyblJAvqAklqSBO0RVccS/KF2LuxbQgZIww42NNL/gT
6NdYe0dbF4b5s21B5Rvg2+rEFicS60hkBQZ/U0BIuJZ6J/V+ikjViYjDjLNojB1np1iCraN1
jmwqcnuSRKRVM9GYOW5WTUI3O03cfBV8YjfSf37/vfrvbEwsecyxPLJpz9xqCo0M2x2gMHOr
CJYwQxuLcB1kzqWRRa6xhqStNugTDfiTCTORcJgBW+eZuWEJ424vNcCrcY2lRnPtLb2e1PKF
pM7xgWCSB2wNFEgNtmVCw4J5v4buNabLMPBw6m7wDneHv5v3jQwD0ML2gw/lGqrhNaLGvBSe
ik4pU+qUNp0+YdRKIVBGQF4MxBNuYzqMjswL1kxmxvKPDLt6yed12abyso0c2sbhUF07SNuK
CxEybbfDR5Z3UHaISwj9Lbp7AnGdU20vyHamvnprTrSNZgC/dGtetC1JbD5LaD6LBSvqCPAK
wbZ0wf3OBw7Lwm2sTXBheE/YfcAHjhCG94ThHjgk3juw4v/7g9wMQwvyxtosAnva2uxFT14M
vuzKjWthM576uxLl8h4+lcp99eEtn9GTo9+9cuHpTz+ViraGUynth48N7H505a+l0szX1+0s
85wQImZX3jj2+e2l9flC+9a9pw5OJ2gFbX3x25+yBx6Z6rN37/teK9siuawdWf0H/nHfZUzF
bpzDwqu3nI0hexSN4nh/fJqfli9FL8Xq8i05WIujowoaCg2FR0Oj4X9JwKpRyZSIWFSSFQK5
p4h6EhHRTl8dqY6GiE4cR4FQhbRYJnYt+o439Z+IqG9iTB3ddiwdRl17R/xMHI9jCPl8/kxk
l4iqIsJETjwjLohvie+KAXFM+9nRezSw7GE0N7I0AsQGWx7AennRHXRcAy4tIhh2mKcbXZ2g
757MTxQRX44avDfve8ueGuQqvFFZB1OuF22/caOcT23gTaO6uX1P23d695daC77LK7/fsvzy
8IZC/rG95dG9+OdSsScHc09AtnBg32XiOJbF/uJUkOmKsW66XXnG9PUwvck+fTA5qPsVUhxy
uSg1lMiaBmmijcEEuVlnsnGyjgYckcayWRgEgbjV0kIzNMOkdFcyW7AzCLFoHNXQNeRDru3I
CrKSEYRd4pSIV+F0RiTc/OhrGYL85F579r8FAAYAZAoS5dqORtN6uM3+ofPw+pdTNZbXWEXD
OF7l4hrmuY5Dh2BfQvd5Itrd2+o3KvdSBoIQrKTWEgn/mRViL5uKJc2Wlb+XvnJgYOc+S+sd
RBuH+4tfvN9+kDi+fL22VeONfa9V7xt+sYqmN3arKLs8U921bgce/GQvnoV88pDPBuRTx/sc
SniA3iM9JBNyffXtOaaSdnvw0WglIkcUg0rTKV4XMpIu60ofZdN9gi1V5D5lO7mN2kwPSAPy
NuVJ8vvkNPUD5SW1lv4pdpr8CXVKPqWcVi+Sr1Dz9Lx0Vn5VOa8upK9Ld+g70l2lVKOQ+5Zf
dI/1eLHY1YyJQjNu3dqMptmMhtGMPO9Fx5G1HjZ9AKhjAh/3H9AP+Z/jJ9NUH9lD90i2+qvA
QuptJfg8fVQ6IhO9wqCEi1IkIWKqnsAEmk8I9dXDjkUpsi7JcidFRyiKVhUlQ5GwIoMBv89H
ggKJAqgEFlBkRqqjuCOM0oijM3SNnqf/QPvpg5Tq7h7OCXScJM+RV0mCPEjJTyvnkYrpGAW/
lxV6KPd3y3EvznVX3HA2VMGoBQqn6ujSPJdG1XQzG3CXG+dZsSflNp/MgY2ZWBpxR5eyLN2U
YbNJS0rDjRNSowkb3iZzO/BIUz2O+Nslb1EEGWkgbuE/zwAhI2Dd7s1Db88V0QRM91doPRbu
J2Egn4VIZQAP6qvvwoymITi0aJM6DGk4PJrHvFEqpqLNMSqKHqHnjEoqGgCmQQbK5VyqR7Oa
WYhev9FKMukeVOyJGNrK+cLKuVg+yXcTx7M53ehcCeDh9f+mu1pj47iq8NyZWc9jH3Nnvbsz
s+t9eXde3vWs433YY0x3ouZJ42QbkUCCFldqAwmKaGwRpZGwbAm1doSQEVCo+OPyp1FVQZs4
dRwsRCoZKX8K/kPURkjhh1takYCp3CiC2ObcXYcmUHZ07zn3zJ3d2Znzne87yZAg+XWdlVN7
HvyN8dVKWOBJlQxurfquQJ4Wme5LYYe8+q56NWaCEJN1M+OMOqeEM87H+sfWff2+FSAbLndW
W/tuJNKVrOPYz9WSmpZO5LDDikbSKBqucUS5qFxULxq8Xx/ID5iHqANohNvP783vMUesEXuG
m8JT8g/0GWvGnnJ+jn9CNutL+Jp+zfqtc0O/Yb2vv2+tOGnKx3IdUVYRdM4UrA67qjyJn5Qb
vsPcUfWwfcE/i2fUC9qF3Iw+Y0w5yrTwkjJtMEHhGDqHz8ksZBo8JV0XEQe5hhU5hTO5bCpD
2cUUJYmhlJTWUqk0pOo8b5mZxa0Jz1P1fIbneIHL21bEti14yrrZxwsRnheAF7RoXtQjoqjn
8vk+VYuoqmYbOQ1ELWS1SFnZJXQHUjOF7synkSSTFaZCwAqiJGEMQjdD0SSIqCJsgdRXl9C3
oOjy6DVPsjy42Xze8mceSCdEEGaXrlynTti5RcR7US9RamjoVQ39RvuDdhtqyY/yJQBN4mpG
0hHWkU4S3B+o6EsIUwYVBdwEPLE0aiDPmDJoA6jpijBhlvhfA3h4IDIRmg40Za1ZtAWXvg2X
Wq9yre61YaMpG1E2tjO2Z79lX7dXbM5+pvc/fHV3vdAc0+J3N1ZBOY1tIwZCcQjAaXU1DiRG
BoEQAVCcMBm0P2CGt4+2f7ct1gBTbWyFAFv8Q5Dxj0YKnwe3/505zA/zwy0YjiHSPI0TWdIs
EAQaOBKoE7EzD7aToC/pKo+YCDFrlxVXJybaWl2KtgFJPgSPHW04mgR9bTA+hOf2GuWYNjqD
aApYZfl3FdWMDaMr+1IRfuWdiOmi7Ffszd/bH2x+qm/eSg4OA0rZVFe6uPEP9MvpYSXE6Dqj
4FwkuvEJ+lct05midT146sFf6f0bVxl6fzkIyZOgKOYvgNpB5oS3Fd4totngbGhWnjamKzf9
N5Vb5q2yIDmGqPvzgXHxrP/Dfq5ryJGO11in7qvjujxo1C230je0338IH5L3pPYbB6ynKt7Q
Ue2o3hg6y036J/GkPBmbVF7m5vCcfFFdMlIhn4QlWSqmcVpOF23RVkpDIh46IhyvNYZYA7AA
nZZZqVRFfyBQVkWB4zSjUq2Uq3p4NlaSkVwNBIOxQHJCa6RQqqQ/n5vM0bnZHMppuuO45d5P
bNssN+APTlRR1efjdI3j8lU9Uq3qgZhp9pUDkXI5AM9aFQJK2dQ1/2DJ6zFUkQlUuKrUhbrS
6WKp5HRiehCISJYJuzhsL+rtTaWSYgA0ytvPx1DM0RdRaD6jIY1UsgCuetpb2p+1NY0lAcIq
2hJdo8oUh755ueqYgMB5qozKS/Q7lEsN0SPz2XcBDIV7Tega8EahWRi7C9qtne3Nh6wBWqU1
4eEmaVVbIo4kO7Qh06GJdmoTB6lhd6Kk3sGrTdhWWiUTjGapCRHcWuLv3gGP4/FwaHg6hIcn
lpeJWeaXOTA8RCHlx5tNwjhj1Bhk+zXKD0ksuv7FrftXBVchrQL4H82DjYL1hC65HvQSuK6S
KCyI9TqVUN3nhf11ToWpRrwhwqhgbUsi37a2ILl6RiK89d5lyeUIciS3H8xCEE4EWxHSYhgZ
MmSIyeQ6UD4troMmpGXkNvMlgi6G/y/DUKAfwVhyZRhFL+p2tmEYa5sw4Z4oaWDWvM6oW+Oj
rtUXcW0YMh9zhdaXxVzbk2FE3X4y4JcV8uswyOWX5M/A/Pjnv9sa9NgJAvyH7cwAgfpDHuY6
YzElmq32k6hpkmLQWhMJPkD4OoHetLM5f2znU/u6DVTbkd9xZGL1y/vczUav1um99ONdvb2b
f8wnjOPXf/Wlp78IpaBLUftx98mTz8ajSSgEavf4xc3F8zuYfD4SUpTm8vLXZNWk83lfJHlu
68HpAcLhgc09zDpUg3502ntDwPCqQoWXbbqz4sSeq33P92IHLQi+MK/xcaEQiRtCPpyPG4VB
VAtXE3vDJ4WT4intG/FnEyeLL/DnxfPaufh3Ei8UL4gXtFeoV4SfxX9aWKJWKh905IBQC4Vi
T4+IWuJNI4qv2L+t+Aw+o8XjfT1iBDYUC4WW1iv0wCU9cYEV+SJYDWiSz22rPpNgLwR3a5Zy
blKqKEpcI1SXmBXRbXFNpJ8Rz4h/Fxlxoi4cEkYFRpiAJiPkJQs3pQySMnMZOjM7WkSlYr1I
F7Vy5fXsa9AxFA6CeBtZbY6tbqxDQ9Uc2zi4+8SuD6n6yMZqoY1MACFqIZF/hHbAEpT+X5b5
jFnQGIFZ4fPVWUuetVqLR/rbAWS0GCOA3oj29mZvvytzfHcB9eiWKmib36+9+fQXDgz0ZV1L
TO3N79y8KmU1rJQhHcykuXuzH/3TtsKCPwj6Tc2G6g++/eLMrmJPOSY9cWyOnk87uQAOQB7Y
wAqnIQ+iaNQbDPOsys6xc8G50OvsIsvNKSionA3uqDWor0qNKJNglVCn9HX2sHSbXZE46h7G
O6Mp0sLmvX6f74qY8rMhScozbIRhWMZPsxIKhJQgI9EhtuFDvr5goAOPSkjqQ7QoLdFPUCGK
pZ/wigxy5uBunEYQ9QW94JkgE4yXlLpySGGUgOOvUjSitZjyi3YJPbg+NrK+ehA378FbW2+u
Yjigjm6MD7cmF15Jq3hClwcDNPj0xLKK8F0QVp9uG1L6qPECaO1W3QttrXgCVDmmDyaWJFkQ
HMkjq3zMlRa3/rQQc1krQtz3FiIueyZM3B8uhF1WjRL3o4UouFLLvSQ9XjSgIhxDTLaKst3k
XecGslGU7f83+2Uf08QZx/Hv9a549OV6YGkpLStvLaUFCiggpUBFxAIWGaKgwiYbhSH4BuI2
k2WdU7e4/eE2YzZDFrPtny3TbTqJLmbJfItbtmQxxuyPLTFxL9kSzMVsZokC+117Ki4smMU/
77n73P2e5+55+nt7nnsqz3i2W3/nB83G6Su9wYV2zpPEYuow0zrYYhX1jG36tzzWa8sta552
3bmSW5g1QDN35gZzgUvRCGCReRoaNj+kAzK0zAC3IkxbrV9axVvwRybJvuzybC7l9k9cLnOh
CRosYwfY1dohWFCE3SEPA4FLt7rsTk8On6L3hHImrCkh/QSsLFg/TSuTy+mKuVj66HlDJnvg
CC1v50yCU4gJrCC3JXOBT8yM2VbsP8XsOJHdsT4xiyKTUxQVuigTqC5COzo6E+FglJBUkXqJ
bZGc6ovKLGlmJftdczczjV0rdclGY2FqQU1z5bLhvZoN0ZBeb9AXWgpqIkvqN+3TDhUU91Xn
GgVTTWHJ8h1r+o663YHuWocgiNW+0vDImsGjmJm56wWGxXmAex9k87bSWKkGjMbLFtBfqB55
dTzNRpk/yFcZ6Axlg3bcGgY6ngEnanlzyDgB1iG7SHSKMZEVyR0ntQGrze44w3iRjctMDeLe
iNz3Q+TPycT6AfHr+HqgbAPJ0MqEpQsSplZWMGf6XXaD3qRLtad4ap2+qoZNXdXaIV9teX55
lsm0IDlYtMjhHunY2RuSdf2KdL0Z13VVKDPZRqukVkw2Y8IYMse11AZMVqc1RhOJ9DwhzqHl
VM/k/eVOCZKs40L5mySvUrk595RTVL0x4MrQGwR9aoasojewbGhdNRv115S7y50JFcsc7u1x
FSnzps+zq3EJVvjxWqhm3D5e/KH/lP+S/3d/0i5hzLpf2Gvl0m2OfDCcKZv3GtInvKE8PSZS
QwZ9aZ0j0FbEmIqcRbEitiiejkfymfxzXMCU5kyLpbFpsl0mW0np7ESUjbrVM9UzMkkrw+TP
dMpWzc6/7bJ9D5qnpJz2P9pHo3U6vVFnsVi8wUhl/dArzNOdEZ3OYLRYUygtKxqG906f91b1
1FDS8XzQVxIe6Rw8luctilbnCkaer/WVNI5RYkIpO+dH8xGtz8XEccrWxbO4DGgLiT3ELWCB
B+ANQPIXgP5twED9hMcA035AHAZSY4A5iTiUII2wLAGsYSD9VIKMK0Am4WwEsmjcHAHIPQi4
1gLua0D+mQTes4DvGFCsAUpozNIcoOwmsHgXUHEVqPoeCEwDwXGglsatTweW7wNWfAyESdem
dxM0hx8k0gq0fgq0Ub/2dqDjb2DtAWA9+aFbBHq6gCe+BHo/AJ4iu/ouAv19wDMOYPAbYIh+
f5hs31YGbN8IjNBYY9TnebLjBXrnxTwgdlXlUfKSkGC3mQgQvwIvv/r/2DOuoqKioqKioqKi
oqKioqKiojIbaMBALmaw8o3JIJIwb4m/jGSd3gCYxJTUheY0izXdlmF3ZMKZlZ2DPJc731Pg
9RWi2F9SWrZocXlF5ZKqQHWwphYh6tqwvHFFuKm5ZWWkdVXb4+2rO9as7exat35Dd8/cP3hy
4sTn+Gx+xR5V4fAcXdMhkqm8lCUVSAGpTmqSNkg90i7pTemgdGhmBqAnbqlQCkpLpRZ60iu9
Ib0lPzFdf/AQ88Qs0a74eu7CzqsTj35lBJbiBUXmSDYrchJJHnkkLplaPAgqsgYC+hSZpfYR
ReZIPqzISSSfrW9raGgJ+zoGN0dHW6PPtm/d3LvlYdtQjzY00NGCMHzowCA2I4pRtNL1WbRj
K9V7sYWkKAYwhmGqjTx0r0f9HnlMK+Im+WgrtOQhEX4spbbvKK4s1ck5zAF6wnMkybW7d/Rr
Ug1g7pV/h6mOCkKUGYd4eZhveYEdVaKleefw8MWdPz5pCv7F2/j42+9dzzwr34+3XNPf3jH1
uhjgBarK8YuP/M8AqnZw3QplbmRzdHJlYW0NZW5kb2JqDTEzMCAwIG9iag08PCANL1R5cGUg
L0ZvbnREZXNjcmlwdG9yIA0vQXNjZW50IDg5MSANL0NhcEhlaWdodCAwIA0vRGVzY2VudCAt
MjE2IA0vRmxhZ3MgNzAgDS9Gb250QkJveCBbIC00OTggLTMwNyAxMTIwIDEwMjMgXSANL0Zv
bnROYW1lIC9CUERFRUcrVGltZXNOZXdSb21hbixJdGFsaWMgDS9JdGFsaWNBbmdsZSAtMTUg
DS9TdGVtViAwIA0vRm9udEZpbGUyIDEzMSAwIFIgDT4+IA1lbmRvYmoNMTMxIDAgb2JqDTw8
IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMjUxODAgL0xlbmd0aDEgMzg3MzYgPj4g
DXN0cmVhbQ0KSIlcVglQlFcS/rrf/88QUMQQwZvBAVQEDzTiiURmlKhEQCzBuC4jcoiiuKJB
VhKPrIoYNR54xWTNhRENg4qiu4nEmNV4lGVcFV3L6O5qPKJRE6MlMG8bsrWV7N/1qvq912/e
191f9xsQgJZYCIXEseN6RSWPSdkDlB2X1Vcy8lz5V/afOgKscwD0Yca8Apt2vL9R9q4A1sKs
/Oy8mqSqWsArBTCHZs+Yn1X0x/IxQNhRYHJETqZr6hdlxT7AxrZypn+OLLQotk6QC9fLPCQn
r6Bw++5J92ReA/iOmjErw0WDCy8Dbz6QeUqeqzDfazetFDw7xN4205WXGd/lzn5gg5fg2ZY/
a06B/kl2sP5W037+HzLzF8/5fBrQ0QC8a81VgmoMgmR0VLMhGPR1GbeahmeUbjCnw+7J0f9U
MXJ6w3/HL18odmAV+aAYi+FEFD7ECUxHPpJQiSF4QBcxEoZYvYbuiEUjAsiFERQts1UI1Cdk
51V9m2+CsRmL8AhzcQEZ+Bss2EJ9EYIBOIWhOhv+Zh36Yyk26H/AavTDR6jTV7QH8XgfdTSE
xqmFZgwmoAgLsJICKZwG0AKECYZCfIZa9nuuGi2QgFeQglRkY59BcqeJRFTSeRUnN6WilF6k
Wr0LNkEVhki8RP25hz6EzghHPwzGMPwJ67EJF6knDVV9jIMIFJ9cOEi+FEBd6LB+B0EiCZgk
SFeiDDtxEicpiFK4l0o3P/Hcgi9mCcJilOI8HpI3TaBCrlG7PcN0rt6rj8rpaLnHgVGCuxgb
xbty7EctvpCY1FEnSqSNdN8oMKMaF3nOeq7pAP0QrQTreORgJt5AieTmXRzBZfwbT8kgL2pN
R7g3X1a+xrtmoIZe1sQA9MJLEq1CLMNykYNy4iuyUTfqSwV0gX25Fc/g17mCv1clqkr9y/hO
x+kd+kuJ+W1YYRcJQ7JktViytlpytwufoho1OI47eICfJJK5VEpVVE1P+AXezeeNBrPOfKC3
6Qb4SLRDEYHeIn0lgiPxsmCZiS2Sqa9xWmrmGZ5RBxpIr9MyWkGraAOV0bf0My/lM3xVlalP
lFsdN8iIMnLNUvOaJcnq8pR5tujR4p2//HY/4U2MxDBTuDhHOPGOxHEPDuCwYHuCeomLv3gb
QoMpmQppAS2i1fRnusTxnMuzOF+R6qTsqqtabgQZFcZZ47JZZJZ6wjxpuieaeOMtbBgsuFNF
fo8suaVIpFTiUIm/SraOCWtvC5sfo15uY8mzD7WhYOpKTpHxkvVUmkwuyqFi+oAq6DLdZz9u
y114Na/nD/gb/k7NVuvUVrVXnVMeQ5s+ZpTIaDNN/K0wH1nGW0qsw61TrOVepxrDG483XvW0
8LTxdPWM87zp+YtO1fP0a3q7Lte7daWuba5UJdztJPyyiXRFT6mc0RiDyYJ/OmYLJ1dgDd4W
KRcf9mIfjgrjzuIbXMW3IjdxSzJ7t9mnx2gQn9qSnfoIX6JpEk2hLMqnomZZTJtoM20lNx2m
WjpB5+gi1dE1kZ/pCT3l59mfe3E0O3gkj+VkzuBMzuc3eBNv5Y/5AB/iryTLF/gi32CP6iiZ
cKp49Ts1WSIyXy1S29UB9Xd1XtWp6+qpxMaQHAUbdiPUGGRkG0uMa2Y3idNUM9d8T+SIxceS
a6m07LWctNyyWqzdrPHWROvH1j1WLZVSibVSpb/6hHE7qDu/KigVfcn7aB2d5j3GPfalNCpS
4EgjQjiegJtcokIpRhVSB6njt/AyK4mhL2/jkcLupi9Zqriv8DDFPGe0oXKAl1KO9Jszwp/R
YrMchxCq69Aab+vpqKZAqahMvVlqYSGNplqpoWyezXeMBuUnDL2uLglvbkrt96Myy0lM4h7C
tqF4DwEYKPm8ivlk456YiM1quWQ6GO0QbswwpYfTI7UHO7mMS3if/pqB76XvTTRGEoxr0vfD
EUR38algO8HnuISqDQttp7GCoaPyEn4cQwhvQ6aaSwYv5B+NOlzigTxRRdAjo4+S11DytARp
dJe8sIvK+CkFYwMtFO9v0F2+gQL8SJob1WrOoeN0jAK4Bw1XveHh6zRF0ITgvhlIXhwtdWQR
Xt3knSqLtuKceURdMRLUfhj0OUVzg7KxgxLUAH0PoZanqqXnvI6Dg7Vea/g0/iDRmY1L+qiK
NFzGqPrq+jMcSGtVnpmqH3mKzSUcgyzztnUo5nOcdIgz8hZVIpx+4PYS9yBZGSSRCjTW1Ndz
EjrxA3qMQlot1REinqRI56hENu0QW1PepmHyCjzjCumaCWqu9Jn9OCpsXyC93Z8z5J3JoWSw
vBJG83uwRdjw0JiG+fLvIRGfyWtaIVpn86PY2NhhMUOHDB40cED0i/36RvXp3atnZESP8O7d
uoaFhti7BNuCOnfq2KF9u7aBAW1e8H++tV8r35YtfLyf87JaTEMxIcJpH5Fuc4elu40we3x8
ZNPc7pIF168W0t02WRrxWxu3Lb3ZzPZby1ixzPo/y9hfLGP/Z0l+tiEYEhlhc9pt7tMOu62G
Jialiv6Ww55mc99r1hOa9TXNekvRg4PlgM3ZNsdhc1O6zekeMS9nhTPdIT9X5eMdZ4/L9I6M
QJW3j6g+orkD7flVFBhDzQoHOgdVMbxaCih3e7vD6W5ndzQhcKtQp2uqOzEp1enoEBycFhnh
prgM+xQ37MPdrXo0myCu+Rq3Jc5tbb7GNq3JG5TaqiJqV6ys8cOU/9BeNVBRHVf4vjfv7RJF
xfoP/izZAgoiolWRaF3UpSpJjAbIwiF2IWiNmGBiG6OthtZYe9ZfjKYaNTWpSXugaVb0xEUr
8SeCtlWrKfEcU217tCexFrUeY2NKmH539r11wbYxPafKt3fm3rl37szcuXeePy223F1eWuIL
itIinqN7GuadHOyz5FLfO10Y/8ok38poaYIIePs+6eJuILDSFdwxwxctTeTfoiLYgK6elOsP
5GLq1byJfTPgCLvPSwkvarbbyxz/PFfwPvdE99zAPD/OIz4QpJmLE+vi4z318k8U73UF8n3u
xOCEBHdR6eT+u3pSYObi3f08rn7tJelDd8V1D+/mrq7drEZsl+jG7IhMtdRwbuXNjGynxh65
pyIKgq4nXPDE58ZCsvhndhYFnsjCMPwr0qAVLMcxPBm8b5I/EJfNfNYPmklxblfgE8Kxu1v+
1p5TanEcSXGfEDc5OCLxBbndDqalBVNTOS6ck3CQ8PHrqj8qfehzIf2qe0GcCwTbR4/4oFaU
nYE9T0zkU10V8lAZOsGqGb5w30VlCXXkyUgrCup+lhy0Jb0KWFJlSyLqfjfCdw/xR0CvYExy
5K9bXO8e3rnZQa33fxHPDsvzHnXnzSj2ubwBv7W3efntemF5VkRmtYI9JvlEgm619AShpIjE
kshg7vhig0YS/hwqkstDzhiEouJortxgnH9K+LeoU2LiPSqF5HXWUuSOmuVmMDutff+Bdv12
7sUGBBw2kvW8/OJAoFM7WS7STiCQ63blBvyB0pCsKnO74tyBejzxgoEFXr99oiG5b1VCMHd1
ERYxV8tOV+UaX1eJbV56LKai1Wxti7mFbxdndD0X1Y6xWn9u6TZq6BVRoiXjw+cloNBRQ+sd
Y6lMe0frAtlqvUYmGqTdb86hBp3kFfBGQ8+rj5X7MX4JsBRwAZMBDzAV+D7wMfAw8AB0lgBf
hY2XgWNMwW90llCpcVFuA06bhRQwm+QRtM8AJ80mWov+rzH/QbFG7jML5XFjoWxw1MgDaDdB
vgTjToGyjdOw19VYSOvQP2dc1AjruA3+IvBC0GsVA6iLPpbOiQFypPBTlkHyml6jzYXecGC0
WMM8SgH16GPbtkJ+HP0h0PGhvwP8nmhPh303jwPGYcxA0HTYToXdFsjzmY+xQ7EeN/wOASWQ
NYmRtEYfSS1ipPyWkU89rXW/yuvmNdtrUv6HfboLsMu2PdEI+3cHd3z7QpyHT78HfRbIxFpa
9RP0lpFB8w1q2+voSasYzrM49xptCxBrlFM/5wC5ET5OMffQKPQZs4Bi6N8wtskz4iZ5IEtz
vEwbwJ+iZyLGRlGd/l265MDXLdabjvlMjhPs23oVC+Vq33TQgcZf5Htocz/JOUDrZO3TNt4b
5xpKh/5ozHUVfrQYC7UA8B34VgdUsz+YPwN77se579UK22phpzti79vAMKxraRjyImK4Grwc
jBsYQ/SCNc+ZKHqGYy8a1vnYOGdD7X0NXnA11Ajcgi/JwCFgKfQ+BM0A/2HQmYjFRowfyfGK
uLgejk35FscG4v134I9h39UaEN8cY+F7oy3R59BPgUrgRQfRaxZ+gDHqvnDMsp+W7RaOLY4Z
m1qxcVSvxbuZ18lxZVF19y5QivIBa+fYilDcO459RS/jTjPdRFM5ZtlmhDapfDCO7yPONjlC
LX/4fiJvnFf0MhVasT7OptZeHInQNfIdyJY6+tB2YyRiP4Q7kEK9xQ3koPPYw6doGt9jYxO9
oq+gns4rlIGznA5bWzrQzQxnszYP9g5iPxuNE7QFdLPRrN9vNGumWSsvGy3aQbNWX8btu2lH
2GOZMqJlX5b/v0D/wKzFG75W/tVsltJopg1YKzmvaMMBl03BrwOqgNSYNG1zTIUWchZQHOLm
JlBpeCjb9CDmDtIEo5fK30ngFzgI+69RnvEqLcR3axdRoCU7amm+KMAdxVz6B7ScwfZBF0Ti
KBxr2Ta9K5YsasdrB3qMcz7nXZuqu4e8alFfu342fY1rA+dnrg+coxnheJWvR+JyA2rIh3fi
s32cyttR8fkSbGZ2jMsoeoEp1xbO71xbMP8szL8dtt7g9av8iBzHOZLzHO78Q/b4jjSiX6Md
QH7Yq/LwCSq27zXA9/xjyB608gjyMO1R+bCSHncUUpEYQw+pfDSFZpmnyKVqkFVTjTr5M5XL
cJ/sWqrqaLNcF6mjA+SNcD6TR1W+OSTr+X6quon6ae7QepjHKUHllYX0K3UP+Q5+StmYq0D8
Ajm3VS4CL1OMR+4FX1ylYiU7S4PEIugZciPXRPEUJan6eFZWigk0QemukB7jU9TtN1ErLHtq
DKi5CTGJt4DDT4dULijmGKGudj7ms3dWyP3OWfKwo5wazUewnjL6M9ZyQu1BSDaqfWDdPjKd
98KZL9eLW7INY36rwDoVsl7tB/Yoei9UbeY3BWw6KmmT2g/WWU4fxfjkJYY5l55zfIZ5MJc5
HrVkomwwJ8pqlVsdqHGLsc5BqG2xNJ7j3vmMlGKQPGnXYdFASWKpfMNMkDuxd0MsfgrnfX6T
8HuD3xDmL7n2y5DSOY13WifyMIwUxGUFzRE7gZXUzdyJt0hIvqjeCs00WBiyRizF+yb8PuE3
QoG6L5XyTbOOUvmOKR8wB999nMcR5NJC5JIc5yr5c0OnEYi5Udjv6cBswGv1D1s4EoZ2KjxG
0yHP1/9BLWiXoP1NvUF8T2+gMfwOFO/LZvGCPKpXy2XiMTogTsrTen96V4+BH+/Jz8T7VKRd
o0ZRRYfEVLybFlCTOCYviSPygt6Zpunj5HaxiyrEcnlCPEvTxdOwt56Oih/L62KtXCc2IUY/
ocPiN3KFkUXvGp1h6wI1aj+krfrfaavjQYrDfDnKfhWtg/3eCssRJ9CLhvLVxt0+l+lJFGv5
W9zOX/bV9tP20fZvLWqZ5R+vm+0qPYwxptA0IvkHIClM22bgTIo5r6uc5UXuiUEuepzGQR5P
9PkNYA/a1Rh7C7iE9vNAAO0fAf8EXgeexribMDMKGIT+N4x4et7KM5UYnwbefAB6n59BfyDa
WWifAPoRtX4E+gwwAe3bAPitpoUCoBt0ME7yXJkW7xrGbwPOof0a6KNhXututLtYdB+wEVgG
DFfv1w7vkv8D/bf16F5phzqU2bGmfCnqvSfargbZ5/9F1KotJXdRax/sdUT5859qXjuK+Gmw
/lM9UvD+3V7vCE8ING2YonWDh4wIC+KTR1Tl9BD76SfA28ApADbwOwjQxX79bUqhQRhcX9c7
QWmF6iZOtBqjs8KN3anpI/6Y0wmPv2uALkKingaHtXYPHjbiek5nMDSY3Uvav1iv1uAmrit8
7660Kz8Wy8LG8gNdWfIu4AXL2pUtYyxrZVu2QTVgDB2Ll2l4JC5MgBhD00CEk9BJmKbpTJqS
RwtNpmUYm8brFSYCXKDT1zBTJp3+yLQzaUJTh3Y6dfoYYNwGRz33yhPaTKf9070659t7znfO
2Xv37u4VCA9PC+Ev8iNWMymKlfFp5OQt5AVZD3IA5BaIABeTRu+D/BkkC2JDLv6c9cFz5Cp/
Bu/Fr0KSl9GLDmwUkpQtZedSXIrnBq5wJsLZ67jMKt+jZbLX07sr9sBlHsdD1PAD/hlcRuvD
3I5bQd3IANQxSMO0MFSW5LBazmGVl6Hlz7HL9e9MwbSYILe48Une4KuXQaG/pZuViDbFP0Ub
anagSWLIW3VPBsa5dRcQPkrLdXoJdOl9GLzKj8CUnGR6AbUFNCf19W7RCimu7dV8FLt6tAU0
RaeeD2DkKV2aS27vZyRL02mMVau7KDUc0VxXIGEE6dk7Rqkc0d1ywxbNKSshTZBr9UKon8l+
YtTIK/TC5oCuvSKPypflG7LNLjeCV2vSypuXNTc18265DBJeWCo3ybYpfoQ2JDuQ4SRFhF48
+RLhCki9DqP6a5qwYR+nDREglZLwgDgucgPCuMD5zgM/73wACr9r5J8nPs3nVzfQIaWsZToD
H52UlOXxQrbfv+VRdc0Dk0EXVuri59ZpmrJcj+VnP+JTCP6UZWcBVcA/Qkiz7oXIdLRT81AM
NGsumqlOZ11YlCy/ottod/WaEEWYSAbVuhvAKFys+5R6TfMpehPUnzXyFSiep1RWayevQinM
p2hDCgysjoSJEBCiAn+GG+eucW9ztjP8OH+Nf5u37QfWCzxP+AAf5dfxA7y9KNbAzcDNHQB9
BuR9EB4FQEdB9rPeOKwhjNaBhoyIA+84eOlZlK5i5hn4jIc+H5i3eIubgWZCgyxGRRijemxg
DmOUhznkQGVl8CJwFTuMWAH3BOdHISThCNNhpiuNipD0Qkh6JiQ9EpKSIWljSOoOSctD0tKQ
FHNyDciLJK6Sanyf6R8xvZ7p5UaFV/qLV7rqlb7hlR73Sl/0Sl/wSgNeqcMrxSTcipuQhCJM
1zO9mGo8d6GopwjlXcNzqAdJ/ARMbSkiXKmlhEiGK7GUKIDD8lwhsXJOgM0aBq8dZAzENo88
IjZqxyhI3wL4Y+THnwd801JqSQZ/PwdjNGesFJ9DCo3C30MeLAN+F42x/hsoyPD1efy25d8H
Yd+iEMvDr8HuH4pAAZ0VOWwpdeDeZwUfI7FivBdqUvMjqIbR4rBEKEbnw/yW5zSZwtXIw9Eu
uqA8TuYgXrbIP/SMA1vk7zUZbswif1AyGHofgu9Vi0wHoWcUkN8Fp8kHwefIL5UMhy+SXyg3
yU05YwPiW0FGfFNhSc57wAj808Ht5JRymryYy32yhpGehskcMxaSp2BIw/5pcgDS7PI/Rrbn
Um3zsyvYdJv1+uB6ANbpzLhWoYkXkq7gw6RTGSPtwZuk1b+dNBOwXyQra6ZJ2M9q1flZeK0H
BgdXssw/RpYEx8im8BT+KRLxSRDVqBNT4kFxUNwjJkRDbBIbxRWiT6wWSxwuh9OxwFHoyHc4
HILD5oBtpqMkk71lwIYHoxLBSUGwUW1j506OalD0k8JhBwdbMnMhn+ASfW1mWE1kxOwGs0lN
mHnrt/RPYPy1JE6Y13eixENe816fP4Pzezebdn8bNl0JlNjY5gayyT2bwWhjfwZnacSJStPV
3g/fLGyceL6SYvLE88kkWnQ46o66WotXdnb8B7VjXqsPDrf674d7sfnNRF+/Obo4aWr0JLs4
mTC7+rxb+y9xx7gn4h2XuKMUkv2XcCd3LL6B2nFnR/JTGiyoo0CDRX00R0shD6XB6k4x2vYc
jUA00GQKlHYOEUYj+BylwTKjvIkxEu+YIIRxbAfQGOOM2Q7kODLj3P4Xjt2JbjPObbuTlStj
lJoaoARrKGXCVwOEiRofc/c+cPtz7mM59zHmfvSBW8+5R3PuUXCr/6djd9v/YsQH+9pwYn3/
hAO1Jdu35nCR80ArWwfFk5HjlZdxFf9rVKAmzXx/m1ngb0PRqFt1tuDANqHQFMAmglD6qmr3
k5WXbQimnNILwSzNu1bEVsSoC5YzdS0Ac9G8y/3kqmoocm7e5QRzMRSBdVzXB+tyb9ys3QHg
70gid3ywA37zMATH8PDw0NChYXpAgNKXMCO9m/snFCVulu/oSKpx92DHof8yfpQwayEoSoNE
MW4aEDQ0pLI4VR3OnUBuevrZ41DOxqhIHfrUjmneIZpFxTClmex7aU8V++pOqrpbUfVL8H9r
ZMKlU3ISDx2i0ZArl2GIZYXnm/6zggZfSxFFL3B4VhAz3B5jIbLbZnmUL9pmMSp3CPZZ2Hfi
Nem8N96Fu3KvZa5lrfNOS89cC4rCufM+qGB9dXF1sQwKXiXovpe/ft+wo4+R13Ydsj+U/a39
N/a9KAA76G70q/RmFeMMHjd8di6C0cXlgQiqr4ostRX5OmvFALdccMFroSi8zsfDpusV+IoV
YsNw57UWtbeWlhblrTm+KhJaU1ZWgVcVnjUKMngkLZ711mbwwcmlvfWus53wcE1Geqvk9tAU
XgO7fQeq4ket5u3wHXAYBcZatwEJ3OWrD1/CDcitwmjUnpk7M3fm7s0479750Hm3/F7FnBtk
em18d8dtFcbZ45xxzk07p6MzrpWBFlfZymIQ5wx23kVMB+vxNlxdKgiiIC7StbAuCH6fsoTp
hlC4UVYAGnVtUWmJILrKGhtCyhK5MUzR7xNKSxaJAtW61hhWOFsDfqn/0cTO2JGTm+IrWr6y
dcdX4/tvfHnyJ6d24nq7/Z1Te46cf6978DVFz6KXG1Z3NnXvyn/ph6Ovj3Qd3Gkc4X6mFHbv
+/qmG6s3rO7a2Nc9dSr9bP/DSnvVz/90cNPeH3d/8s6NK/9ku0yAmzivOP6979t7daxkSSvJ
ti5fgsVH8YVjNxaGUA4TKEMgOIiWFGIgkODgYwZqAibE5a5pSDI0TcIVGtwpCcbgi6Ot29J2
kg6dNO1MZ5pQDKElGnoYOoFI7ls5bqfTytKutLJ23/7ee//3/zZ6Q+y96dWLVsbmbu2KPHZm
9tWNW08Ys1ZBnSn9e1Nz2W5+P9FIzXlRAsiQHU6Tsp28hXl7pIdXquU+WNJrn8H7HHX9VBuH
OD+BhJIJ7Sa2b5qHmF+QX65VOkFHLNTtgu2RtrLoofNw2NvfcnAg1aBd/+G3dkPdGEyDaM6u
Ux8kv39vCFcY4dRcGkxff8Z5Ga/vkDMc/+f6McU+w84Hecr7Mbxb7y40o7gX/58wKj26x62J
FAoQuLO8DCZH2konHepLNabD4Ldk/AnDSF1IpX6e+n1w99sf0GUYBsZxOzUGGjlLXKQ4ZiEu
151aGzxvA5tjAJoJR3vPk4dVn3vD3fG7/3QkQYrjTQntF18qEdOpLcg3Afw77e55xbkCV8LE
6uik2r07r0XKonlOu1QiOzzGw3VTl52biuwrYDNdDWPYNVk9ZAeFPuY4x1Mft2G/eZWR+doI
KU7ibYnhSrp6UvL+JBjbuRN/98jYnzHWHqKSQD92dNcZQcWmbe6VfZaJANEe4y8r08Gky7Li
lFFdM3lydXVPtbnFF059snnsFvsHv4Y4SS7ZG3u03FMdmi3MFecEFgTrQ4v1htAqzyr9mcAz
wadDrfZNnmZ9a3BLqMOzU98XOuTp0l8PHXMf9xzRuwOnQ/30rPuM56x+IXAplJvxGeGz+qAx
5lesvu5tVrD68iLd29Dif8TusDHGM3/+AGSDh0zkEYOOm1EnahPpRJqRU2ywL5rKWVmhRwQq
0nTjVFZkOB1l+XR42+mO1hWNNQs6Tj/e+ObaHQ+1Pf/QvIbYl41Ni3Y28Gs+/ORnqVWvtJUH
Prx14xOw7V1e9kTq4+up311d0xhdDzx0g/rsWuTZjhCXIoVM8suYX/TDEtpIW2kzu2Dl0UVp
Ouh2TrJjGU7rkUQQpqvowUXih2NoomwkSnz42Q9JFFPNDoxIUc1uv4mmCxcRvgEYJX5mjcmZ
mYSXRAuBQRbFavdTtSdoB3sfK4ipGmThMdAhSxmgUbiOVHAkGkaNoV0G4158pOauKcC1Ndpo
otNWZLRrw4YpSl6i3U0Yn8O4MF0e35r44qQJwBQZHWunIv2XMaFAYkEeW5q6mFW6QkkmbYv8
k93hyC03Zflhf6UVvsqvefDGN6bkFYh5eVR1BoraWN4c1ZWRE7XkrkBWIWR1GVllkyOx8AHp
RfU16WXlB1K35ZI0YHlfet+r3GF/4W577uicasm+gIx8yKeNZMG0mDub6V7Ow2MSM5hTYDrn
4UDtozRmkbvtvM97EzvRYrlEdRxY/yQBIqDxz6b0jNMfHIB7cGe8WuaPJLR7I8hDS9bUJkeQ
A5gw8FmU+JRoSTC7ksQhHg6Xk4yJm64Yb02zpCCM0ltKf5KMU+6t+due2vdETunwc9vfCZZs
H071w+JF6/RoHgwDtO1Ys6NT237g3a2Pz2vp+mPqo5lVpmbOxK45ggyKyHv9xDV2OTbLkVUb
L9xQ2JzfXri/8HDhCeVt7+nCQToo9ir93kuFthXka0BXu1pclKey3TKJCczDcl3fKzxVeLHw
rlvkXC4XdQ2w/Xj60R4AW2SAYWXhMinTqg7BK0ShuBjFjzbeMFdDOrMSHsLnYg4odoDjErxO
SoiCpaYyOwGq9xQHITjE4jiGr7DlxBzl8dFRxIaaNWpqwyhON3O8JUbiJqumJmiKG1D+nxqp
mFAyj7nFLvxC3fQAxcGF/5QPVX9vW7LqKxuX5pUdW9l6cNfJNeu+/WD31ulGaZ7fr7XPymto
WXCK3sjOe7p+7YLGPWpz2771y0/NMI40tT/YNSUQzZkq8bP0q61ffzmOShRDpjf4eqLg6vbR
mGFTYYsKdipZSkkFV6luUjr5TuFX7A9MkVXZslppUbjFCjylAG86It1XJuA+VoNvwELR1EiM
8KLEVMFqoapAeP6moOJ9qIos37eoLossWVRJVlSLVeQYBdVukwfhVQzEQo/1MkniCRbmGzFF
iSqEE6K8lQ3Sk/g1pbSHyIrSB/fPqTIhMs/3sWivjKeW5QGkL1HotVitFlUdZJOIjOdTY6pg
i6qaoAs25Uo/3P6v9h41Nn8M3mLMBZqOtBE2Nv8NDxjpd5r5He7+ijssecOUAUNLEIdpTZI1
N9KV3ykVGTxqQmeR15QGOz5QBAzjuaamOOYWoFTMYTkZ4UpgEGY3UsmjucfXfmddyjOZFR9M
9kMXX//5C99MvQTr97L1qVTyRazxOZiP32I+IuRHsWeFiLOKw1dYNEIlYk1oIb9IWCiu5J8U
nhSbuCZhk9jBdQgviF1cl/Amd0zo5fpDnq0cSFnerJniUeGuwIe9HhZwAs2VvJnhiJtx3P0I
cUUiJMIxwgWcHItEbJShbHKZfbD+vM3q9OUEuqUhKuNsupKeFNo9HBNIYX7CNKNIwDne+aYk
mvdvUkkfqkpbNlMIm0gcfXNYDIumMXAJ6YEyUcp46ItaLqAa/LQotXbe0YY9jYcea25dXR0t
yy+fHvW7s5surn6tg68/cdI/r+U3e669OqVmSqAot7Q8rMrXzra/M9uGVbF97BZXhorgQl4/
7pWcXif1mvVYr1cFInpVxF3BSt11rM69LmtzVoe6zXcgeFB9yXc4cJydth7xdAfOsh6x1zOU
Nez2SJm625vJZnLLHGjbObfu9nMhRonQB9/tCYUsaIsazxHe/5nFmt0H4ZhaLNfK1C4HZSqb
Wir/GgD8uXq3fYgSkoNTtmaCHQ7a0Xh8fMoivqQDQaWJlZYSUzRRBBAXSqdbIOK4AJD0/HWS
yop/8V010E2VZ/j77k/a/DXJzb3N702be2+aNEmTSEPTtIFcKMUJlDIHaK2ZsPFTV2jBQlGK
gnOFrkxRNwZYkJ8yUMoBJLSkpRacU890Kjtz44xztuHsURArOnvYGCbdd28KVD1n557k++57
2nty3+95nvd5YHb2UlkbS4R7MkOPrZixMZn5w8kDh4dg9fGGDL5txcyWt9bcy8fJBrcnM/b7
QGr3tcyxa3vehdugY4YnvT/z/vuNbbD2b62bTJKSXkZ9C8msP9gPiLFzyanzwojQ8kpIKz9F
vhe1aBPFKpB6qkiCSME9ogbHaBzHCFyFAZX83qRCQg9SxgE0YZWwoa9ABVUWNTEIbwIcLwIk
3nYKFmAQG0Q01WBUti+jiRiSxKz9QNiSkDVMIfzcRpU8TmBCzmJOBrqhk1Pk8PBprDudOw/b
lRlqXywWk3O4/w65iH3BeuTm5iLuXEFoMCHkhsAb/cCFoPCwPppjaNS0m9othIWs0Ebd92hn
uefDJXAVuVZoCz0F281PCe3eTv9edZf2BXtX0Xbvi6Ej+h57t/Cy63joBBzUDGoH9GftV/2F
LrMGvalOXnyOGxTpu6HQOnuATq/DdAPo2D3wgKjOYsJyV6AHH4D/AjZU08aZRcwm5hJDMNZJ
SItuG7D09WwP0tfH8WEYH6vSuyMSwfw7VjIyMeCU3c41pjvBBpWw5KK6//R1v3v4cl38rR3P
9v3y7RXrWhJ1TayX3b5rS9Mju+uxfzf01Xd/9ebPVl9cuvKZme3nDjU3ndK7Xlq5bO2quqro
/OGpV7esbN/XPL8fMawS9XRE7qkLvNYPnKijNaaoDZGL4KomVxBD6rcteI7DbM534JXkbHJZ
wQZza0Gn7afcHnOX7VfcUfKo+oihx9xjP8SdIXsLqAWSPVOYrWZWwZMEQO6u6zTPA/aGjpQY
JlJAa+1ppi5RGGV162ABxAoR25KXNFCD0NbbjEhmQR5213gLRyVqjSSyvfy/BJOQZJImbVlk
PDICuZUYQM4ky64s08oql8/ZcmH+lBneHftg5PjeI4OZoVcehumnG+9ufb15fpFoLsz3zrr4
rIN67+fX4MJr+97JrMn8s7oYq4OOD1c+mun76NE2U9blj2AWvBPlBROI9AMFSgwgR5NCCyUH
h5PKFh1aEGCYAgZjLOameeOvhFBxy5JPiBL4hD1MemMoV8RiR7wVlcUoWeCdlV65VJn2V3qL
K6UiwMZ2A0AsIhuRPrrgc+KTOAPyCTPuzOVUvELI0fAwyMf5Wv4hvpl/gn+Gf4E/w39SeL1Q
TTpJnhRCzlIuJFSz1dwCbiW7hFsmtNJruZe4D5g/Oy/wfxGMRVyIDjF3sUQx8NuC9iBLuEVL
RbhINFaEjS6eogWeRz6XK1RRalbFOp0pzCbO4pwOllXCXFZpZ2ysnWcY3snRTifHUzxDObIW
XnDRLt5oVHIAZ+12lUqZi3MGDuMA72RogaCKQgxkJK1SV4SZFD79NP8EJ1psYW68xqXwqb1A
qoDxCkjB6aIWivqKsA4GYS0ayyl8bm/RVp4DhQP4A3i97BBGE75Rn++6zzf6sS8hURGJUkKy
veiKS+NvBG0klcqVZn8eGv4E2pgnZgH0nfvZ7bucPH0sh9THYjmxmGwQEBiBFBVWQ1zmb34p
igtSvEJXxJlls5wgymTrQBQsz9UZp9Wo05+qTdOKWb1apc9s6AyawzF1plk9a/Uq3NudWQcX
kI03d9ZaPAxrd7nsRn9By9Ez8Yi5MIC5XHhiJzE3k0xfAfjYHxEm+pH6O4EfRGCX2JqDAgFG
+UNxVzxUG6oP/6S0rXRV9Beh7ao9nr2hg6pjxT2hJNGrGnSdDRkX+n9HYFykpMRvtNKsEdoA
C/0lJQ6rjbZabcrJQjBg9AZgJMChYR0IctvQmXFGiBlzuYi/xFrusVn1SqW7ZFIK35iMI1oP
wOnAjW/sVYgGSrKT55J6M1qhqTfqf7XkI1sKrxbzKKt0kies56znrbgV/VGvYXLICq0p2NJX
rrSarOWqAdgCmVseT6KRL+GrevD+fmBFj7Qb4tJ/JYtM0rop6THL930l6F40RKUp46uDNcPp
YSQlPl/NldHVVyyS25OehuyiZG6AOR5HlUR6RC9f0rAi5VT4jcPP0cvHnJh9wvOD2SfWfv+B
+0+GLa7U2Cfl5XVg9gkfKk5FxV7Bw3s4TzmqwgT6naImxDHRSZwz6kYf+eckYMQ5KX9CHEAu
6k6ulCXLOC77KDvACdtgHhxef/ahl8+2rWnobrn3WEannWv3GMyerwoiNYbBaez5dzZ0COWZ
Ayum7P5y+6HCAOl2zemYs/bVksDO+qWpZWaDC9Ma7EUd+OQGr8uXfg/r7VjeorlZnze4v60T
lzxE59iH5H6kLG6wTRQEfZW6Sv+gYrl6japVvc6xWf9r/WHQB05ptIeoNylMoYNYCtaIylzh
+dxSdyHOpDDjacMSsxJILMYdJ7EOJP/TT7o7JLaeoqNgNA8BRKTs4t2zw3aRju61Q/tSz9LH
sxIpHVHahxzEMKJmejgeG/lMPyxHKtQ1nHcHcNQG1K+sokdKFQTPCZKjEiQDKpXI/UsFghS+
11SV3NyzeN7Hqa1/TQSbMqNnDo2BzZ/DvX/6cVuZ2Sx4ycbMPU2xH1a7f/T48OBrb1zd8OTx
32z9+rm/w4NfBGk6iDT2dQDIbsQnKygB/+gH9rHLYqkBIec+22Pu9b6t7l6HQkvnsVqEThba
7HYHzaDcyfABrT8AMW0uHfAwtL54AN8IFFmIKgagCQSR/1Iao6uCMGj7wD6AQ8Dg1acoHQ1p
CfUBJW2iA99B/WoZ8jSCOHoOPQ51aRXVCOu0aI7S38Z7AoldzZUs0JETQ8i+5cG+gWvZjSFE
FhIUQ+dhxLegSEJZtlBvhUhZdp5Cvwa+Ao1Q+WJ9y+eZT8+nf6uttXmMrPCFPTwH1mQuOhnK
WrEHaheuf/7ShckIg09kvuxqv7mj7z4XpjGw3o14eHHE7S36WvmITe8gldPEBJx5/n+El31s
E+cdx++5S2I/tuOzz+eXe3nubJ/vfI7fcolDcJYmFyiFtgTaQbd1WjRRIkDqJmDSUmDqSJUN
1kUdEtOG2P5o/6BDaTVphISAViqksU2aNFZVm/ZfxyTWMkEG2pimiiTs95ydEF66+Y/nd++2
7/t5ft/vc+NvwN+9D+Gt8/DWe9GU+zNXmpHY70o/kt6WuKPqkfyP1RPl08rp8i9bZoVZda4c
2K2OqUcYrpUX+aclrttVIL/E61I2Fh+QFcTzDOIjEcZXCoe/6ic+kgODqtR6e9+vkkrbJpbd
0UralO8kk7dlorSUUMkskhITiWhgUrmc2VspsZUwz8dLbLJC/Lm1tpmLtE35XEMYrPqQT51S
3GSqpgDZc2RjTTleOV6m6Tohq7U3y7fKbFmus+/ApH2Hn2JORqjUpid1DuXodUExWcuBauN0
32t4uWSu0fD6Hmh4xYb6uUbDy51vUJBrUkArbXg5gGAVAHc+vvMxzU/F4TsLxeK16kjx2jIL
87Tf9T8KxEhl/iYT+Td6oHhnGpue2x1dCfHFpuXBzPQmI2d4qz/DaNhfd+PggzgZvRnvsryV
twz2xE8Pf+9QyZy0BeOJl16biEnRJw/86saIOX73evsWxRYU8x9qz3A8xF3Zbvrk7FDnz1u5
xevb9i2JA6ViTVoaHMrKYvj77y4dBbAEtTDBde2sWUVz6UJF78lVUgIl6goQ9SIQVUWbZuNZ
Pjrg0Jc/AXmmNRwPn7BOWxdbZqNzlg+FwwwCvYGX9nbKS4IkSSK/p1rdYZP8Mi9xXiTxFhOZ
Wo6YDM9rRBMJ0aoVk620h8Nxk03E/aTT1giwwvhcH/sH3198rC9/nLE6Ldd6ztpntVqyw/yR
p0RoYIMhgSc6qRJunCBCSejE8M2dAdg8s7AKhAYGpCE/acpPlpsAAf3JI6a3fxik378iff9n
Sc+s0vlR5Y+C8q9eBgtsrN0eELyhdyPZ3FfaWlbaE/onb00feGXQesPmn987M5bufTm0CArL
dkwxbxG5e3OoRR21gk/X7cnWlsVPnjm4JPTnn1i/tPvrOdP2mV7XKIxzzs61simYS1MD9rrh
SAC0/R3DtL0K2g5B/gwJqSwfGyjQgT9/76OzUAehuj+ADTEr1s+Zn3SxRwKz4jmZ2zY4Fhgr
cNv5fetZlEmnWSY7NGRgWOJGIdFKaZlIHU6RdOA+1Df0OdKHWYi1KSFJUgXDJoV611oCAVLQ
0qwINw8ZhuZ0iY7ThZhsxqiCjzKpvnod4i3bUShIUsrvpNfZbLrLiQhDIZCdZWNMGr3OGLDd
xW1gBMaBLtK9pua4Zg8F9GyxUvOqXfCqGzd6HBqWxp1fOJecD5yrzm2nzQFE3MA6nE46ybSz
ziNmr0cMINNsHvQD4Mw6bsIc9B6FoYs4ribQPY8lp8lS4yyvDTrjvOQdnQOwnPFU3fspQe+O
S+eE2ICzDFrzQ3mbv3NtvkjjNJB2aSVZ09GLV814HV6O1+HHxOuHxpHHHPI1e9BliiJ80PIf
vMDw9z6ajtSp5lCCUM7EGokrs4Kkz6LxwfcwsZnPQrh5PfqU/cZOVaptDrDZ0IZsZzKTvaX1
jAYXb4eBYkG2Di1OfovURv2LN9u3AtaydZtIPcMhNhlcn64mtBx7C219aQ2l10R8PFMdW/j9
rpKV99gW1PwEenNpx2hl5UDhNa57tNa8XMyUDgHrlxiG2wSsa+iHMyjL1xOUbRfYZnQ+zb6Q
PBk7q3DjacRijrBYQEIqRgQkQTiJBiIkmpIkDQdEjANClGWRH+t2AEdS7wGIEkAYYGMQ1Hms
4yo+jI/hVgyqY1B7uthDy1x3D3atfI1uu0m7Zxxfwh/gq/g2XAksYBcaK6a9S8c4iXXPxWKr
XAy8whOK9jA3jl0hOIhdMQRDoh2GZHgQL6OJKZp072w6RquHKG4i6h0HQr2flq83boobg5gS
i5uUNuuAVw1vf9zFgDJ2bdE7e0Z8AN9VFC+u6pUrwD6G05H78Wlkf7FoPp6dJmoJ9Glw8cPw
dqUUzxg3NZmiEQq6erlq3khLvabX4rTqQa5rV03OxTzVnzm8cGW/Lhkx0P59WNtVQXsbYbcb
x1I2K7yQOGZN5iftU8wcc07x5W3kZ0lD9Chu6u3Hot+PjbR9HrW5mXQFgfTIb+cNpqXDX7Cx
P8JMMXbETtucfblDuggcYK8Z+UHIAvYn/QWvpVy+r6M30fwNTfxef0rR6iUQ/3gjgXjNoOE9
zXWWkKxDBO2PzM9H6//jnXqxgq6aZiEXiQPS+XvXp6P1eLOZU+CnoTa+YiTz0JopD288uzy5
vfjhnQWbenchFn5O6RB145bWuzkaCLEF/8gWWSjcUJRo/8Sx7QM1daMMGgQFUjnA1Xd1Wh3I
NHMF5Y2FP30ll0rwOWWN9kqZpomLDOMbBSUcdOWsxCJE+XsbOP4C+rLGCll/D9moPEW+pH6R
7GZmMn8m/yGBvPobwu4iR8g5wlkElbOR6ADTCYNGt5xyJ3E43EK4mCySmFXKE0sIRIlg6jRg
IOQFDMQSmL0BTVZEWVbgew1VEVVVKZdKhq6Juq4JsZhqmSYhqt9hOJZlWKIiTtblLluRNT0C
Qp6akWGqynQmrT9dk6l6KVLz9rU+b39a7JG9aBqO1tLyYfktmZMvspNMN/z1YaYEZhPU3Ui0
pruh9prefIDefCCtbhSepH+7S07qSVnvCvSvuFFk0Zti89dWTOm+WaAo5WOVYURWm0ULmEXr
atc46m8e+T/2sTJDG0mVguXyagrUIlkYGDpQlhhYAI3AgiYTb1uesZQfmNGUIQAMGdyKQXhY
IcvK97Kvv8rF0LNfi2V603cTivX5FF78dUDZbOtO6erC3+3D/9TX7AkuDQWVnaW0gfKZ/ucD
rZvvvtfypOnztW/Zu3Dq2WJeJKaZiLx4khPunmnZunDhZdOkJtCVO8D9K5vymZS53977a1sK
mCugbe43fbGkYItrhD7rKWaDsDG+hz3InkoFt8fGUjMpbgKhoBAiQW+pUzAhqgRYTAJqQiEq
Zem/lJd9bBP3Gcd/vzu/nO/8cm85xxef7TvnEucc24ntACYmuRbKS8jaQDoKtGalDYXyovAi
KBQCaXlpaFXY1rFuENY3wbqNLoMk1Ly0rF01rRPT1qr/sEkTaExVpUXdNMamjZj9fmcHQqRV
mizlubucc8p9n+f7fL44o0JCrMIdJPCiAIHA67W1UQmbVFUDw9A0bhxKFFySYMR4oUpiYUoo
km2mKJrTgyhqpgPtprhR7BdfF21ikUwMu8D3cX4xGQnfIOEbJNxLAl5RPx9uSGStqtRa1QzI
Le3SQ9Ie6bA0JNml3YZL8Et+QTImWQ2mlzt9Aseux29i6ixdn4wX7ZVeudMn1P/ZHs1NoIDM
G8JJBlJZ91E4BQjKgi+Eb/0pmJ3n9jBwxD1HTfkjaumD2tKsv9U0P0aXliCTaRCVWuipX7aC
QUpfIeUnpunYSqydv/U/b9q23xp+PDOx5pXG3eRQPkHqgLj9W+Tw/0IaB5HHZ82Ag5CIeeqA
/h31mH7CeTJy1jmq0g4aGvgNfgNlF6q6QW1V59ofie3U3yJ+op71nFff1xlJY3Oc5mPblBhN
K7EYw0toIQB/UAEcg7ZCjGFCkh9p7acpJVyXBFQmHOYAwXMUrUSlhphfYqPnyT3ABv3DRuwz
BmcUPyGM8P0SlIrWWpD8UnktPDcpm1h7QSrvBamyF6QKQEoomeBro3xOusONdxLK176YWBK5
XCWgoHzC5fjclIwy+afTi5rE6c1bw12Ig00FqKZREztsSMc72qUry6FekFBgKavshCYhffq7
faVbr6741vq6aU/R439m1nY3XY3lVv5y0wMbhlft2j1npb1z9PnVH+7QSof2GRHDoesLTpC2
l1LRpH38HWX5yMpV2ziAVPsEqfYmUq0O7YMXzT5KctXnjfmg0+iILwdrwU7wTHhH4ruOo4kf
G+f8l4xLSe6kY8RJOIJS8GCCJOubm21uwaO4GRutMLIYUOQ6TVfqmm22kCCKgiCqmhYCUEQu
oMKGVFJuSEIIZKLO7WYYQGkqBLZGIR0TBbYRqxbCLz6RDWEBgqFyFapRhf6zGzMw0/yZDQsq
EsKogBFMqNCVYAESkkwwfYE2oYJPQkU/4b7qnGCBfw5BonWInyJUnmL9Cj2lX4AC7pA0Gmgh
PRUcCpNBq6J94SY6vqv/3SVQ6QE+d09i+MqZfgEn1MpII5yvL7v4FKR3Ti93iVNAE+CEuCvK
TUF2X+ns2upXpCdc439nOuQGIRIdq1441w3P//Gjj4f2NT2+jhlfaqZP/aqvL9JIvALZ0lNd
041qntJ1EqXT1DNkZnEiaUL97YN7ryilLd9e6tCJP7guHerdRiH1gPf2NdsS+zrQCr9u7t/f
+FyKWOFZ4V3hW+vp9fb6etk+zx7vHt9Otj/Rnxz0HPcO+tgYMDzZxMOJ1WpPYhe107s5eZA6
YBxIHHMf9R5lj2TeBu+4h7xDvlPsieSPUufg++6L3kvscPJs6kYyJCUXMV3ubs+jiYdTDofo
Fzvc870d7L6kw5fwJG3OmFIkQyYd66mKfqmqVSRxASYBADl0kXNmslngYuM8fSrS1NRENKFb
R6MDWmRAK8L7R8PqVZVQyw6PyzBKpbiaNVp9NqW2q/0qqcqz4qd4M9nCXyYGYOsAxF98DVwF
BMBhAt0ITH8LOA+ngTycdrqvupIREDiyYzfimB5xw1TOC7gVcG+M/YUdwwUdcKhdsNybYQFs
gpv8QgZPvSVofR3+tGSnZdKoA9AHXUUYGC1rjW8DuAkcUQ3dhsT3btScQy/vHQinLj8ZTH52
ckY6vHimw8spRrBujWZ7fe+a57thfOmGyzvyazbXy61qGP5zQdPBU288PWdG9yc9zYuWHfo1
49D8BBlqLrXl9R1Hn+2au6d07Y1HV3+wVor7upD+hwGwp5FTqDBuRkk8ex5k1aMeaFEfzyDg
s5MDRGRAJVjogPACSQEaqJjFuJzKgiawEb87kjLZGpZGLl4mQVeQrinCQVMEhPoeBAQt8JSs
xWpY5lPeAjwkpVXjyXKNNpRrKJItk161nN0jvyYPIdIrEqF3NZfslzV69TmyYyK9laWIxzGX
yzizWaToz8mVdIXru7zQJuPNX/H2sXglQ8Xb87fy7Hg+n59w8/iz7F8LsDoVx0dX0cGM+EcQ
STqem0JteOWrlmpIpSi05L0LZRAp6XBGYaPN0VsnJLSX15VuZMxFSff4GUZ+0FBSBgws2np4
aVC3d5a+91DbAj14a/nPGuqadT3ALfsm+Yv85qeRLr9HbLUX6ZKG6XMgXA4adhQ0zA3o4Eh0
xD3quSDZuu2Lw1s8+6M2Kkmlcnxrvc0VjNcT0IEiV00kqNSARFoBloE7XK6QkRANIxHRtCgv
ijwv1sgysm3C26O7fCxXG7XzBp+JJQyR1QZ4E9kubxl1oA1X08PlmniT7+JJlof8RfJBFMog
MNA7D7QYlnaxrFXjCauafPPMbMSAxvaMy/DzfvS36SLZfrr3LkqVFYRokgoWeN/D3WNTOGoC
s/+n1VqZt2DJ4/QSiJed5dFrIyrr1kpiCKS9BBqxluyE+9ZDNzGLWbqwRXlJd7pHXn1ysPex
6PbErAIDh5jO2enwK/N2f3n68r8ZKnwgmNti79QJpaOnFOmPmdN3/HDhC59vgz84llJTdhRz
Fq4vuf7xxfHPj7TOblwPf9OT0hscyGchuH3N/rE1ZwtME7gATXOUSNU4VEcVZ7IEP4ObVdUa
yEVy6ny2k+vjdgmHuMNVx8XBqveqvKvCPRFikPspd5EjEbFH8UuOaFlczygt1qlcY50OJ2da
1Ww0Wlw+WnHJkRpFpqBToQJctRLwsay1t1kOQI5lo2pEVNVI8fY2k2eBGpEDAZeLIlTgSnGQ
KxIvnmF3q+fJNvQP3D8KcEdgmzRZBHo+EEDD3w9sIKC5iuSi0x9WT+xTtEVv3rheABMkHEdR
6V4U/ioJrUmtxCKr9c+g11K0CuaG02KunI1gwV4G5CiS1YHxmIRooVZ0thIThNM3UrPn19KE
n3nkPoFmughuieT7L9/VGtzEdYX37q610korr7Raray1JOu1u7ZsS7YlGdmytfiR8RMDxhAw
LpQQAi6QmLyGkqQwCeMBMqSFuCE0g0NL03YoCbEDFU1JIDg/+NVMJ9MMaaa0M+6MSUdDpyGZ
tonlnivJadMf1Wj33H1pr+53vu98pz5jQafYBk/znicWaR+9a723Lg1eOFDtfOirj8jfPV7v
k2SNDofpcvf42S//DvoWW1qgrlNHwE8l0C3dZaoy+hPoOfRczRQ6JZ+sOVX/y6bLEXMM81Oy
ODLnnOcayGRNXxVpCVQkLNaAFrfiaykYZKQhaYtEtcWQRYdDi16RuOK8pSwoFCJpmoD6H1YU
0cI51WijEnbSDWJtk0fJUlO6QKihQIBgNIKmfaLiEEUlml36ZNZrz0SzVL3Oud28WUxqishz
Ry1XUSdBkxQhgh+kfqVcEHW4T8ToWYPhOCHyYkykvi8iOHVwZjghXiWniFrqEGEnPDiN4nEP
vldS1Ljn4HBi2nPXQ3oak6IkJtnGG0UFLrmnAk74odVaBj80C3JbiK7SsRgsxvLSeZiIpygs
hfimlFr2XxsH79yLjE1EIvdAd7/IFQ1YocBGlmUgAjmIK+08sqWg+tpS8CVggPibk/i6EQSD
n5vDWkBAHu3D+TRG9F+sGe6/2LJm0/3vEomlD4k4bNrSAqEuLayAD6RTBI0hiimYMyzkzVKh
DoNINEMqFUb2ZijcTqmZCTAGsiAshWyjrt9wUqzRwonqykD3ifZIxCk+u3dooHf83ZOP7mhb
I4be13t2THfV7jl4voM6srhplDPxFhPvGXXt3BOpbljdf76rYf/4NPr2+Dq9b19leiQ/M9k1
dPb3fx4ZAOyIJM69suOERIRQmc6PysjIIsa0hthQ9nYlrZTMLo469LBxWxlCwZDLRUjd1k81
Z0wadHHI70ZWgtAIOOvycVYHx1n9IW/Kr9IMN+8Omc1cWLNyvDdLHdLLGcD7Bea3DOljELPN
9RtIIgmFCA5eVBOLc1h0tEQhKIWAX88Vaja8/hr3Afc3juKyqPVSmJO4MJslfW+WEma5Ys/n
FkGm7yzDm8tlivgai/hCx4URtac+z0W+Qp9P4p4Ke2g0gaEESKkkRkJ0kLirQsVCHGASFDZU
9qKZYsih97e+sGrv89n8p5MvTaNYkJfqxEj19oH7rx4bbR+bUcqOLw5u7zvx9Nn89ZkJWtov
ujk7o/zrH82HUOMrm3dOHYYqnIa13w281xCn3wfO0JrR8K6eqEURtV5rJ9pRS1m72q49Tx7z
H1HPk+dCl3yzId4HvZCbrihzqz7NcFhB31WPqq/5KWcZwoVxxlaolzPOQgA+Jqa1NzRSA4S4
ClsW0W95QiwTBsWYlfkMxE/0gDcVVikzcdPxSIXKAUBRLsMNcVs4upzzcSTnrglg7LwGuJQx
DBm2GB420AcNrxouGq4ZPjCUGSqqI+sLZhbYNXhnFZ/HMZebh9WPRAABBAue4m+OFQV4AjPG
D4ypB8a8DSK8AC3cAuYJWFrAMFwihz1UwKFEkHayiMRy3U02U/LOD584Pn0e+Y/t2a1UVvuq
y6Os4Elsu9a19rHtgy996+OnH3918mWkXRntaK8NaF6hqs5hFq2Oo987fXrHk4MPQv4DRel1
kP9R6FHe088wXuQIVJRnzCCcLGxmPZmOs3hndsUTcbPe2ASHjYm4zLrNu9hd5tvsH82GjDgk
bhFHmuj/PBZoiScTvd7e1pH6ycQP0Y8cp8XXiMsoy17yvBWfTVjXEUhB6LMEsrjgVhbfX3io
TQ8n2vRgCAaVCYdDDIYURdjNItYczStZ9JmuaPWx6GDQ0ZSKKXJLMuigBMw9iohSPkFxCILS
FKpiUtmlj2e8qRRWbrPLZTULaU0ReLDS1KzyhmDGmcEmYZ6NZ+Lmoyz2skmYeeeZOHSwnTpL
zUenCIEXSKEo4MKvQcCTkANWGXJAhknKuicUl4t0xUG3garflZFckRYkIc02/uybrATpnZhf
/AL7sAh/7xvim8n9Nz1xqtix+GKWlkgKqVPgqbFA1KKaT0ARBw2O7EP7lgUeynbRMP9fiRUK
dbxEakxnovAIQa/L/7zSZuLsgdWBnpN6oNar/uDJtf0DE++8cuCh5Cplm5mxlIt+KSH3pZ7J
3+2o3wn0PP7l9q1e1s65torbn4rVprY+9af1rZOPTaG14yO1TWhz2Km5RauNCS8+qq/Kb32n
fwi9h3VXB+5PAPfdRJjI68ly3hx28a4wTRh5I2kfNq4xkZqpJrzC1OrtYXqNvaYedtS4gR8J
n6R/TP9UmKEvh3kVL3ubkjAFKm0ZYwC6K6PJaCqTCaNJrCKOyrqRbedkjxyVKVk2B0N2pkw1
m6taykWfSIpuleglMa0lK0BqPaitzlh1+KFpK7JWKJEbruUKPPjPedyYDuawac7ZU9GxSK6E
EmHDtC5CAtpZqNUmEBaYigkLjI3NGEuRwdFkacfHMxCLFRkbLWGZz9L/0J4xqABVqX+9xzyz
qefws2LuoxMvZpHz5PiOjg2/eGTuxbEDBxINO/6C9jf6Nz7d+qDnr9mHp9CKC+tbhwceaKt2
26qbX+6uid8Cl5yfzt9H3QSudyL1CkHBdDbVZSi8hsJIJGPQpZVSR4qg7d26Vl20ue6KYJzQ
YdcNlO/WnbC5YLPy8W58uY5L+AOq6qPIzg46GKJ9ZKfaAe7Jpzpg46fkpqm2UB2Bgjr8fjCL
vqMLoRBhkEOmcl+Xpvr4ZEuqIZYl8zNSA5clKZ2PCTpQ7kKXT/J1sY1/KDHo3thibjH3NWVw
57IYSWcW5/n5Zd+CsFMBSCbn5qxzk2X8nDX9NVFKHoqGPwzzILFVlGFAB9LeDKmnHZlAoG5T
xo933bqw7JY2FjpRJkiRTIE/KiCTLAFTtDHQjkKLE2wuDkpFswjhMr+wbyYfsJ/Y29u3a//m
zekaX1NYDos8YxIiW/r81rbXX7cOdzTXtib7ftIzsLk+5FPdJq4i09iZkHuoiY58f/72mdsj
K0MVWlU04Pw329Ua27Z1hXlF2bQlSqJIWhQtm5REiSL1sGVblCzSk5nYjq3ISlPLdaosSpNt
Wd4PN00TJ+2Gbl2apGg6rGhRtE2BIOiKpc3SOrHnNt0WDF2ArB1WoMD+DNgGzMjadUb+BAUK
zO4uScnxHoLIo3tFUhC+8z2Oj3JjrU1Ydv+u+Be2N9Yz66on1ler5ZSQjrBEd4sbc0jKtPYP
BIJ7e2WDPQH51Y18AxkHDj3/k6GL5GXqLd+loSuj75C/5m7w14Yc5D5iX2mGmCm9Unq71Oz1
ePjCRrpQ2OjxFjbaCyG/mD/XsoD2zSYRyJQXdL77Vl8kiY1E/B7SS4/Zuu0tYjpbCOECeNE+
1kP/Eu1FOpA0zLl2tEdvlXFVOCCvUzs+gAEHiiciQ7WMK7LROx5RyhAy+EQG8nvlj8b9hk5O
Gyq5RBjp9HNiGYZQA1HzsIrJv3tLEP0lyL08k2+g35M2uTdXCrt8gx6DaI3qIQqEQThY66BC
SOvkMn2UYXyMAZuBmwEcRNIsYh1uBjPZV590QXMDe2MQEu2JzjepI9O/3afQkeJvLmb6Zj5/
7omPH84nAt/revCHh5766g+lHalydWz6he1DyreHpZXQg5WBqZ8+/1HpgIaW9mS7n9692xlM
El465E2JGWVk4kxZ+46SqHHUaCQhbc22nd9y/q9c8MLmbX87Vf6W+t3Xl49FH+tfnyjsLMc2
+HCYoWSoo29DTmfBA/pBchKbki/J6N7mva37uQOxmdYZ7pR4KtZSQfaLtopieLtCwQMAWzyR
TCIUnR3p2iop6WwZCCnQhSAYjvOBIB0IBJEkkk3yqS46leoSeuxYKunwOwM5KRjoShH0OQr6
5DUciwYXQGQWjwYMg0za0NnspykjtcKwatRZJm+WDsXchb5u1njGrDqpKndTIMXmAkyKCeQc
vactyjek11DfRQg5bAlzXqkrwOAAtMwmyzJhD/gTsCKrybZhmc8Q7ic/hBOLKQTQLEvv9MLM
lYWZ691guB+2AmwZvRX48XwXPGAG+PM8RRfosCUBVQDIOt/R+57qtlmeSlmqbLURhgkgZy4x
xVZd+fv8x7W03nGS8Tpd3nw/H57ZEo52C0d9LN0ZHa76z8QD+kugKCR4MtrWdP5fCiCvr8+t
375SG29xk67kJkr5fk93NHkC/LiUoP2++KP8nzZUfm8/8US71IzGDPd8+OvPbF1NPsSJyCCi
x5hDquJ7XFXIhE4qCZ0NZKo4YAXgY+SR0FZJSstlHDnSvIC+prfjmIR7cNnDcyGa40IBJxeX
QhzBnPNBQK97Wo+g+AIYnUV3eBaA8Av5AMnpAYUzQFO1DFcHz6h6K0ST0/mgtaIoXybNPc/Z
ODbOMVzccfz0f8yxlgzrTs7wWE53wZPxMJ/LrPUptVpeXF68Q9TRNrFeE42QL5eIBrjGvFIz
HznH6Dg96DLhyzMQPePjnCfP6J58XcmhkK/RZmoNno1otAqoAn4XVzVZ1tTcLZpyedryqjC8
bbggZ9gfBPmAb6TJp8ZlTZPj6srR5aFRN0ETqQqzZ1TpiUanwM1DHb4OJ8QIIH7IzC8gM/vA
UX0LHqbziu7yZBS9TVF0QnE4HbjfyeITyI+8bxBYjhlUNjBTjD0QZcX2FIra7HZA0bQfqkwk
5gXAHpNiXgnheJfXnXbhdmca71tJLIAOvU3qTfeVEdrv5yMiHYmIwA4Qu+G2vd4Y7fXGQEyk
7XgMwAkIBuU+iZcTtCwnXHizLDm4F9tjYWdCJlztCneOXwDvzfsXIwv0ovgrtBu22nOIBCfU
BLgx2/upbBI7kJEtRptLGBXkelOYuu5QFZnNyIwZfyH0dQ4vLt/5ErJ4eWkTcQciiwyWlxch
iwcaLLbYC+lrifoqsQ119yN11BFiCcCWMM/EbayFGGgZeMY4P2mYvpv40Jxia2a3AZAzY64o
CkIuhDWbNPUZYn8/HMdEFEMhdRvQ2zatLD56o5/EhaTgBHOO0sG+XcEpXzBLUbSXyWjCwcfS
cUaqnd39GhjvaIoKTC+kr7zz9XHW1Uo4RNEeE0ud42NP/VGSvGKFPbslpIGXjq9csB/byVL+
oEMw+uIByN2dsC86gaxvbEUAifCA19uVSWSy4y7/FWN3BJ1pp+7c7LQ7O0fatkod6c4yhA5F
OlGebKNJss3jJDmpjSTuX3jA8T64AR8Z0XE0SiIkuEl+QtrIBaDpDq6VZEjOcXy8rq2G05qJ
iIS4Me5B0iRzLztI6hJtrq5FfdYuJbTB3RDc1Y0LdSJgfe9h63e5Gbjrsq6e8+dJ3dfIT40U
tbR475+1/yYzhLsBac2gci0Bpk11cBq/4zBOALL4XSFfN23wfygLVnHbuXKZpdxQgPLcI5s1
RewLAk9IlJhuOJ5srdIe2itP8acVMROOHEEvH/X6eSwKkRC+/qzpEMxIFduI/jQL9b4/Baqt
38QfcW2ht/XX1Jq2feChiT3UXt++5Aw+4zuZPDFwFn02+ezA2aEL6KvuV7MXht4Eb7ku5n7W
fzV/Vb2q/Xzg8vClkbn+eXV+LLo/uye3bxidQKrDExPo2eyZ4ZdH0F35k9lj6qnhx8cu5Zsl
EM3HRrsfOjzZFApXVkoGnSeliXSljLhUDBTXuRwqQEqZHq93XQ+GVW4hGM2yvJyG/E07VJXX
CrSmFZAxpDLGF0t0sVgSncWxMU1THfIklP2CVioS4XMhw6tZOppeMBqEjcq6W9kh/0W2yQu2
zPxhFVxVgWoE8DZNFxRND3RkDmtA2+wAjmjhivY+uImM2dDrpSsTt4uWqZtFUMzCm+UavMlc
stYynjSXOtOdyRwu3i3aiuykzGhMkZEn7/v8GncwVGLp3r2lGgFz4FJtGu6v8f16A5mfBle9
v6kuEWtCwOIAAROiOaB5rTwA32tto2a+rH7zuqDzD8ADCeP5jbBmjX/gyXvMzJi3WwWxNitW
YepBIRym1va6Mcqh5iBghQaMzK2JD8z/5Ifc2hlBWM0TcNpABaohSTHwwb/5LtfYKK4zDJ8z
Z3dnb56dvXhmdta7M7N3e69e7xqvsfEYjMGAwZfYyNiGBAikyJBglbSBNIYICHahpKGGUIHs
lEsUwKGF0tguLVRJaWlUFalVf1T90R9uUqq6VBUlrSKve2Zmw0WhXenMaGZ3/3zv+33v872+
tn7DulxtZjG77Mxb7WuSCx07giaD2ezOZyT30LpwIFXeKxDIYrVVpEa+vmbpiYtlDC2F6n6S
da//zhRHRoWShSY0XKgfa3u1RpQzlWsKsHJPU8Pi2sbCniGKMpPO+PLS6OFMOpD+Nmx80ep0
uCkqNvTnE38j+jdKHp6LzINdCwq/Jw494zQxAavSORGcbRO4c6rhUY2gEkWCkk8VEcqYYoCH
8KR07WSHqcPXLr4C9ySGfecjZ6PTxHTY0gf7ojcgWmda51snqsC6zafhqqG7oj03EMZ98ySu
xlRaTWi0ipfKOASJsQDEaKoD5GPYGgPVMSGecMXjiXjsC2RNxJ+CrIqefTnPJDF6JXc7oSwp
MZx1cdXgce1L9Var3pSIixchNq4lYFydkRh178VhXIHY+P+A2Fjr7MzM/diXOfYpFIvNOwiL
1qWfYNn/g7LYfMr6hHMPPYVav0Q5Whw+dB322UcHfvyLvkyjd3cpbbLacw1Cf2dtMhT3f5Xh
nWWRFeM9KSFz/EdigLf6wgZspzxkv784V7e50NtCU86Sim7ngXwkEU7vgm+trHC5ucRv3ul6
/hwxuJNlJJ0hiJm1DnvmKvZMCXCDCbnRSJiQwYzOOt/nxj1XHFeYn3KGXq7HfcB5mBt1nubO
OchqZ617mbPFvdbY7XjGSZqtVnvQQiK9ng3qLK5JtE92kHtXdmbJvUtyR8kxkiDdPKW8jgAl
QYCMvwPykhyQM/j4cgCIIA1kMA704ENP7EMOK/RAU6j1riZW6128ZCojRrlowwKX1kXo1Po5
gri06kJIqLV1oKtjhZmDwxPvQc/+/RfP9y4/9tmzLUc+I9qOF/5w6fI3j8Hopfeb+zcVeu9s
2ArPYJya9xVWoF/iKgRABnbKK7vgEetp64T1eok+X7oSNFPNpcsrugzPU7uoV/hL0Snj9fKp
its8tcTfBroplAZZvwwQLAlWZigKMDybZkopV7o0sNQzCd+Vqag/HWgFQZgKQ+BJTaIjsl9p
jyigQIASeI+L5z3hoNmC/2XjIV8V9fB0fBrtAyQ2dDJHKr4u124R9SaXijlSFnJrSCiTbeRL
5Dh5k9ST02ghJpLYDz2BwCSPf/ZBJsfLPkcDr251ZfjB483e46HHXcWzfJV5EtX+oFtri2JT
7P4Ll6Jn5zTXxu5qhLATqKvdY8hfHOVKM+SfgoGY+urw5xsfPdSKrNb8D7BiEbUHmCpSWlBd
/QjxnVi6RUh9MJDw50u3X+zpea3w3b9nWtMtDJttNRXKzf2NwTlWEL3ZHYu+kh3Y2tHYUjnw
20o0/MneLUd2/rGQZ8oKhVUsI9hDIV3NEBrodHl8ZGTOuaJ2cPRXm9q6/n1e2dMSWO2PsdoS
SMFm2WzwGMrqEysSuohSpn5MU0ZPlngZXrC/55jwnw+fjVxIXExei1hGw6eSFz1oC9wXPpxE
y90rPN0Q5RMLU80QJcyJVHUEnQAwJUq0mbakzSZoTJvsYigm2mm/xCUTdFSaRKOyE4SCXq8i
P4QCLbloWopNoqRsLbWYTRSdjko0Da7jmSfBQyCKG8d5g75HE/Tezhwth/ER/FlaG3XKTRZ5
/I7HwnKQU9TmMLZyeD3kBtI0S6fNmSn4CSiq/ACrWpx+/XfvP1znivJSj+SlZxSBlZS254s6
P66vpu1OLbVjoIiCrCaqKusX000LXHaB2qCgOPwc6OPCFMO6hIy5IJk3cuFK38j+wfbmzVum
33752WV9rLBsdX534Z9L0vWtu06j4c+Pr2ZYyWgNhYwmW9N2OPuz1QvObDgBV23rXLrqpe/J
HYW+6ZWrm7bCJQrLh3ET5LG+5eA/ciOBM1DCpx12ofWm9eaO8gvoku0Cd443HeBH+fkYGtad
1BE+QYBgqfTXaHkatELCJRICAaVUCSyZhGOy3xUyGCAZhfhHgiBKLlGURMEclUQ6bZJNbSZk
miZkgBP/SvltURElyeZFOVufFeV4TpSD+PjxEUT8osybBSIE4ph4Q7wj3hPnRQPOvkPXYiKb
UbeB+8X2i8Vm5mZUSn8USZo8+LWKUo/H0RuKepVpJXOwws4Qeog6ihCR8EOseZQy6qutsOfN
y0fbq6Swn0uwko4gjRa7jc91PlfhqzCIJ6dEm0sqrUHtNQUexr7WFAktrkv4BKfBaKTkjacW
dw6yrxHbB5IOK23C1Z+fxZvUp7j6afCBHMxAyPo9dIPRorNxllJbbUQftQRsJxFKwQa4Bm6A
OjgJdbI5eQukSX2wnHRPwmtytvQWx1q8QbuFGAG3oOywNLRBCG9TtXfEP4n/ENGQeBTX76ao
E8eNteFRfsR9i1NjP4utn8ZH8mfHuZscwb1aOQ2b4GbcAPS/FOffx3F/v79/Ds+7mVkcKw11
M7PatV+dVoqZUSCsTCHV0biA6lKKKxVwVuGxlVEKlyRyWVxdVnleQHxaH9K/0LqoxVv5+qqJ
/cvXS44EG6oPGQY3reqhy65WHXlR5Kmt9pgXR/SvD+5uSkt11d96U37hHb81CZvefq1rUdRf
97ttuecO6lEkhR28Ftdwi24f8EHDFNBjgNuJ6Ve25c/q7xGfU6jLMwIeQBT01oJeCtlEr0gM
YSMRPkDZoE5PksBb5vNAvszr4/RuHTTiTHK7dTp0DIwT0OC0YDQTGDcewm5GiLoZmmixIQER
8wiiARFcJm0j1DSEgMTLh9XByNX57E3mDkMw6uYqmHBZhCc215iC7TZG2VQZucyOL3gOqUvi
3AM8ShRHz2izRhkzeg2pcM3n1M0BW5nVdoJ8XnWxvq4O0re1vUCZMQpAVZGBp7JTQJk2BLv6
tP3UpTLa4i7nOqW+jpp8vEZ894R5x3/Zr9bYtsoz/H7n+H63j4/PzYmPY/vYsR1fYjuOE8c+
Db3k1iS0XdsU0nR0qLSrYEA3BBJSBwFRM0FhMLYVRjW0jtEO1vRCVDGBtDZTSyU2CU1ibGjT
UjQmsm4aMASN2fed495+TNuP/ZyPnvPKPj7fuTzv+7zP++QWwzebf6svz80Evb6If4fwcFkp
p3ruoG6It9/zbaIWxAGdxvlaRc+os5Y+oY/ylfJr8huquwL3svcFjrBn4DPW+qXMhv5dVnqU
3QBbWLoHqiwVTnRWqMNWVFHqiYnETOJj9pPAxxWzv79aZaw2Jd5b6QtwxgJbZZS4NJApFFpe
OGWuggloOsRU/QxT5V12iRnAbrjKeGwN6zaajHxS9acM9kiMygtFRmVLIWaCmWEeZ55njAye
DlVHISapGZSJyU/7JN0Nk3AM/12LflaP6aIWVSGSKOYkVToo0ZIwYJU4hsMXtd3zC43D60Y+
TOUJSY346toCuPJIPBqoaHSuJZPgkvZPPBZeMc2khVzDLJ4FW93kchPBBBNCiTHQNUpvHSRt
eJa3V9jWtNePkcNox2hNcAjXo078tbxjzq93zyZzvKd8vcmuUeUyffrluNPu7VzfPrG+XIin
nZ7Rly7cklHTm2SvjU2OhEY3qD2xbGJrXGDDu47evSJA37l85KGIzxvazd3fr6QjHb0jnzY/
eFvNjx5ApTskh7d9W2BPOZWN9Tza/PlshOEG//TLd8ZIJqVxJjVwJinwubriVYQSqqeUUB0Y
rtIUtZk+aXgnbOgM9geHKbq3A1msNuRwusy82YzkKNY5FplDsj3ky/rqPtqH+86r7jhPPDOR
trlkSVM4SSld5L/gKZlX+b38fv4t3siLiVBDhmGFHHf4S3VlQplRXlcMymt0hBQxyCQVMkVZ
X0drUEKsE/civPikvFfeLx/EUirnZFWm5XkqeCze/R5PCltLiSVc4IuepfHW97W4+xDLUP1o
ScDUZhEmVzcD+CBMMzEsD3jrKWsbJkeTSq0RkdYToTQxTaNwiJG8Ftf9/Kw/7LRPFyJJ1SM+
9gP/uRg/JvQJGXq0NrL2zgPjlxrhY6FSol0SVybl7lWFQnbs3Xnu19S9zxWs+K1HvvizcRS/
9RSaUu08K0iUhbVKVJLMvXGHs7ZJXJ+8VdyW/INoTLJZqRoYkmakm5O3S7tDO1M/ih9P2X1d
JNNzfUUSsd/u0l+TFkJaONauH1RzXLAoJs8ixENHI7aQUhRs+M1BSRIE3k7RBqPJ6BWklBgM
2bP2up22YxZPGB9we5F3ni6rDnRBaPAPiKkGXBDnqcdUm9QIxiaiM1EqOk9n55IXguRqWEZJ
nEuVSFDdmZ5iUA2XckE1OBmkg6cwq2m696hOUYsh7NmWl5c8GMvTmCC97rCs1jWJ1fctwhb5
rDaytqr9uISLjcOva85bwSn23glvRexwa+U3hb17CjdFxGhMXm57GpdmE4UlGRE6NUJLsQAT
4BC9ZdXLtw3YDOVAJtpZcbdv2vXHcmxFc3vaHHVHhEJbFwpVfSYDOkDvW/adP7YzG/BaIzE2
lBooFLs2PvJC84Ne6vjyGDr8zx0yZ4re8OPmoQc7qEPEWbyG62sWM70aWdTtTmIKzGBOwgCq
+SGAohBBxJHvE15APxFeSr448ErdM4RL0MNtD98dPiu8GTZaI47kughtEESRSiZTNbVWVRPh
DkoUQwnVn0iotSRuk97SYGP1AniJWQ+xfTYbmEsLlXgmo9gNSaEWbjzf8VYH1XHWSS2uOoXW
gIqic+IDCWIU24TFmto/WqypbaVabY3sVJ2PO19xGpziULewZh75CWnjuCO+P42JwLVE3Mj7
S1h7lwhjhK3lRW3n+WiJ8HdFSD1nzRZP1YJl1nNak9BphJ08IpVGOuBVq9fyeUzg2lYZV2hK
jy3fQo71lDFzGnVoR17wdW6OfEXh21IFdzDK4jGQD9c2rmNEJxssxyP1L5eV3jA7+OzWgUoi
zKdlOSq6HEz2h0LNyI0Mce30vmIx+r3Z3CaPLRNWXILVEyw+3XxxIsRlRnzfGE/X46iz+ffx
7rZALJyWOY9yqfcfrhU9VJQwu625mn4YM9uLGPWmA3mU5/tKVkEUOoUB4RB1nDolHk/Mdy/Q
C4ZzwjnROSxNSTsl2pDPZbPGtlS7mBe9hlw205VKBCVLOG80mbG42h0WzlBq9C74wRw9m4q3
u8Pz6A21nPeqdl/R7Q15KW/C8XWOiOB+7iBHTXJ7uZ9xtMzl8G80N9zXO/x6GdXLE+WZMl2e
pyOq03AhT/xNnvibPKlNDsvo/vzB/MU8PZnfm6fkfC6v5uk8EdHKZRGd1kt0mhgh/EUz9YtQ
X/6QaKjmfnRUwEf2mgcynK7qfhTdhQIBjrkip1dr0ARYUbUmqFtRnVW80RqrcTTaITrT1bvK
N+btJld/PBdN13Y3z7/7zJPFUHaF4ndaGIvRbHKXh7dlel29g2yPld7Xd+tTTf/Qs2MPTsoe
r93FFMKd3cPqxJvNmz89PJUNxVWrMWsx2jpGbqlR9z230hQj/P0VnTF4KRfQIKoOqgwgGpFg
qJf0XP8EsmuX8MOES2GD9/PfGyLozDA+Cz1Bn6ROGr8KfkieBL//osvgPYX2gIE6MQc1+yka
gKVWH/0deYcfal5dc4S6EilK/EpfMZnRE6PZqMmQo839ic76tx6ifxMuJaKM25KzerhUbbB7
6mQ3tD63/WdQfAvfxZOkfA2ewjgPYAjoMAYBTEMAZtz+LQcBbDkA+1YAx3cAnLsBXG8AuC8B
ePb+e/jwmv7f4kddBOC2AAhHAKRHdLTvAZC/dhXhzwCitwMo63QkLDqS+OHSGF3nALLfB8hv
/u9ReBugNAnQg2MFP0cfvucqvocavi+1ATCY0bFyNcCqXwEM2wBGawBjKwHG8TUnfQA37gdY
h8/foAJsxOfgZWHqLwA3nQaYnv0//uf4l3Zh4jidUTyKR/EoHsWjeBSP4lE8ikcxrTEDEwMj
uF8pwsAMohilgJiNgSAAK2bgZODmAfYRBQQZhEVExcQlJKWkZWQhClRU1dQ1NBm0gXboGxgy
GDOYmplbWCIMcHF1c/fw9PL2YfDzDwgMCg4JDQuPiIyKjsFl4zYg3kjYYdQCLAwTgKQcgwDQ
q3wfFD6ofdD8oPfB6oPbB88Pfh8CPoR9yPxQ+WHSh2n//zMwgOU1Puh8MPjg+MHjgw9QPuhD
4odsiDz/Y+xQQEVAGhr6+AAwqP9/xKuCgyENag4zgzSQZIT6QJoBZj4bkGUGMomFEyhixhAI
ZTMx8DG0Q9nMQPGpUDYLkH0aymZjMGNkdApwcXV11w7JzE0t9kstD8rPTczT8SxJzMlMJk+K
wYkhgMGFwRUI3Rm0GUIYMhlyGVIZihn8gGQ5QxBDPpCfyJDHoMPgyVACZOUAVSQDxVMZ0hlK
gbxEhiIyzaCnLkhsME9h+MRgw5DBwAoMcQEGfQZHYMg2AVMOM5APDGzGCUAZDhYgC8SD0Qxp
TEI8DIxwgB7t9kDA4ABMe9M4QMac4TBgLobGPtPMWZpLVI7H89t85ZDkAKteLL9jL4je5H3/
5x/Wvz0c3zgMGEBZmBGSRgACDAB0f3T5CmVuZHN0cmVhbQ1lbmRvYmoNMTMyIDAgb2JqDTw8
IA0vVHlwZSAvRm9udERlc2NyaXB0b3IgDS9Bc2NlbnQgODkxIA0vQ2FwSGVpZ2h0IDAgDS9E
ZXNjZW50IC0yMTYgDS9GbGFncyA3MCANL0ZvbnRCQm94IFsgLTU0NyAtMzA3IDEyMDYgMTAz
MiBdIA0vRm9udE5hbWUgL0JQREVLRytUaW1lc05ld1JvbWFuLEJvbGRJdGFsaWMgDS9JdGFs
aWNBbmdsZSAtMTUgDS9TdGVtViAxMzMgDS9Gb250RmlsZTIgMTMzIDAgUiANPj4gDWVuZG9i
ag0xMzMgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAxMTgxOCAvTGVu
Z3RoMSAyMDk4NCA+PiANc3RyZWFtDQpIiVxVCVSU1xX+7n3/PwOIilEEBePgsEQGXFCMigLK
DIorbj0oYhhFwQVBpUbR9ighHqomR1JQSaPGcKzkaOLQWKUpMWhcaosLmii1GsWlYgxoNDE2
xfl7mXjapHPPm3Pfe/fd5bvLDwLQEeugkDp5Wv+YqROmVwJT8uV00rxcZ/70lB3/ACaeB6hs
3soCi3tMw325uwqYixfkZ+ceH/hhHeCVCegjs5esXmBLDDMB4SLSozBnvjPraNN6X9EnMhiS
Iwe+p8ytYvBd2Yfm5BasstX3jpT9caDTuCV585yYfrkZSFgr++m5zlX5Xnn0prxPFXnLUmfu
/FNH7hnA5GLx53R+3ooC41u5weSs9vv85fPzt54pLwKC/QDvFl1e6hPQW1awKkMQYDTJui2r
2T3OaNMXw+peZNxQXeV12/P14y8Mj8mCVzADXyEGBTgn3HgcoAR44zvykgDXIYCmg9EdNbiI
VDyE1TiCa/gescY9dOFDSMH7lEJp6Ic4bJA3ViRgGIZjEm6JnpHkI7qWkZfbwAQU4R2cQiP8
5T5XTdEb8ZLQLr1GNGfJ6RVKp7XGMaNR4q0wDPRCNP5OwVSgJYu+5RDL3n/EUPExFzsoUGId
gdlYiEJU4ST1MR5JjjfgFtv0qRiAMSjFtxppp40DxlHjC0SJh3GIl9eLUYE9qKE6DlFJxmaM
krNX8DZ+jyPkQ1fVi2qLkS3oDEQGluIQ6nAeF+UmlWq5gNfwZYlpCMZKRLORh2L8FuXytgr7
4cJh1KKONBpCL5ODytShZ+vdCTCjh8Qch3TB8QSa8JS6UwRF0WAaI+hlUK1q0Qr0GD3egLEN
XugsmnORL4j9BpuwF0fxRN70pUJjuVHyPHfxmCkyywSX9UK1kpUvqRv5i5fv0CX+taZpwcYa
WCQbyeLpRMxCDpaI9Dq8hkqcRQNuooXM1JvCKYEW0Q01R1Wqvapeb9QfuhuNVcaHRpNxVzwP
FYRmIE1sFQm+Jdgicf4Zx3BccGmRWngqVgNFTxTNobW0nd6jerpAP7CNc/mc0HU1SJWqW9o+
rU1z6yX6XdOn7gZjnERB0pEaAsTCCPHwFxJ1Nl4VJF2C02c4ib/gHu7jO7HgQ76CWKzQMPE2
hSbSNrF0ilp5JKdymljK4zL+SEH1VJHKqbaq3dogLVFbrV3RmrV/62v0zfo+s9Od6a4QjLsa
/Y0xRgsCJccJgs5iqf5VWCu5LMM2sX5I8tiIK4LQbdwRD1rxQDLwA5nEiy5C3SiO4iW/7X6k
UxblUTGV0kf0J2qgJrpDD1hnE/fhIRzH8TyKM3klvy20g49zq+qqIpRNrVCb1cfqmLqgddZe
1/0l+zF6iu7Uy00VpipzhHmsea6Xn1f9s8hnX7qtbrs7273Vvd8INUYZsw2nsdOoNA5Lr5ww
/mpcMx56akJJ5fhJTMHShTbpgHjJ/HhMxRyhpdIlayTzr2Oj9MVb2C4oH5A466USzuEC7uIb
PJIIibyoA70gNREh1M9Tx0M90SZKpIsonwpoNRVJvCX0Br1Fv6N3PbSPaqiW6iTzV+gq3aAb
TOzH3bgX9+UBQkmczAu5kIu5nCv5IB/lY1IZ17iJv+aHyk8NVw5VoirUB+oT9bn6Qt1SX6nH
WrjQUq1Bu6F31cfrK/VK/bB+TH9qijOlm2pMzWaTuac51Jxqft/8udnwisATCpc4ruMnP1XM
B/gx1bBOhVqp0E7apYV5/mVxIabQfnaqHiqOg1UctVIJr2IfapX9LqnLUHbSTqnrZbBTChej
4vkKk55w8HbReppTNDuVaPZ2azxAv6j5qwxaDystRax2Gun6Vq0UYTyXr9F5bbDyEVsvqqPa
Tr1ZzZYXRcYDraM6y95SW094mnqPr/N5+OCSdBsQQ97STwfoVda4kHbyfUH8a56kwrV01ao+
08JxWM2VKp6MCKOVQrFVZeOy+iWXqnAV3u4jXUYBG7yHu/MuKpSGC5Zpe5hslIN/YSBV0XBU
Ub18CcKYEYIVdMqkOIhGky6VHKpieTlt1pLoDhdRZ3YLLuP4hGR2EkfyHjonc7OaF6g/qDTy
x5uUwXvQ4L5JLqmhWapcJtT35tdUEDZpGdhNdvkMl+Gg+1N1Es3qLK1Q/6R+3EcrlxllFexr
JFsPpc6mqYNUpbeaAukkfoUzaFBrpW4/QX3bmLZqFPPetr9pWfwxZSsb8mmIjJEY5ChfmoEg
d55xklNoIH/jXu0+2PbIGK0+aOvU5lSRMk9KsVumywQwzZFO3yBdkoHxMllqsME4If2wXGbb
TPkiVVCsfI1GyjwqlMlzSaa9WSbyTZlTtbQILVyA9Har2CezNFXfgy2JiYkJ8SNHxA0fNvTl
2MGDYgYO6N8vOsoW2feliPCwUGufEEvvF3sFB/XsERjQ3b9b1xe6+HXu1NG3g4+3l9mka4oJ
UQ5rcqbFFZ7p0sKtY8dGt++tTjlw/uQg02WRo+Sfy7gsmR4xy88lE0Vywf9JJv4omfhfSfKz
jMCI6CiLw2pxnbFbLTU0a0qa8G/YrTMtrhYPP9HDb/HwHYUPCZEHFkdgjt3iokyLw5W8Mmej
I9Mu6qo7+CRZk+b7REeh2qeDsB2EcwVY86spIJ48DAc4hlczvDqKU66eVrvD1cNqb/fApcIc
zixX6pQ0hz0oJGRmdJSLkuZZ57pgHe3qbPOIIMljxmVKcpk9ZiwL26PBJkt1VN3GzTV+mJtp
882yZjlnp7mUc2a7jS42sWt3BRTeDvzf9j+sVw1QVccVPvfuve+Bv6jBCkh8zBMEEU3wD0iV
J8obE0wFRAXGsahgjI4J1jaNNSa0+bHzhDZqkmqbaBxnUgfa+EBlnlGQqBljE8dmMsSamrGd
xLGpsTEt/qTC235n773PB9rWdCp8fLt79uw9e/bsOSsWHzqzfGO0NEkECkc86uFuILDRE3y9
pDxamsJ/KyqwBnT1VH9VwI9P17MTR0yAIWw+b8XaVI23kEeqVnqCsd4C74rAyiqcR2IgSKXr
UloSE30H5Z8osdATKCv3pgTzk7wVS2aNbL6HAqXr9iX4PAm9JVnjmuOGWN5sHjTYbgwYGN2o
ichUS03nVlFpxJ0aW+R9EFEQ9CzzwJJyLzaSw39qciiwLAfT8K9Cg1awGsfwaDB2ZlUgLg/j
cawfNFPjvJ7AVcKxey9/0XtkiT3iSo27Stzk4IjEF+ROO5iZGRw7luPCPRMHCRunq/7krHFP
hPTz3to4Dwjuo+JyqFXkTYDPU1L4VDeFfLQUnWBdSbnV99DSpBbyTcisCOpVLOlwJPHzWVLn
SCLqVV6E737i/xDEB2PSIr+D44YPK1yRF9SG/wdxjSUvmuctKqks9xQGqmzfFpX16lnynIjM
bgWHzSwXSbrd0pOEkiISF0Umc6d8QNBIxa9LRXJ1yB2DUFQjmscfjKuabf2t6JeScpdKIXmF
tRTdUrPNDOZl9u4/0Kvfy7wBAQGDjTS9qKwyEOjXS+ZH2gkE/F6PP1AVWBKSdUu9njhv4KA4
LA4HagurnBMNybc2JQX99RXYxAotL4vUO5DcKeFCWhir39zZHY59A68Yd68qvtmVq41UFdaG
SKY1xhqtxCAqBua6GukTVy4t1vE+1BvpEb1RJmD8mvFzKtYJVaGRBoIv6LmyEuNrgPuAGIDn
jQa+A6wHvgLmAAuhUwpovEYERAdce+QNc4GsB943F9AL5gnZinYIbTJP0M9cubJdJMuQQfIK
xtuNT2W7O1kewrx2yFejf4wZsiPGWvmh8SntRr8D+v9wJ1M3xp/DGOu9i328o+fS6+BkfP/3
WHMObOqCHenAMNFAU8AZ4Cy9MczffMVYSwnQydBzw62QDUD7XvjmHownop+NOS7wGPjQCzsl
5GMg82ONXNiQC/lu0SB9kF3ST9JC7Rjt1E/KGfj+GHvfDWrfvGd7T2y/bdNtwLp5wP3RwDez
ooHvD7ds64O1VNALRM1iIu0HrwYehK2f6aeoGvwHg8K7zX/SY4wYkj16o7YFvjpoVFO2uwE2
n6D55n68yqrpXh5TIHnZeFXWiS6aC1mm6xWsVU0T9fsRZylUry8nJDVKh24avjcKiIXf0o2z
+HY1lUFfqnUuKN/OAwbFEO21/VTPvnE30DPg8Zj7Fez6AnP+zoB9XiCN9fH9CfD5LD53bUF4
I+QpsP1JINdYG94MvAj9LsT+rzA2Eu3j+M4k+zuhKA5x7EXDPh8HHQ6U7xvpF0ArsAe2DAY2
AcXo9wePQtzNRfu8isVcIo5XrNnNffBfODY4BmDvJLbd2oN8W8XYWZqNmPklfLgeqAEedxGt
s4Hzk9/n+8Ixq+6LtfZNji2OGYc5vg3SNL1J+5L3yTEVYb57PZSh4pD3jthy2LY5hdnItFgQ
jVP2It5usYqlbL6PfCccduzh+4m8cZ3Z8PG3EOuIRYdtX1yMcKc84kqiWlcx/dhYjdhIoFQx
m4YYxVQAuyYZb6o7Nsf00w/0dynW3UGjcZZzYcP2PryN4e7UVpoddE7ln1O0HZxmdOLl3KmZ
ZpP83LisdZhN+tPcvp37wpnLzIiWfdPx/wX6R2YTLUf7r2Yn7k4nbcFeyX1Juw/wOIzxFqAO
GBuTqW2LWaWF3PMpDnHTBTyOc8gzfTTV6KB8I5588FMqxue7XkYcraIi+KtS92n5xiqtxNVE
28Uq5Hh8S/+IFjF4ffDDt+JJxdqUW6xiKOs2tuO1L3PO57zrMMcz36878CHwt7g2ID+HVH1A
jlZAnUCcLbbjMtFVKA8Z82hEJD57xSnizIpPibjciTUNOx79d+DjzFZtQexZ99TH9YJzOe/f
zo9pnCM5z+Huu535ffmWvlaD3LBC5eFTVGnf68eAeuA4ZOPsPMJ52M++dk0lnzsD5zWAfOZZ
8mGezzWbpmPfVyM11ZA72N98n5xayn4CNkTqqF9+wP6AnOcdM7pQ9/h+wjaun67ldM28If+m
8grXUtxDdQeRa9U5XILNCbJMlFG+2Ih8yjl8DJWoWjSNkrC/rfDvT7gmim2cuyEfJavEZtRJ
6IqQLDHLaZ15kh6Azli1HuYw8xjb79pEWzgXmAVUaZ9VyHkXuGfJn7pPy3bXBtpirsb+NtN7
2Eub8kG8/CP7Qen+UMbzWu5yWWcMle/zHDWPdTbIjewP9lG0LziG1ZuC1zxFW5U/crFWN12L
1WUbwxVP59xvy4/NofKsOZliYtbKfeaz8keqXodphthKk/QueUncoPEc9+4d8roYJc9wHCkM
wrspCee0Xu4w1tjvCvW+kC6+P/ze4Bgx37LeE0pnIi3DO+0hhjGVvm02UIXYA5TKi+YZrDdK
+TvLmEAjRKo8J0rVfZHWW4bfCeFWnPtrqNMJfMfYBnwjH+1p4hjuVRflI5fMcJfK3xqLaSRi
brJVvyTiVBba/aM2jlnQTltzNB3yMtSHM2gvQnu63i6e0ttpKr8DjdHyHdEm9wpTrhfPUhNi
56r+JOrmVgoZI0gYHlquT8fb5CXaI16QB0Q9vSo+ln82Jsuv9Vr6rr5FvizeoIVGnHxNXKSn
xS552FiB+RfkJ2jvFx30prmSDhtu+bxxhVqNVmo2nqJm7UOqFU+glgyV1/G9HLX+S/SI2C6P
inp5FOsdYr1osK0O7mBzLWyebdu7NNpeZattp2NjxL5dtMmxj/et1mU93sd8eY1IngNSLQ7z
u3wa53WVs4oo2zURueg98kP2AVFPK7ALc59Bvxv4DdqTAaiE8coIPw8sBPDm7zmCZUqANPS/
ZyTSUDvP1GA+hsPZwFLMawL/DvwZgHW7LwBYt2cJ8DDanwM43pttFlR7J3Sewzr14GR7/NeY
j3bPdrTngvuDtwIzbQzB2EPAQIu7L3B83vYu+f/znevRXbJdfzIsll/fVlO+CRfdFfeqQc75
/zd2aktfdvzg1NEoe/5dzevFCJR2+4dm9Kc63LedwF7gNGDIDtGxr7Aw2xcCZ45X3JKekX2Q
BS2JadltogNvtTE0CgPtLcOTlKStpaDAbkzJsRr7xmZln5/RT7TRl4Au2kQ7pVta+9LHZ18J
ifYD2ov/Ir5qg5s4zvDu3kl3sn2SLMm2bMVay5ZlY9nGtizJtgw6GQkSxNXU5sMmGAQ0BCZQ
AzY0TKZxKeWraUpn0ibTMANJSCktpZaPrzNyYiedaaGNSn40mUkpxdNxm+kPynRC+cOH+u7J
E6Yz/dF/PWmfZ3ffZ9939727vTvjDwQymfsWuaa2BmSNXLvwVKDNGnNBhBSUXVA4ZAEch0JQ
GnBWr20EfEuvLQSMQukl1+SzHEaIk7MdkTZZAXiXXqQz9GM6Rw0r6dfoKP0O5XnqoF7aTuPU
MEfvUXKOZujvKHcjezNLXsmeyI5np7N8NptVbirkFeWEcl55T+EVJTzGjxnIGBnjiIXDN7jb
3F0ux/HHuVPcODfN8b3cRm6YG+P4U2ScTJMbhM8bbnB83nCc4ym3kItyvRw/FnNzWxFGwzpu
1LFXx6iOC3WkOlp0zOl4lyG3VfWELTEvucXGAp6CchsKB7m4Bbm4hYb1FnyrQv91yJEFkEKJ
QtkIhSe34Hcdftcgaw4M3xTIhAkSUVkZXCC2YlGOFZPD+CSKIgkv0rGUIRlGBwHLGOLRKwel
Lw5K+w5KMYkEkRcMTh05hniTjna5zCud8Uo/8krf9krDXulZr7TUK1V72aBnkBvkZob4Ax1P
6/iiXOmW7rulf7qlv7ilW27p925pr1va5Zaec0t9bilDHCgMurfkwrD0ICw1haXKsKSRkouW
uAWZMqQExcFxt6pUUo10qQoFCqtKA50ibUghkFvSrNLXaMxEGhHFtdD2A68BbtD7JVKPZbQf
2hTv1PvdKMCzcZVqYA68udRADKhU9TRRDf9KVdxA06ryGtD7qpKlUziTj4SvqPR58Igvg8dj
0FZRiHnCEyiE3wROq6EMjBpXQ+dgQvg83omeh+5fAO8BPqN6GsH8E9UTBHpX9USA3lE9GyDE
2/AgZ65eYoGn8H6k6J73sQnESvDe/NrwCETeAbxrPuIwMOt/Ib8mvF0NHGChtyKP3r8FRXRe
pirVbOZLoM50ERQg54C7UEBvd6qBdphMSPU0Q/QAfFmy3jY1cg6aFIIegGZ5PkVlqmcZULEa
zAKJqrIfyKjSc0AGNbQHCF0Byb/gbr03iWURy3Z6N9BI/wHO73hW0FlY021Fw1ilfwJx7SV6
k2bpH3XpZfpZ6Bj91KPhNSr9JKJTVtHpIyXD5op+i2X1JL0+yU6nSn8T0CBAIf0wEKEfBDro
+zC0VqWZSEZk4gt4J4h/qmH5yg562pOl7wQ1/KZsoW/D0n4Mqf9ecA42E42HyAc8HXSMDb9M
XwqsoPuZ8jLdrdTRr8NEMAzaqiynWzzHaCrQR9dFMuwUoAGIsIeuhemI+BJdDWvszUdbETpJ
k0HwrNJnIhphk3w6kqUJTwNdAv5q5VLao/TRGGRDDhyjnaEdtNnTQhthtLqf+iEdbFL1cJHW
sZmodHV4iqxFAv4UyhG5WfizcFY4KawRFgvtQouwQPAJtUKV4BBtolU0i0VigSiKRpEXiYhE
h5ablRsRbDQOo5WRkWfI63UrYQgAiAgWCVqOTr1HDsNmfRhNQ+HSdi5Jkv096bA/qQm5vnSH
P5kWVj47MIHx9wdxMj2zBSU3V6Xv99douOCr69KGmh6ctiVRclWPE8RpchSuilUDGs6xEYdc
aduSgUnYrToPvepi3H3o1cFBDO5HUOm+qDNqW1zcuTT+XyA1j/4nh9P/H4fTX5l+Pdk/kP55
5WC6jVVylYPJdF1/1fqBSXKUHE7EJ8kRRoMDk9hLjib6WD/2xgdB1qLL8E7ojjP10bxsM97J
ZHDNbdZlS3QZ7CJHQAbbwxFdRjYgymTQv4HJ4CzndSHdHeqadye+gUK6LiS+oet4nA8ro65E
fKKrS1e5Z7GsB5Xds3rQIiaaiERAEogwyYQtAoKJiE03tz4xe/LmlXnzSt3c+cQczJuH8uYh
MPv/L8dzPf+zNLG9vwcnVw5MiKhncMn6PJdady3Wr6TiM4sOua5iF/cZKvQPpgtqetKFNT0o
GnX6rd14YTItrWKXWy7dwdL4Zd1YlDaCVIDCvEQ8zpddV3mEz+peiqBbmjc1xZpizAR3DTOZ
odsyb3K+HPFA7LPzJit0F0NsZ2J7HP6MRuAY9Sfio6N75w/EYBTaIyP+hHM7WPKoK/x+hBLx
BBs2uhf5/SPQM/JlIvbCbQo3KfsSgR+8HQhImSA4gy3IiASyR0UGXsOWixwqEFjlEkblotEw
DXaCOByH94Mq7EeQmPvdj7q/Yr3XrTzqRlGoWx8CtLZ4ij3FtQCwO6CHVdzMQ9mAHqAqfgZy
9tfcHG7GjagQ+WQbihkLuVmLCQ+bxkzEVF7UPYlPgGPwObRbuYOid1pb7G2lJQ5jTbUv2B46
lkhtisdTKdyYYgQFZrQ7N8c9MmxDDtSIfi1b66tMBe0+BnXtAE7Yti4Au+a5Qst9JLdBxWts
KK51est9rkbfgrqgs7W8rSLoivq665ZXJOrWPbW2/huuF+vtlS5fPd9ASzR4liFDNZAsFUpU
dhRFqWwrjMLjZ8cFS3mTb4pUw6u4GzXkZi6AsUEDBnsD2FW+olnDwYm/s5XdVx5hv//eHKxR
r8Eio3dwsa2ss7UFD+XPEG4rhUUTIhjZwmHl4ZAtVFZtNApGDkqJozTQFg6FQ/ZQsN1HPtn0
3UX9P1zXeXp174Hl/Ynsz4bcjQHfsjU9kj1Yt6AiWNP3zXDQsG331PpTj3/5eC7V3ZfStv/t
8xlctjFetnTPx4//8HlsaGlrR2nTCw+w9uFwoAt28Ra4MI5DVivQedldUWUqan8aLcXEV36l
nFjsZpO54IFJxMIDUS7P4BRyIiepkgvtKbsZc6Z62I/hIXTZbHeYzXbnVXh+lONtsquiAhnq
TWKR2VVvt1LzQvNx87iZN5eZXQVXudfxF//mukpgm8jO8Lw3HnvGxxzO2DM28RE7jhM7xkmc
OEziZCYhIclCSAgJgbJDOFQSjkANaEEJAVSxIJa2QFfdpXQpSI1KL0HLVRckYFtaqdWuhOil
0nbFShGCLtaWNkJllzh9b5KtUDX2m+eZ52f7/7/LqPWIbXE9nonzdxCi4iqR4afzR9mFcWqC
vxsXJAV4x/jP5OSUl+DzAC0yxqPsxN3qKkJH9QMAl8ctWUrqm2F9ESoSKlE4ZIlGyBOFa95I
fLttZsC2uTcVvJuA5vqU5zUaIPR8/o01spzizJEI9LeNwskzjFdK1NGRcexoHoSwX6JapIh7
Wqyipja2qIZMgqhQ4itZWFGTdjeFOuUl/s4aayxeapLNVbFopUlmiBykrwM1ejIKozmw81oQ
gCBvv4GK5QAjV84zgMmBC5d5qjJHfvdakPkUfdANhB87pK8GHcBRmoNmzVGrVYGqB8liQBSD
4hz5rsZpZmB+ECxSi4aKyCJv3Q1QBQoGZZ7r3fnsdFbPZ/lHST0/pWNkzejTU4JTSfJ5nc8L
ioLmCGuKgh7VVTqqGIbRXInMlmg6nTLYZjFb3BKaWBD8oph4qRrJbWAOrSwDlOP4wK6RdUvq
19WX9/9wy+HJ3uXK2M7E4g9+/PG+ppiWlN1lp2uak+2r34Ifx8VozZHu1nUNneKB7d8a6RtL
lISqMmsOPD3z1UQgtTBj5YdV/Wujkz2IyX2zU7CXPIu0QSISms3cQljsLU4b2YIqRWoOriXp
Ul3Q1S9vPIXFR89P5w32IOK8IhLkK3PwEyQT7eiZnVcO8uyGOeXYMHPifxoCZm/NPjNPUMuI
MHhd6+PAKgDbeBDjkqFkWCEysJFqcKSFtL8xkAllwl2mDqHD3x3iOcCYVEAGCMka7g2F/hxY
zzisPkb2e3wyDS0+WhLcPgkiLpCbtWLWITqwbLCAYB2IIAGOFzkAOT7g9+MFdoEXebxAEPhQ
jjyrLQiHCYamCShLNMfSAlta7mB5gec6WOImfEEIaBNeYzQW9LBDLGRz8MOr5yMggnY7p3mT
gir0CAeFEwIl/LqUYSVBYoVS66L3DI5lkMogkQV5Xn+uZ4FnSuan+Dy6wWPqYe7hA7/kMf2Q
TrGIgEfphbLBRDQBKCbha/KrRHx1RET9DyJqHMENK5tOZHUADMWK1pcgZbOA8BxZU4irCFrp
elCGbsEH4Ae3ObXbBi5a+7ZFCtfKZh4WXjg6ljOFJYwix3o9IFDX2Wmjlr3cB0+mYzUZKhKh
+vZ/ftZ0+OV4MpJuiUSs/NpV5F8aQ+ifCyRGZx9St6ntBE+UEOOazRez2muL8eDKzf7zis1e
K2JL8KALq62rxRG4z3HUTwl1NOmtIxip24SEXOPEEhWFaZMnFOjW7MCOxd27oBafNUaSa+3e
8Nh2g4TxeLb7CdL2LIh3P/kCnYasU4aSO4mUIe6ExVwUYiGc13InFnJt8ndfLoBL98f/Pl64
9dvTl3p27ts/unXlju5vvz8cPPJ4x0fgV4Db/1F2pkDuGqAalCMvCv0nxia6TsHqvx4zlOp7
yNOPIxx7QEpTnDa6AarmBrrB1UV3uQaZYdswt9e6hz1quwBYXhR8PMewPo5mmIDoEl0Ye6Lo
gp4cXKS1ErTrFgF5jha95S6RJzvgRacK7oB7YBaYgkh1hsAhcBtQB8E58CkgAXFR7vBo9cXq
eg845DnpQdvM3rnq9dV6mBuwkhBh7XUvI0qi15oD3p99Z07pEYtBPhnP7gLx/HRSR2cUzDQO
4K8CsL0CvCMq3pppDM45V1CNoDGHSur/EYirjTf5BUHP/uuKzami7j6+4hCMs+ay86pNtnEq
neYVF3pyIsc3z+eiNaCEDBv4NGCJLaQGgRIhNQw6TYuHS+HYqcJ9T/MQMzNkH14XBQvfuz8Y
pZYV3va5R3bTL8mBirIEjES6j6A8cuBtlLGIauQcx8hzRDFRTvxDy2QCawOD5X8qN9kcFtEW
JM0BUGYJ02EmRaeY13gzpCHjpJ2MCXmkLwR9f0Q2rBH3UESzR3Lw6s+1IgtNX1hP5cAi9FNs
9O8ZzeaoZT6xh0BIcR5yA7cBSHTNvTUGKzkM0xJR5QwIl4vqbQ485AAXrghvNUIWYmQ83p3H
sJ0vmhutZNFb3LgDbtwBvOVl9F6jQthh4lh0vWNP5KTqzTsVPYnTi0IYNCd0JCZo17mIkq6X
zHNC7Cw1jAWz3hxtJucs2QzamMGuJV/X/bsfHL5w6Dbo+n7/qljDT0e7dq3eoLcF5KrMDrC3
Jbb0S20DC46/cX7LJOj8TW9TV/u63X4x5khsere1OLh4DAWV2XcKS0whVOdaoo3oAwL+HU+1
ZpuyQuQUxd5YAZke6woY7E+7Jy0P+03oW7jdFqc76Kbaw0vtsSamnY8SJNXKNKpNPU2wqSlc
TeZQYikBB+oWV1vCtqWNxVx7b2/cVSS6XEXLFQ/6f/eJ6gGeHJC1aGsDhetF4XpxVIBCM2qI
ooJoeEjNUibK27+zE3TeBBkiSPAgo/mjDQ1V0RPRS1EyeiB4mUsEEjCY0BIwsWfl08eGuWWn
pvQ8jw4dW3vWaNQUcnNDjw3lJWQkLyoyQWzwutEFZb4TyquiGyfioMQSxq6IuxE1EqTkxsec
UxoWX182f8KjYfgW1KIvsiamBZh/ZVCkjJSBNfhWcNP7bwSWVrYKds6b+qBlzdpHz/69e+Xo
lSaXb9uBjYNbPnxzoDU0WR1Kr1BiFX6lP104NNR+7J2Jrwx/s43cuKOxbu2Z1xk6JLKc0yHZ
KhdE9vRN3Oxt6G0aKQ8Vl1Us3lwTHe8bPLuxyCoGqx8NVyvF9c82VqZfjkRW1bRsWduUbos4
Ec8SKDlsorah5FBO/OGq3Soojtzsc62OF5pJqUgKS2qsI7A3cDB22v4j+3n3eelS7HrgMz8r
OTm3x0r+7b9kl2lsE+kZx+dKJp6xZ8bnjAePY3vsxJmJc/mK48QeArEhiJybhGOzhIpr6Qeg
pVrKkZJdlqyaVk1FAe1WalhKsWBVwQZYzCGBqogiVV0hGbVbqaK7LK26oqitmp7b2H1f2zGg
fph5j3n9we/zf57/75kFNKZjHXxuFuYQrmmtbL1SV7ffzer1qtthccPwut2O6t8iGhu7BCot
Upern/TbQI7YZm1nbIQti6ma1U779aSjwe/mBgCv8Y4GSt5VqnT7lpk2efCLcaEZUG1yXH02
XbVsrWgJayHVlMIJfROJFaOIFjuCCtSY8UoHwGPFrai5TLlRH/ogMTLa1Tk6cuiXRhNlNAaS
ntMXV643zljq3KzVgA5XfXW0q2sUPvnQUqzLTJtZ31ZL/t9r230x9FGPbPOg/ij0Er7w96qP
QU4NoPe1n5oSPQdZbGNgrGlj50jqz0NV7NDvhjDEy3nrvHW+qBCJRtekhZQ31Z7qSa/ZYB3v
G+9/Q3+gczo2vfp7QydrTlpOx9/rnB06V3NBf95yIXCh87r9P53/Srl7UilEjyJpryTK9ZQ+
qutAkZQ3R8jogvxQxuRzVlGMKM2WZhgBRWnWdXSo8YQlAZfxeAJJpdR0r6UXLtPp3r5c/+RA
8BaOIKC3xBGtwVQ9AHradCoVj3dQfjkpa/KsfEa+LFfJmXpaGfQ3K4l4b5obyuJrNVrMEAp6
V3moYEoWVzRdR4aIo3fjaByubKlMul/pe9o7n7YPKnycT/PKILXtBr623LaosKSuX4QpCtpX
+Cz9t0hUZeMqBl4tURVobMAb5vdiWQSQqipQVTS30hQVQPZDTcC0LosCTqfhR6iOfV9DisVb
MwSA7rucxlivhYuls4U/zXMxIVv4ZJ41JsoGh0PaL5ViMgLRvzR/LqjnJbuiKQYnSXl5UU3i
pXmdHPVh8tGp+Ni+2MqOFYE3YxtWBoLhtHOP3VBD13j9OpOn5yeprl77Pp4hDQZz/w9ijq6l
W6yB9A0c3DZYuO3gvEEKHcHn8kP3erYn+ppbt7x/v3uHV0zHtB35mWGhhiGldr3dNnVgVUAd
Q48PWkhDNfXKbw5u/Rj7bthC6reeyuU/w97a4ud4Q10catZWWCRw6ANoQjtt6mr4JoFtcA0r
AxGcdtGNLZG9EcInRPVpfarh1bZXgztrTtW823i+5mLjdebTiIEQLALWoChIoFFVmxhepNAG
tAFRhBx/TscwEclj8UChSZJHQZBIk2ppgsumJtUXrK5G2nLByVAIIVWF4pO8xs/yZ3iCz4i0
FPZ7pCaVYzILEipBLZnUoNL2tGletYclXuWl8Es6WpbR4niFyMvqKUL54rMilVdUwzQJy0VE
+AdUCpQIVEpRIuB7SScVodxA9IXHV4AoaoFGNBZM3EA0AScXa3Sysf9XysvqeFkc1fiLeqg9
fCSx+VhHqFc4CsCRomWvzlJ34mwiJRwxmPR1kW9PDRVureC8bTQ6COI+fLtn25r1ifaB/Ei7
keJqpDDj4P+ptSjD6AeKhTaGjuW/zP8ae3OL31gMMIa0AZ76GYgvC3z0uuYOmeMObMJz1HPG
c9fzwFPFxRFSiNfQzg4TobWFQ5Ddr7BccdScAIvmiDsERuzyWDtMtBYMh+boOzRGy25YpcGt
j6vwfq7R0MfpMjwVR39pnJdNyxwETRnMiucJeJ4onyfK54mXz1dagXG0yP8YUbzIBMaDS1zu
AkptwPv9M+lr+U9OvXNyzweP+sJy6nJ7Xb2z8ehQGz639s3+s/nbt85+Y+Zv1/aFa5P51ptN
nYL3S7R5MhQDxFmozvfivwA3JIMc8F61AbeS4Z/fwMbW4WjKPGoetQ3wbzimLafMJO4NcRyG
c96Q0YiFgl6caKkPeTmcwIy8YrM9NQqK3X7fgSiy/FTCjMaIQ7JIUPEOhyTnkEkUxVqyeM/V
6mqM5LL4vBapX2Wg7TnBlhN4xhH2Sw4u0KiDv9DBK5rToS5di07TTej26uZ0l3R3dDW6XRHs
JnoLkfA118LAMcNUFl/zYdk0YSI8e44/lQ4A1M3k0u9BKsBMWHz2vBVASz3ni2+jiYdIxINs
AG1v55EFsjjCUCDQWc2+IFlSOkcW8Yhchn/QkZalbbaB8FSwlTyMrusMvH68+7UdP7/8wBdq
DjkaB3VLf6C0Ed/iCs7VnnG2uFxdm4bbovVybaAL39n+44lV3389/9mjBUa4+pWgy2fw+bC+
KXzta/VGnlqqb3XLu8/nJtanTGIaVDEF0MwUcQKR0J03kKrC43lzrCpbeKxNs7EGMSJiLsyF
exgX6+G8Dq/UgrXgUU7DNHw1u4rrt/eL3dIYskHYbN8sjkk7kO3YdnyPfY844dgh7cf244fs
h8Rv1R7DjuFvszP2GXEWm8VPV70nXsQv2T/CPsLvIQv4PSmH5KTPsc/xCEqQJMJSjGkFItoF
CbHai8zLChP4AOglctoJ5gyDMRCanOQEiSCqYLUIMOaCYE0yGjMLvhNMxmS/ie5CcHTXPCoh
WbRb41ATDRoFp1+wcsR9MmOFiWNyJsH46ZVINARHjXW2hqw3nTorb3VWWArgMcg8FV16sqyI
JLcIxABh+QWiEgUuPy4ujbeJB7k/Cs0lCy3z8TRUy0JFBCgeJOUXsKrigTJUAdY38JY8leFM
tNHU1CX3nB9YvU780TuWo5cPEyfyf/n60u2Iw2Bm5DHbgb094Y7NmNTbPPkd6EfdhSeEC2Rj
ED2gHTd18+gr6EY95kG9jCx41BgdCqfRNLOJ2uTaTe12HaIOud5FfkidYi4gF6nzzIX6m47r
6q+Yh9wX9BN2RUsYpSlEkChOIAQzx4u4nnQhIuVy1tKEXoIuxbUprVta97RirZOqgeMikt6i
LzmWHjCRqvotarbwV81pMyRVAeyDHWBV0KhwYFStubbJYBDRZ/EPNd6AALcl7/t8Iu2XQn69
pPo5LlN0Lw7P+P/HftnENBFEcfy/3VK2WNulRaGECkGJBAgIRTFCim4giEitpdFGQ0yFQmpa
KgIS8WI8meiBGC/iwYNGw9WPxBhNjCcPHI1XTTSRi8lI4ok09c3sFgFBDhBNzM7mN+/Nx85u
983re/Oy2VdcXeyrbi7YPS+sIsxCh5FcxOJ+Sm7arn4RPjql8vilW2d5ipPz2n6R/H7jjlqr
W+pX/jvab0Su5xUl9OaV5AtPPUUB9YVwDYmiGP3JB2p4N0kn786lPDySidOOsKunZbmNdRO3
0HFoeVATgazsrTNf2VbfO3LlbOZNiUtxbt/TWnnzcaDL23i99czVg/t7vaNlalWTyF8y0Qa3
PU8JT36UmuyZZMShFDp80ZLFdv+BvtnX2oAWbPOfkqbPV7r0NMUol7eAdzqWXYBco2O9vT55
jq3FNg/kv/8d++DmKZjTcRg4K1ai0nPczwDPB2DHzEqK6X7vlImJiYmJiYmJiYmJyf8JLJDE
ubIIMhdSKWHDhkVe0SqEpwg7dd23xuzGJl63rO4+imM4TjJ0MtxH4nR04+f+tWLFNapLodJP
LWAVrJ41Mj87xE6wCIuzYZZgF9lENguIsX1iLLg0lmLj2azr89qX8cXXK/Rps9//OEPBkLGG
jHKqJeONy+nSdRtpAb6S1U49AfQbugVO3DN0mfpnDd1K+ldDtyEgVWmhjs6ertpIIhUfC8Yn
w+lUbKROSycHu8djycTA5oahIYQOdKIHXahFBAmkEMcYglRPIow0tWMYQR3NTCOJQXRjnHqS
NHOAxuMYxgS1Yri0ybX+5d265eQ7WEAbLiCPrKOiAUfICh20s2Rqk2GkaRpRrKTxVk5iyOJ2
QFoqq7dIOxUcpr05ofBl5hRNHjN2iuXuzI29sYVzrrYfilcRsx+Uv3rI5ZOeT9Li/cwt+yNF
oybfO2LlnwIMABov+98KZW5kc3RyZWFtDWVuZG9iag0xMzQgMCBvYmoNPDwgDS9UeXBlIC9F
bmNvZGluZyANL0RpZmZlcmVuY2VzIFsgMSAvYnVsbGV0IC9zcGFjZSBdIA0+PiANZW5kb2Jq
DTEzNSAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDIxOCA+PiANc3Ry
ZWFtDQpIiVRQPW/EIAzd+RUer+oAYY5YrkuGfqhpuxNwIqTDIEKG/PsCR0/q4CfZz89+Nr9O
LxO5DPwjBTNjhtWRTbiHIxmEBTdHMEiwzuSeNTReR+BFPJ97Rj/RGmAcGf8s5J7TCZf59Eu4
PYsn4O/JYnK0weVr+P4phfmI8YYeKYMApcDiyvj1Vcc37bHQXdrqQ18YLO5RG0yaNoRRDKqA
VIBk/3NM3hXLek97awUppFSsyToIKRQrI/6a67R62sOMOVIqPtv9zWI15QgfL4ohVg812K8A
AwCK+Wx/CmVuZHN0cmVhbQ1lbmRvYmoNMTM2IDAgb2JqDTw8IA0vQ3JlYXRpb25EYXRlIChE
OjIwMDAwODAyMDAyNTAyKQ0vQ3JlYXRvciAoQWRvYmVQUzUuZGxsIFZlcnNpb24gNS4xLjEp
DS9UaXRsZSAoTWljcm9zb2Z0IFdvcmQgLSBtcGxzLWxkcC10ZXN0LWNhc2VzLmRvYykNL1By
b2R1Y2VyIChodHRwOi8vY3JlYXRlcGRmLmFkb2JlLmNvbSBWMy4wKQ0vTW9kRGF0ZSAoRDoy
MDAwMDgwMjAwMjUxOC0wNycwMCcpDT4+IA1lbmRvYmoNMTM3IDAgb2JqDTw8IA0vVHlwZSAv
UGFnZXMgDS9LaWRzIFsgMTQ1IDAgUiAxIDAgUiA0IDAgUiA3IDAgUiAxMCAwIFIgMTMgMCBS
IDE2IDAgUiAxOSAwIFIgMjIgMCBSIDI1IDAgUiANXSANL0NvdW50IDEwIA0vUGFyZW50IDEz
OCAwIFIgDT4+IA1lbmRvYmoNMTM4IDAgb2JqDTw8IA0vVHlwZSAvUGFnZXMgDS9LaWRzIFsg
MTM3IDAgUiAxMzkgMCBSIDE0MCAwIFIgMTQxIDAgUiAxNDIgMCBSIF0gDS9Db3VudCA0MiAN
Pj4gDWVuZG9iag0xMzkgMCBvYmoNPDwgDS9UeXBlIC9QYWdlcyANL0tpZHMgWyAyOCAwIFIg
MzEgMCBSIDM0IDAgUiAzNyAwIFIgNDAgMCBSIDQzIDAgUiA0NiAwIFIgNDkgMCBSIDUyIDAg
UiA1NSAwIFIgDV0gDS9Db3VudCAxMCANL1BhcmVudCAxMzggMCBSIA0+PiANZW5kb2JqDTE0
MCAwIG9iag08PCANL1R5cGUgL1BhZ2VzIA0vS2lkcyBbIDU4IDAgUiA2MSAwIFIgNjQgMCBS
IDY3IDAgUiA3MCAwIFIgNzMgMCBSIDc2IDAgUiA3OSAwIFIgODIgMCBSIDg1IDAgUiANXSAN
L0NvdW50IDEwIA0vUGFyZW50IDEzOCAwIFIgDT4+IA1lbmRvYmoNMTQxIDAgb2JqDTw8IA0v
VHlwZSAvUGFnZXMgDS9LaWRzIFsgODggMCBSIDkxIDAgUiA5NCAwIFIgOTcgMCBSIDEwMCAw
IFIgMTAzIDAgUiAxMDYgMCBSIDEwOSAwIFIgMTEyIDAgUiANMTE1IDAgUiBdIA0vQ291bnQg
MTAgDS9QYXJlbnQgMTM4IDAgUiANPj4gDWVuZG9iag0xNDIgMCBvYmoNPDwgDS9UeXBlIC9Q
YWdlcyANL0tpZHMgWyAxMTggMCBSIDEyMSAwIFIgXSANL0NvdW50IDIgDS9QYXJlbnQgMTM4
IDAgUiANPj4gDWVuZG9iag14cmVmDTAgMTQzIA0wMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAw
Nzc5OTcgMDAwMDAgbg0KMDAwMDA3ODE0OSAwMDAwMCBuDQowMDAwMDc4Mjk5IDAwMDAwIG4N
CjAwMDAwODIwMjcgMDAwMDAgbg0KMDAwMDA4MjE3OSAwMDAwMCBuDQowMDAwMDgyMzgzIDAw
MDAwIG4NCjAwMDAwOTQwMTggMDAwMDAgbg0KMDAwMDA5NDE3MCAwMDAwMCBuDQowMDAwMDk0
MzM0IDAwMDAwIG4NCjAwMDAwOTg4MzggMDAwMDAgbg0KMDAwMDA5ODk5MyAwMDAwMCBuDQow
MDAwMDk5MTU4IDAwMDAwIG4NCjAwMDAxMDI0NjYgMDAwMDAgbg0KMDAwMDEwMjYyMSAwMDAw
MCBuDQowMDAwMTAyNzg2IDAwMDAwIG4NCjAwMDAxMDQ1ODMgMDAwMDAgbg0KMDAwMDEwNDcz
OCAwMDAwMCBuDQowMDAwMTA0OTAzIDAwMDAwIG4NCjAwMDAxMDY2ODQgMDAwMDAgbg0KMDAw
MDEwNjgzOSAwMDAwMCBuDQowMDAwMTA3MDA0IDAwMDAwIG4NCjAwMDAxMDg3NzYgMDAwMDAg
bg0KMDAwMDEwODkzMSAwMDAwMCBuDQowMDAwMTA5MTEwIDAwMDAwIG4NCjAwMDAxMTIwMjYg
MDAwMDAgbg0KMDAwMDExMjE4MSAwMDAwMCBuDQowMDAwMTEyMzQ2IDAwMDAwIG4NCjAwMDAx
MTU0ODEgMDAwMDAgbg0KMDAwMDExNTYzNiAwMDAwMCBuDQowMDAwMTE1ODE1IDAwMDAwIG4N
CjAwMDAxMjAyNDMgMDAwMDAgbg0KMDAwMDEyMDM5OCAwMDAwMCBuDQowMDAwMTIwNTQ5IDAw
MDAwIG4NCjAwMDAxMjM0MjMgMDAwMDAgbg0KMDAwMDEyMzU3OCAwMDAwMCBuDQowMDAwMTIz
NzU3IDAwMDAwIG4NCjAwMDAxMjg2OTMgMDAwMDAgbg0KMDAwMDEyODg0OCAwMDAwMCBuDQow
MDAwMTI4OTk5IDAwMDAwIG4NCjAwMDAxMzMyNTYgMDAwMDAgbg0KMDAwMDEzMzQxMSAwMDAw
MCBuDQowMDAwMTMzNTYyIDAwMDAwIG4NCjAwMDAxMzY3MTMgMDAwMDAgbg0KMDAwMDEzNjg2
OCAwMDAwMCBuDQowMDAwMTM3MDMzIDAwMDAwIG4NCjAwMDAxMzk4NjIgMDAwMDAgbg0KMDAw
MDE0MDAxNyAwMDAwMCBuDQowMDAwMTQwMTgyIDAwMDAwIG4NCjAwMDAxNDM0MDQgMDAwMDAg
bg0KMDAwMDE0MzU1OSAwMDAwMCBuDQowMDAwMTQzNzI0IDAwMDAwIG4NCjAwMDAxNDgwMzMg
MDAwMDAgbg0KMDAwMDE0ODE4OCAwMDAwMCBuDQowMDAwMTQ4MzUzIDAwMDAwIG4NCjAwMDAx
NTA5NDcgMDAwMDAgbg0KMDAwMDE1MTEwMiAwMDAwMCBuDQowMDAwMTUxMjUzIDAwMDAwIG4N
CjAwMDAxNTY3MTAgMDAwMDAgbg0KMDAwMDE1Njg2NSAwMDAwMCBuDQowMDAwMTU3MDE2IDAw
MDAwIG4NCjAwMDAxNjIxMTEgMDAwMDAgbg0KMDAwMDE2MjI2NiAwMDAwMCBuDQowMDAwMTYy
NDE3IDAwMDAwIG4NCjAwMDAxNjY5MzcgMDAwMDAgbg0KMDAwMDE2NzA5MiAwMDAwMCBuDQow
MDAwMTY3MjQzIDAwMDAwIG4NCjAwMDAxNjk5OTUgMDAwMDAgbg0KMDAwMDE3MDE1MCAwMDAw
MCBuDQowMDAwMTcwMzE1IDAwMDAwIG4NCjAwMDAxNzQ4MTYgMDAwMDAgbg0KMDAwMDE3NDk3
MSAwMDAwMCBuDQowMDAwMTc1MTM2IDAwMDAwIG4NCjAwMDAxNzg5NzcgMDAwMDAgbg0KMDAw
MDE3OTEzMiAwMDAwMCBuDQowMDAwMTc5Mjk3IDAwMDAwIG4NCjAwMDAxODM2MzQgMDAwMDAg
bg0KMDAwMDE4Mzc4OSAwMDAwMCBuDQowMDAwMTgzOTQwIDAwMDAwIG4NCjAwMDAxODc4NTQg
MDAwMDAgbg0KMDAwMDE4ODAwOSAwMDAwMCBuDQowMDAwMTg4MTYwIDAwMDAwIG4NCjAwMDAx
OTI3NTIgMDAwMDAgbg0KMDAwMDE5MjkwNyAwMDAwMCBuDQowMDAwMTkzMDU4IDAwMDAwIG4N
CjAwMDAxOTc0NDYgMDAwMDAgbg0KMDAwMDE5NzYwMSAwMDAwMCBuDQowMDAwMTk3NzUyIDAw
MDAwIG4NCjAwMDAyMDIzNDkgMDAwMDAgbg0KMDAwMDIwMjUwNCAwMDAwMCBuDQowMDAwMjAy
NjY4IDAwMDAwIG4NCjAwMDAyMDQ4MTQgMDAwMDAgbg0KMDAwMDIwNDk2OSAwMDAwMCBuDQow
MDAwMjA1MTM0IDAwMDAwIG4NCjAwMDAyMDgyODAgMDAwMDAgbg0KMDAwMDIwODQzNSAwMDAw
MCBuDQowMDAwMjA4NjAwIDAwMDAwIG4NCjAwMDAyMTI2MjUgMDAwMDAgbg0KMDAwMDIxMjc4
MCAwMDAwMCBuDQowMDAwMjEyOTMxIDAwMDAwIG4NCjAwMDAyMTczMTUgMDAwMDAgbg0KMDAw
MDIxNzQ3MyAwMDAwMCBuDQowMDAwMjE3NjI1IDAwMDAwIG4NCjAwMDAyMjAwNjAgMDAwMDAg
bg0KMDAwMDIyMDIxOCAwMDAwMCBuDQowMDAwMjIwMzg0IDAwMDAwIG4NCjAwMDAyMjQzNjgg
MDAwMDAgbg0KMDAwMDIyNDUyNiAwMDAwMCBuDQowMDAwMjI0NjkyIDAwMDAwIG4NCjAwMDAy
Mjg3NDAgMDAwMDAgbg0KMDAwMDIyODg5OCAwMDAwMCBuDQowMDAwMjI5MDUwIDAwMDAwIG4N
CjAwMDAyMzE1MDQgMDAwMDAgbg0KMDAwMDIzMTY2MiAwMDAwMCBuDQowMDAwMjMxODI4IDAw
MDAwIG4NCjAwMDAyMzU3NDMgMDAwMDAgbg0KMDAwMDIzNTkwMSAwMDAwMCBuDQowMDAwMjM2
MDY3IDAwMDAwIG4NCjAwMDAyNDAxMzcgMDAwMDAgbg0KMDAwMDI0MDI5NSAwMDAwMCBuDQow
MDAwMjQwNDQ3IDAwMDAwIG4NCjAwMDAyNDEyNzQgMDAwMDAgbg0KMDAwMDI0MTQzMiAwMDAw
MCBuDQowMDAwMjQxNTk3IDAwMDAwIG4NCjAwMDAyNDMwNjkgMDAwMDAgbg0KMDAwMDI0MzYz
NiAwMDAwMCBuDQowMDAwMjQzNzQ5IDAwMDAwIG4NCjAwMDAyNDQyODAgMDAwMDAgbg0KMDAw
MDI0NDY2MSAwMDAwMCBuDQowMDAwMjQ0ODc1IDAwMDAwIG4NCjAwMDAyNzk3MDAgMDAwMDAg
bg0KMDAwMDI3OTkyNCAwMDAwMCBuDQowMDAwMzA1MTk2IDAwMDAwIG4NCjAwMDAzMDU0MjYg
MDAwMDAgbg0KMDAwMDMxNzMzNiAwMDAwMCBuDQowMDAwMzE3NDEzIDAwMDAwIG4NCjAwMDAz
MTc3MDYgMDAwMDAgbg0KMDAwMDMxNzkzMSAwMDAwMCBuDQowMDAwMzE4MDc4IDAwMDAwIG4N
CjAwMDAzMTgxNzkgMDAwMDAgbg0KMDAwMDMxODMyOCAwMDAwMCBuDQowMDAwMzE4NDc3IDAw
MDAwIG4NCjAwMDAzMTg2MzIgMDAwMDAgbg0KdHJhaWxlcg08PA0vU2l6ZSAxNDMNL0lEWzxi
NTE0ZTQxOTM3NjcwMGZmMTQ2NTBiZTYzZWFkYTA4Nj48YjUxNGU0MTkzNzY3MDBmZjE0NjUw
YmU2M2VhZGEwODY+XQ0+Pg1zdGFydHhyZWYNMTczDSUlRU9GDQ==

--openmail-part-1a2daa78-00000001--



From owner-mpls@UU.NET  Thu Aug  3 05:42:48 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07448
	for <mpls-archive@lists.ietf.org>; Thu, 3 Aug 2000 05:42:48 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjapy07672;
	Thu, 3 Aug 2000 09:42:04 GMT
Received: by mail-control.mail.uu.net 
	id QQjapy25411
	for mpls-outgoing; Thu, 3 Aug 2000 09:41:40 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjapy25403
	for <mpls@mail-control.mail.uu.net>; Thu, 3 Aug 2000 09:41:37 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjapy20383
	for <mpls@UU.NET>; Thu, 3 Aug 2000 05:41:35 -0400 (EDT)
Received: from daewoo.dti.daewoo.co.kr by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [165.133.13.60])
	id QQjapy16657
	for <mpls@UU.NET>; Thu, 3 Aug 2000 09:41:31 GMT
Received: from santosh (santosh [165.133.13.16])
	by daewoo.dti.daewoo.co.kr (8.8.8+Sun/8.8.8) with SMTP id PAA08740
	for <mpls@UU.NET>; Thu, 3 Aug 2000 15:06:03 -0600 (GMT)
Message-ID: <00be01bffd2e$f13887c0$100d85a5@dti.daewoo.co.kr>
Reply-To: "Santosh Gupta" <santoshg@daewoo.dti.daewoo.co.kr>
From: "Santosh Gupta" <santoshg@daewoo.dti.daewoo.co.kr>
To: <mpls@UU.NET>
Subject: Routing policy
Date: Thu, 3 Aug 2000 15:11:02 +0530
Organization: Daewoo Telecom
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_00BB_01BFFD5D.09BB02E0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_00BB_01BFFD5D.09BB02E0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello
    I have some questions to ask regarding routing policy in MPLS =
domain.
  1.. If some data is received at Ingress LER and there is no LSP =
present for it then what should be done? Should it be discarded or =
should it be passed onto all peers on the default peer channel(control =
channel ) or should it be routed?=20
  2.. What should be done in case this happens at core router( an LSR) ? =

  3.. If we have remote peer session in the MPLS domain ( say in LDP) =
then which channel should be used by the switch to establish a TCP =
connection with the ADJACENT peer so that finally the session ends at =
the remote peer ? Should it be the default channel or an already =
existing LSP formed between the 2 remote peers.=20
Thanx in advance.

santosh


------=_NextPart_000_00BB_01BFFD5D.09BB02E0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hello</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; I have some =
questions to ask=20
regarding routing policy in MPLS domain.</FONT></DIV>
<OL>
  <LI><FONT face=3DArial size=3D2>If some data is received at Ingress =
LER and there=20
  is no LSP present for it then what should be done? Should it be =
discarded or=20
  should it be passed onto all peers on the default peer channel(control =
channel=20
  ) or should it be routed?&nbsp;</FONT></LI>
  <LI><FONT face=3DArial size=3D2>What&nbsp;should be done in case this =
happens at=20
  core router(&nbsp;an LSR) ?&nbsp;</FONT></LI>
  <LI><FONT face=3DArial size=3D2>If we have remote peer session in the =
MPLS domain=20
  ( say in&nbsp;LDP) then which channel should be used by the switch to=20
  establish a TCP connection with the ADJACENT peer so that finally the =
session=20
  ends at the remote peer ? Should it be the default channel or an =
already=20
  existing LSP formed between the 2 remote peers. </FONT></LI></OL>
<DIV><FONT face=3DArial size=3D2>Thanx in advance.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>santosh</FONT></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_00BB_01BFFD5D.09BB02E0--



From owner-mpls@UU.NET  Thu Aug  3 08:28:24 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13081
	for <mpls-archive@lists.ietf.org>; Thu, 3 Aug 2000 08:28:23 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjaqj14513;
	Thu, 3 Aug 2000 12:27:36 GMT
Received: by mail-control.mail.uu.net 
	id QQjaqj15200
	for mpls-outgoing; Thu, 3 Aug 2000 12:27:20 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjaqj15195
	for <mpls@mail-control.mail.uu.net>; Thu, 3 Aug 2000 12:27:11 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjaqj00863
	for <mpls@uu.net>; Thu, 3 Aug 2000 08:27:08 -0400 (EDT)
Received: from prue.eim.surrey.ac.uk by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: prue.eim.surrey.ac.uk [131.227.76.5])
	id QQjaqj13820
	for <mpls@uu.net>; Thu, 3 Aug 2000 12:26:52 GMT
Received: from petra.ee.surrey.ac.uk ([131.227.88.13] ident=eep1lw)
	by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1)
	id 13KK5H-0002bR-00; Thu, 03 Aug 2000 13:26:47 +0100
Date: Thu, 3 Aug 2000 13:26:44 +0100 (BST)
From: Lloyd Wood <l.wood@eim.surrey.ac.uk>
X-Sender: eep1lw@petra.ee.surrey.ac.uk
Reply-To: L.Wood@eim.surrey.ac.uk
To: seenu@samsung.co.kr
cc: mpls@UU.NET
Subject: Re: MPLS-LDP TEST CASES
In-Reply-To: <H0000e65019b03a1.0965291717.secsw0@MHS>
Message-ID: <Pine.GSO.4.21.0008031325460.7966-100000@petra.ee.surrey.ac.uk>
Organization: speaking for none
X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/
X-no-archive: yes
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

On Thu, 3 Aug 2000 seenu@samsung.co.kr wrote:

> MPLS-LDP Test cases are available on the net.
> Whoever wants, can access it at :
> 
> MS word doc :     www.geocities.com/smilybits/mpls-ldp-test-cases.doc
> 
> PDF format    :   www.geocities.com/smilybits/mpls-ldp-test-cases.pdf
> 
> OR  find the attached .pdf file.

Since you're telling us where to get it from, I don't see why you have
to spam every subscriber of the list with a 450K attachment. Sheesh.

L.

<L.Wood@surrey.ac.uk>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>




From owner-mpls@UU.NET  Thu Aug  3 10:54:57 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00812
	for <mpls-archive@lists.ietf.org>; Thu, 3 Aug 2000 10:54:56 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjaqt28153;
	Thu, 3 Aug 2000 14:54:17 GMT
Received: by mail-control.mail.uu.net 
	id QQjaqt18673
	for mpls-outgoing; Thu, 3 Aug 2000 14:53:40 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjaqt18656
	for <mpls@mail-control.mail.uu.net>; Thu, 3 Aug 2000 14:53:33 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjaqt25349
	for <mpls@uu.net>; Thu, 3 Aug 2000 10:53:26 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQjaqt00271
	for <mpls@uu.net>; Thu, 3 Aug 2000 14:53:10 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA18452
	for <mpls@uu.net>; Thu, 3 Aug 2000 10:53:07 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA05276
	for <mpls@uu.net>; Thu, 3 Aug 2000 10:53:08 -0400 (EDT)
Message-ID: <39897F0B.60AC4BF4@marconi.com>
Date: Thu, 03 Aug 2000 10:17:47 -0400
From: David Charlap <david.charlap@marconi.com>
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: Comments on draft-mpls-rsvp-lsp-tunnel-06.txt
References: <6DEA508A9A0ED31192E80000F6CC176E2C9D98@monk.datcon.co.uk> <3988BC9A.F3587F4B@americasm01.nt.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Philip Matthews wrote:
> 
> Thanks for the information.
> I guess the answer is that an implementation SHOULD make an effort to
> handle such cases, and not just reject the change with a PathErr or
> ResvErr.

IMO, if the hardware (or its operating system) is capable of changing
the egress label for an established tunnel, it should attempt to do so.

If the hardware can't do this, or if the attempt fails, then you must
report this fact to the ingress node so that it can take appropriate
action (probably involving tearing down the tunnel and reestablishing
it).  This report would be in the form of a PathErr message.  A ResvErr
message to the egress node might also be useful, but I don't think it
will be necessary.

-- David



From owner-mpls@UU.NET  Thu Aug  3 11:29:54 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16079
	for <mpls-archive@lists.ietf.org>; Thu, 3 Aug 2000 11:29:53 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjaqv14873;
	Thu, 3 Aug 2000 15:29:19 GMT
Received: by mail-control.mail.uu.net 
	id QQjaqv03243
	for mpls-outgoing; Thu, 3 Aug 2000 15:28:47 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjaqv03238
	for <mpls@mail-control.mail.uu.net>; Thu, 3 Aug 2000 15:28:46 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjaqv07808
	for <mpls@uu.net>; Thu, 3 Aug 2000 11:28:28 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjaqv23722
	for <mpls@uu.net>; Thu, 3 Aug 2000 15:28:27 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA29083
	for mpls@uu.net; Thu, 3 Aug 2000 11:28:27 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjaqv03213
	for <mpls@mail-control.mail.uu.net>; Thu, 3 Aug 2000 15:28:04 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjaqv07720
	for <mpls@uu.net>; Thu, 3 Aug 2000 11:27:55 -0400 (EDT)
Received: from sj-msg-core-crit.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-crit.cisco.com [171.71.163.10])
	id QQjaqv14171
	for <mpls@uu.net>; Thu, 3 Aug 2000 15:27:40 GMT
Received: from ORANLT (ssh.cisco.com [171.69.10.34])
	by sj-msg-core-crit.cisco.com (8.9.3/8.9.1) with SMTP id IAA18271;
	Thu, 3 Aug 2000 08:27:37 -0700 (PDT)
From: "David R. Oran" <oran@cisco.com>
To: <mpls@UU.NET>
Cc: "IESG" <iesg@ietf.org>, "IAB" <iab@isi.edu>
Subject: Use of the term "end-to-end"
Date: Thu, 3 Aug 2000 11:28:25 -0400
Message-ID: <NDBBKHCGKKIOOIJEGCOEMEHFDMAA.oran@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
Importance: Normal
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

I've observed in the MPLS meeting and on the mailing list that the words
"end-to-end" are frequently used with respect to various MPLS features and
mechanisms.

I would now like to ovserve that this usage is in conflict with the
conventional use of this term over many years in the Internet communty in
general, and the IETF in particular.

This leads to a number of misconceptions and a number of proposals that
attempt to apply MPLS as an "end-to-end" service or mechanism, which is not
IMHO appropriate.

Therefore I would like to plead that the MPLS comunity use the terms
"single-hop" and "LSP-endpoint-to-endpoint" as opposed to "hop-by-hop" and
"end-to-end" in drafts and RFCs on things like compression, VoIPoMPLS, etc.

Putting my lead BVDs on....

Dave.




From owner-mpls@UU.NET  Thu Aug  3 11:41:01 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20726
	for <mpls-archive@lists.ietf.org>; Thu, 3 Aug 2000 11:41:01 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjaqw03315;
	Thu, 3 Aug 2000 15:40:38 GMT
Received: by mail-control.mail.uu.net 
	id QQjaqw03912
	for mpls-outgoing; Thu, 3 Aug 2000 15:40:07 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjaqw03905
	for <mpls@mail-control.mail.uu.net>; Thu, 3 Aug 2000 15:40:05 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjaqw03843
	for <mpls@uu.net>; Thu, 3 Aug 2000 11:39:46 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjaqw02263
	for <mpls@uu.net>; Thu, 3 Aug 2000 15:39:30 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA01343
	for mpls@uu.net; Thu, 3 Aug 2000 11:39:30 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjaqw03842
	for <mpls@mail-control.mail.uu.net>; Thu, 3 Aug 2000 15:38:46 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjaqw03605
	for <mpls@UU.NET>; Thu, 3 Aug 2000 11:38:34 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11])
	id QQjaqw01493
	for <mpls@UU.NET>; Thu, 3 Aug 2000 15:38:33 GMT
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA20203;
	Thu, 3 Aug 2000 08:37:46 -0700 (PDT)
Received: from sbrim-nt.cisco.com ([10.82.192.1])
	by airborne.cisco.com (Mirapoint)
	with ESMTP id AAY34113;
	Thu, 3 Aug 2000 08:37:27 -0700 (PDT)
Message-Id: <4.3.2.7.2.20000803113712.00b59860@airborne.cisco.com>
X-Sender: sbrim@airborne.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 03 Aug 2000 11:37:27 -0400
To: "David R. Oran" <oran@cisco.com>
From: Scott Brim <sbrim@cisco.com>
Subject: Re: Use of the term "end-to-end"
Cc: <mpls@UU.NET>, "IESG" <iesg@ietf.org>, "IAB" <iab@isi.edu>
In-Reply-To: <NDBBKHCGKKIOOIJEGCOEMEHFDMAA.oran@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

LER-to-LER

At 11:28 AM 08/03/2000 -0400, David R. Oran wrote:
>I've observed in the MPLS meeting and on the mailing list that the words
>"end-to-end" are frequently used with respect to various MPLS features and
>mechanisms.
>
>I would now like to ovserve that this usage is in conflict with the
>conventional use of this term over many years in the Internet communty in
>general, and the IETF in particular.
>
>This leads to a number of misconceptions and a number of proposals that
>attempt to apply MPLS as an "end-to-end" service or mechanism, which is not
>IMHO appropriate.
>
>Therefore I would like to plead that the MPLS comunity use the terms
>"single-hop" and "LSP-endpoint-to-endpoint" as opposed to "hop-by-hop" and
>"end-to-end" in drafts and RFCs on things like compression, VoIPoMPLS, etc.
>
>Putting my lead BVDs on....
>
>Dave.




From owner-mpls@UU.NET  Thu Aug  3 13:56:09 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11313
	for <mpls-archive@lists.ietf.org>; Thu, 3 Aug 2000 13:56:08 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjarf08467;
	Thu, 3 Aug 2000 17:55:20 GMT
Received: by mail-control.mail.uu.net 
	id QQjarf05836
	for mpls-outgoing; Thu, 3 Aug 2000 17:54:47 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjarf05831
	for <mpls@mail-control.mail.uu.net>; Thu, 3 Aug 2000 17:54:32 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjarf01731
	for <mpls@UU.NET>; Thu, 3 Aug 2000 13:54:18 -0400 (EDT)
Received: from crufty.research.bell-labs.com by wodc7mr2.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: crufty.research.bell-labs.com [204.178.16.49])
	id QQjarf07514
	for <mpls@UU.NET>; Thu, 3 Aug 2000 17:54:03 GMT
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Thu Aug  3 13:52:04 EDT 2000
Received: from dnrc.bell-labs.com (ex-vpn65.pa.bell-labs.com [135.250.1.65])
	by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id NAA27881;
	Thu, 3 Aug 2000 13:53:03 -0400 (EDT)
Message-ID: <3989B253.DCC3A2D6@dnrc.bell-labs.com>
Date: Thu, 03 Aug 2000 10:56:35 -0700
From: Grenville Armitage <gja@dnrc.bell-labs.com>
Organization: Bell Labs Research Silicon Valley
X-Mailer: Mozilla 4.61 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "David R. Oran" <oran@cisco.com>
CC: mpls@UU.NET, IESG <iesg@ietf.org>, IAB <iab@isi.edu>
Subject: Re: Use of the term "end-to-end"
References: <NDBBKHCGKKIOOIJEGCOEMEHFDMAA.oran@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit



"David R. Oran" wrote:
	[..]
> Therefore I would like to plead that the MPLS comunity use the terms
> "single-hop" and "LSP-endpoint-to-endpoint" as opposed to "hop-by-hop" and
> "end-to-end" in drafts and RFCs on things like compression, VoIPoMPLS, etc.

"edge to edge"

cheers,
gja


From owner-mpls@UU.NET  Thu Aug  3 13:59:42 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12996
	for <mpls-archive@lists.ietf.org>; Thu, 3 Aug 2000 13:59:41 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjarf14075;
	Thu, 3 Aug 2000 17:59:03 GMT
Received: by mail-control.mail.uu.net 
	id QQjarf06079
	for mpls-outgoing; Thu, 3 Aug 2000 17:58:31 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjarf06071
	for <mpls@mail-control.mail.uu.net>; Thu, 3 Aug 2000 17:58:21 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjarf27779
	for <mpls@UU.NET>; Thu, 3 Aug 2000 13:58:17 -0400 (EDT)
Received: from griffin.host4u.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: griffin.host4u.net [209.150.128.163])
	id QQjarf10892
	for <mpls@UU.NET>; Thu, 3 Aug 2000 17:58:17 GMT
Received: from nfloat.labn.net (labn.net [209.204.240.82])
	by griffin.host4u.net (8.8.5/8.8.5) with ESMTP id MAA26928;
	Thu, 3 Aug 2000 12:58:07 -0500
Message-Id: <4.3.2.7.2.20000803134804.00cb6370@mail.labn.net>
X-Sender: lberger@mail.labn.net
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 03 Aug 2000 13:58:02 -0400
To: Francois Le Faucheur <flefauch@cisco.com>
From: Lou Berger <lberger@labn.net>
Subject: RE: Two last calls (draft-ietf-mpls-diff-ext-06.txt)
Cc: Lou Berger <lberger@labn.net>, mpls@UU.NET,
        Francois Le Faucheur <flefauch@cisco.com>
In-Reply-To: <200008022339.BAA25146@europe.cisco.com>
References: <4.3.2.7.2.20000802153638.02dff6b0@mail.labn.net>
 <200008021908.VAA19297@europe.cisco.com>
 <4.3.2.7.2.20000801225758.00def3d0@mail.labn.net>
 <4.0.2.20000801113940.02298700@europe.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

Francois,

Looks good, but I have one suggestion listed below.

Thanks,
Lou

At 07:33 PM 8/2/00 +0200, Francois Le Faucheur wrote:
>[...]
>
>
>           - after the current 6th paragraph, add the following paragraphs:
>"If a DIFFSERV object is not present in the Path message, the LSR SHOULD
>interpret this as a request for an E-LSP using the Preconfigured EXP<-->PHB
>Mapping. However, for backward compatibility purposes with non-Diff-Serv

I suggest dropping the word "backward".

>Quality of Service options allowed by [RSVP_MPLS_TE] such as Integrated
>Services Controlled Load or Guaranteed Services, the LSR MAY support a
>configurable "override option". When this "override option" is configured, the
>LSR interprets a path message without a Diff-Serv object as a request for an
>LSP with such non-Diff-Serv Quality of Service.
>
>[...]

Thanks again,

Lou



From owner-mpls@UU.NET  Thu Aug  3 14:01:37 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14018
	for <mpls-archive@lists.ietf.org>; Thu, 3 Aug 2000 14:01:36 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjarg13358;
	Thu, 3 Aug 2000 18:01:11 GMT
Received: by mail-control.mail.uu.net 
	id QQjarg08807
	for mpls-outgoing; Thu, 3 Aug 2000 18:00:33 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjarg07858
	for <mpls@mail-control.mail.uu.net>; Thu, 3 Aug 2000 18:00:19 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjarg28222
	for <mpls@uu.net>; Thu, 3 Aug 2000 14:00:06 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88])
	id QQjarf14739
	for <mpls@uu.net>; Thu, 3 Aug 2000 17:59:50 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id LAA17265
	for <mpls@uu.net>; Thu, 3 Aug 2000 11:00:06 -0700 (PDT)
Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id NAA19603 for mpls@uu.net; Thu, 3 Aug 2000 13:59:48 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjard03742
	for <mpls@mail-control.mail.uu.net>; Thu, 3 Aug 2000 17:17:18 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjard25762
	for <mpls@uu.net>; Thu, 3 Aug 2000 13:17:07 -0400 (EDT)
Received: from mail-gw.hursley.ibm.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-gw.hursley.ibm.com [194.196.110.15])
	id QQjard10360
	for <mpls@uu.net>; Thu, 3 Aug 2000 17:16:47 GMT
Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id SAA167196; Thu, 3 Aug 2000 18:14:46 +0100
Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id SAA18730; Thu, 3 Aug 2000 18:15:31 +0100 (BST)
Message-ID: <3989A81A.300E3222@hursley.ibm.com>
Date: Thu, 03 Aug 2000 12:12:58 -0500
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en,fr
MIME-Version: 1.0
To: "David R. Oran" <oran@cisco.com>
CC: mpls@UU.NET, IESG <iesg@ietf.org>, IAB <iab@ISI.EDU>
Subject: Re: Use of the term "end-to-end"
References: <NDBBKHCGKKIOOIJEGCOEMEHFDMAA.oran@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

I'll observe that we went through a similar debate in diffserv and ended
up speaking, at least colloquially, of "edge-to-edge" to identify things
that happen between two edges of a diffserv domain, as opposed to between
two hosts.

  Brian

"David R. Oran" wrote:
> 
> I've observed in the MPLS meeting and on the mailing list that the words
> "end-to-end" are frequently used with respect to various MPLS features and
> mechanisms.
> 
> I would now like to ovserve that this usage is in conflict with the
> conventional use of this term over many years in the Internet communty in
> general, and the IETF in particular.
> 
> This leads to a number of misconceptions and a number of proposals that
> attempt to apply MPLS as an "end-to-end" service or mechanism, which is not
> IMHO appropriate.
> 
> Therefore I would like to plead that the MPLS comunity use the terms
> "single-hop" and "LSP-endpoint-to-endpoint" as opposed to "hop-by-hop" and
> "end-to-end" in drafts and RFCs on things like compression, VoIPoMPLS, etc.
> 
> Putting my lead BVDs on....
> 
> Dave.



From owner-mpls@UU.NET  Thu Aug  3 15:12:44 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04131
	for <mpls-archive@lists.ietf.org>; Thu, 3 Aug 2000 15:12:44 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjark08527;
	Thu, 3 Aug 2000 19:12:07 GMT
Received: by mail-control.mail.uu.net 
	id QQjark03330
	for mpls-outgoing; Thu, 3 Aug 2000 19:11:36 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjark03322
	for <mpls@mail-control.mail.uu.net>; Thu, 3 Aug 2000 19:11:29 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjark17040
	for <mpls@uu.net>; Thu, 3 Aug 2000 15:11:15 -0400 (EDT)
Received: from web5403.mail.yahoo.com by wodc7mr1.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: web5403.mail.yahoo.com [216.115.106.141])
	id QQjark15458
	for <mpls@uu.net>; Thu, 3 Aug 2000 19:11:15 GMT
Message-ID: <20000803191114.3390.qmail@web5403.mail.yahoo.com>
Received: from [132.177.119.129] by web5403.mail.yahoo.com; Thu, 03 Aug 2000 12:11:14 PDT
Date: Thu, 3 Aug 2000 12:11:14 -0700 (PDT)
From: John Sparr <johnrdb@yahoo.com>
Subject: What will ingress node do?
To: mpls@UU.NET
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

If a LSP setup failed because ingress node received a
PathErr message, When the ingress node received a
PathErr (like "Routing Problem"), what will the
ingress node do? send a path teardown request message?
or what?


Thanks in advance
John

__________________________________________________
Do You Yahoo!?
Kick off your party with Yahoo! Invites.
http://invites.yahoo.com/


From owner-mpls@UU.NET  Thu Aug  3 15:18:48 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05984
	for <mpls-archive@lists.ietf.org>; Thu, 3 Aug 2000 15:18:48 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjarl13238;
	Thu, 3 Aug 2000 19:18:17 GMT
Received: by mail-control.mail.uu.net 
	id QQjarl04085
	for mpls-outgoing; Thu, 3 Aug 2000 19:17:41 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjarl04075
	for <mpls@mail-control.mail.uu.net>; Thu, 3 Aug 2000 19:17:38 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjarl13725
	for <mpls@uu.net>; Thu, 3 Aug 2000 15:17:32 -0400 (EDT)
Received: from web5401.mail.yahoo.com by wodc7mr2.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: web5401.mail.yahoo.com [216.115.106.132])
	id QQjarl12656
	for <mpls@uu.net>; Thu, 3 Aug 2000 19:17:31 GMT
Message-ID: <20000803191731.22064.qmail@web5401.mail.yahoo.com>
Received: from [132.177.119.129] by web5401.mail.yahoo.com; Thu, 03 Aug 2000 12:17:31 PDT
Date: Thu, 3 Aug 2000 12:17:31 -0700 (PDT)
From: John Sparr <johnrdb@yahoo.com>
Subject: what will ingress node do?
To: mpls@UU.NET
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk


Sorry,  this question is from RSVP-TE draft(06).

Hi,

If a LSP setup failed because ingress node received a
PathErr message, When the ingress node received a
PathErr (like "Routing Problem"), what will the
ingress node do? send a path teardown request message?
or what?


Thanks in advance
John

__________________________________________________
Do You Yahoo!?
Kick off your party with Yahoo! Invites.
http://invites.yahoo.com/


From owner-mpls@UU.NET  Thu Aug  3 16:09:24 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22758
	for <mpls-archive@lists.ietf.org>; Thu, 3 Aug 2000 16:09:24 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjaro09946;
	Thu, 3 Aug 2000 20:08:19 GMT
Received: by mail-control.mail.uu.net 
	id QQjaro18802
	for mpls-outgoing; Thu, 3 Aug 2000 20:07:41 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjaro18764
	for <mpls@mail-control.mail.uu.net>; Thu, 3 Aug 2000 20:07:27 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjaro26937
	for <mpls@UU.NET>; Thu, 3 Aug 2000 16:07:16 -0400 (EDT)
Received: from mason2.gmu.edu by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mason2.gmu.edu [129.174.1.11])
	id QQjaro18336
	for <mpls@UU.NET>; Thu, 3 Aug 2000 20:07:00 GMT
Received: from localhost (rpapneja@localhost)
	by mason2.gmu.edu (8.8.8/8.8.8) with ESMTP id QAA12201;
	Thu, 3 Aug 2000 16:07:00 -0400 (EDT)
Date: Thu, 3 Aug 2000 16:07:00 -0400 (EDT)
From: Rajiv Papneja <rpapneja@osf1.gmu.edu>
X-Sender: rpapneja@mason2.gmu.edu
To: mpls@UU.NET
Subject: MPLS2000 Invitation 
Message-ID: <Pine.OSF.4.21.0008031519190.23001-100000@mason2.gmu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk


Friends,

        On behalf of Prof. Bijan Jabbari and Daniel Awduche, we wish to
invite you to attend the 3rd Annual International Conference on MPLS,
being held on the pastoral Fairfax, Virginia, campus of George Mason
University October 22-24, 2000.  The theme of this year's conference is
"From MPLS to MPLambdaS."  Conference information, detailed technical
program, hotel and travel information, and registration information can
be found at:

        http://www.ail.gmu.edu/MPLS2000/default.htm

        The conference begins with parallel tutorial sessions on Sunday
afternoon and continues with full-day technical sessions Monday and
Tuesday.

        The designated hotel for MPLS2000 is the Sheraton Premiere at
Tyson's Corner.  We have a limited number of rooms blocked at a special
rate and urge you to make your reservations immediately.

        MPLS2000 is co-hosted by George Mason University and UUNET
Technologies and is being sponsored by Nortel Networks, Juniper
Networks, Make Systems, Ennovate Networks, Cisco Systems, Spirent
Communications, IronBridge Networks, Avici Systems, Marconi
Communications, Ericsson, Virginia's Center for Innovative Technology,
and Vivace Networks.  Sponsors will be exhibiting their products and
services throughout the day Monday and Tuesday.

        If you have any further queries, you may contact Pam Jones
(mailto:pjone3@gmu.edu), Advanced Internet Lab, 703-993-4700.  

        We look forward to seeing you in October!

        Rajiv 
        

       ******************************
        Rajiv Papneja
        Advanced Internet Laboratory
        George Mason University,
        G10, Johnson Center,
        Fairfax, VA 22030-4444
        Tel: 703-993-4700
        Fax: 703-993-4704
        email: rpapneja@osf1.gmu.edu
       *******************************










From owner-mpls@UU.NET  Fri Aug  4 09:52:33 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10929
	for <mpls-archive@lists.ietf.org>; Fri, 4 Aug 2000 09:52:33 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjauh25849;
	Fri, 4 Aug 2000 13:51:20 GMT
Received: by mail-control.mail.uu.net 
	id QQjauh01827
	for mpls-outgoing; Fri, 4 Aug 2000 13:50:46 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjauh01822
	for <mpls@mail-control.mail.uu.net>; Fri, 4 Aug 2000 13:50:44 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjauh05322
	for <mpls@UU.NET>; Fri, 4 Aug 2000 09:50:31 -0400 (EDT)
Received: from smtprch2.nortel.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtprch2.nortelnetworks.com [192.135.215.15])
	id QQjauh25022
	for <mpls@UU.NET>; Fri, 4 Aug 2000 13:50:00 GMT
Received: from zrchb213.us.nortel.com (actually zrchb213) 
          by smtprch2.nortel.com; Fri, 4 Aug 2000 08:42:29 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <QFL2AGGX>; Fri, 4 Aug 2000 08:45:56 -0500
Message-ID: <6DDA62170439D31185750000F80826AC03597F1E@zmerd004.ca.nortel.com>
From: "David Allan" <dallan@nortelnetworks.com>
To: Scott Brim <sbrim@cisco.com>, "David R. Oran" <oran@cisco.com>
Cc: mpls <mpls@UU.NET>, IESG <iesg@ietf.org>, IAB <iab@isi.edu>
Subject: RE: Use of the term "end-to-end"
Date: Fri, 4 Aug 2000 08:45:48 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFFE1A.4C1A4CA0"
X-Orig: <dallan@americasm01.nt.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

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_01BFFE1A.4C1A4CA0
Content-Type: text/plain

Agreed

> -----Original Message-----
> From:	Scott Brim [SMTP:sbrim@cisco.com]
> Sent:	Thursday, August 03, 2000 11:37 AM
> To:	David R. Oran
> Cc:	mpls; IESG; IAB
> Subject:	Re: Use of the term "end-to-end"
> 
> LER-to-LER
> 
	<snip>

------_=_NextPart_001_01BFFE1A.4C1A4CA0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: Use of the term &quot;end-to-end&quot;</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Agreed</FONT>
</P>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Scott Brim [SMTP:sbrim@cisco.com]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Thursday, August 03, 2000 11:37 AM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">David R. Oran</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Cc:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">mpls; IESG; IAB</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">Re: Use of the term =
&quot;end-to-end&quot;</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">LER-to-LER</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">&lt;snip&gt;</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BFFE1A.4C1A4CA0--


From owner-mpls@UU.NET  Fri Aug  4 10:31:06 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23773
	for <mpls-archive@lists.ietf.org>; Fri, 4 Aug 2000 10:31:05 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjauk11312;
	Fri, 4 Aug 2000 14:30:38 GMT
Received: by mail-control.mail.uu.net 
	id QQjauk15990
	for mpls-outgoing; Fri, 4 Aug 2000 14:30:10 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjauk15985
	for <mpls@mail-control.mail.uu.net>; Fri, 4 Aug 2000 14:30:08 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjauk12316
	for <mpls@uu.net>; Fri, 4 Aug 2000 10:30:06 -0400 (EDT)
Received: from web5404.mail.yahoo.com by wodc7mr1.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: web5404.mail.yahoo.com [216.115.106.142])
	id QQjauk11025
	for <mpls@uu.net>; Fri, 4 Aug 2000 14:30:06 GMT
Message-ID: <20000804143006.4300.qmail@web5404.mail.yahoo.com>
Received: from [132.177.119.129] by web5404.mail.yahoo.com; Fri, 04 Aug 2000 07:30:05 PDT
Date: Fri, 4 Aug 2000 07:30:05 -0700 (PDT)
From: John Sparr <johnrdb@yahoo.com>
Subject: resource preemption
To: mpls@UU.NET
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

Quick question on resource preemption from RSVP-TE.

In section 4.8.3, it says when a new Path message is
considered for admission, the bandwidth requested is
compared with the bandwidth at the priority specified
in the Setup Priority.

My question is who will do this compare, intermidiate
nodes or receiver?


Thanks in advance
John

__________________________________________________
Do You Yahoo!?
Kick off your party with Yahoo! Invites.
http://invites.yahoo.com/


From owner-mpls@UU.NET  Fri Aug  4 10:59:44 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03465
	for <mpls-archive@lists.ietf.org>; Fri, 4 Aug 2000 10:59:43 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjaul23075;
	Fri, 4 Aug 2000 14:59:13 GMT
Received: by mail-control.mail.uu.net 
	id QQjaul17844
	for mpls-outgoing; Fri, 4 Aug 2000 14:58:50 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjaul17839
	for <mpls@mail-control.mail.uu.net>; Fri, 4 Aug 2000 14:58:45 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjaul19185
	for <mpls@UU.NET>; Fri, 4 Aug 2000 10:58:38 -0400 (EDT)
Received: from web5403.mail.yahoo.com by wodc7mr2.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: web5403.mail.yahoo.com [216.115.106.141])
	id QQjaul00445
	for <mpls@UU.NET>; Fri, 4 Aug 2000 14:58:23 GMT
Message-ID: <20000804145822.29282.qmail@web5403.mail.yahoo.com>
Received: from [132.177.119.129] by web5403.mail.yahoo.com; Fri, 04 Aug 2000 07:58:22 PDT
Date: Fri, 4 Aug 2000 07:58:22 -0700 (PDT)
From: John Sparr <johnrdb@yahoo.com>
Subject: RE: resource preemption
To: "Sanford, Bill" <bills@netplane.com>
Cc: mpls@UU.NET
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk


Bill,

I agree with you. But I think it should not be
receiver because it just requires BW not allocates. Is
that right?


Thanks in advance
John


--- "Sanford, Bill" <bills@netplane.com> wrote:
> Wouldn't it be the first node that didn't have the
> bandwidth, wherever it
> was?
> 
> Bill
> -----Original Message-----
> From: John Sparr [mailto:johnrdb@yahoo.com]
> Sent: Friday, August 04, 2000 10:30 AM
> To: mpls@UU.NET
> Subject: resource preemption
> 
> 
> Hi,
> 
> Quick question on resource preemption from RSVP-TE.
> 
> In section 4.8.3, it says when a new Path message is
> considered for admission, the bandwidth requested is
> compared with the bandwidth at the priority
> specified
> in the Setup Priority.
> 
> My question is who will do this compare,
> intermidiate
> nodes or receiver?
> 
> 
> Thanks in advance
> John
> 
> __________________________________________________
> Do You Yahoo!?
> Kick off your party with Yahoo! Invites.
> http://invites.yahoo.com/


__________________________________________________
Do You Yahoo!?
Kick off your party with Yahoo! Invites.
http://invites.yahoo.com/


From owner-mpls@UU.NET  Fri Aug  4 11:07:08 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06353
	for <mpls-archive@lists.ietf.org>; Fri, 4 Aug 2000 11:07:08 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjaum26413;
	Fri, 4 Aug 2000 15:06:43 GMT
Received: by mail-control.mail.uu.net 
	id QQjaum29473
	for mpls-outgoing; Fri, 4 Aug 2000 15:06:17 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjaum29445
	for <mpls@mail-control.mail.uu.net>; Fri, 4 Aug 2000 15:06:12 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjaum18610
	for <mpls@uu.net>; Fri, 4 Aug 2000 11:05:57 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjaum06111
	for <mpls@uu.net>; Fri, 4 Aug 2000 15:05:41 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA13462
	for mpls@uu.net; Fri, 4 Aug 2000 11:05:41 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjaum29342
	for <mpls@mail-control.mail.uu.net>; Fri, 4 Aug 2000 15:05:14 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjaum20528
	for <mpls@uu.net>; Fri, 4 Aug 2000 11:05:05 -0400 (EDT)
Received: from mailman.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailman.cisco.com [171.68.225.9])
	id QQjaum25737
	for <mpls@uu.net>; Fri, 4 Aug 2000 15:05:03 GMT
Received: from chmetz-pc.cisco.com ([10.19.239.35])
	by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id IAA16940
	for <mpls@uu.net>; Fri, 4 Aug 2000 08:05:02 -0700 (PDT)
Message-Id: <4.3.1.2.20000804105445.0238c870@sj-email.cisco.com>
X-Sender: chmetz@sj-email.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Fri, 04 Aug 2000 11:08:32 -0700
To: mpls@UU.NET
From: Chris Metz <chmetz@cisco.com>
Subject: Question on Notify Message
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi-
Terrific job on the Generalized MPLS signaling draft presented this week in 
Pittsburgh. I had a question on the RSVP Notify message described in 
section 5.
The draft mentions that it does not replace existing error messages. But 
what happens if a particular node along an MPLS TE tunnel (say it is head 
end of a tunnel traversing a single area) receives an RSVP patherr message, 
an RSVP Notify message and a link-state LSA/LSP all reflecting a failure 
along the path.

Is there the possiblity that a race condition could arise? Or I suppose it 
could be up to the implementation to decide what information will be used 
to recover from the TE tunnel failure.

Thanks ...



Chris Metz
Lead IP Architect
Solutions Integration
Service Provider Line of Business
Cisco Systems
email: chmetz@cisco.com
offic phone: 408-525-3275
home office: 914-241-0423
pager: 800-365-4578
Internal URL: http://wwwin-people.cisco.com/chmetz/chmetz.htm  




From owner-mpls@UU.NET  Fri Aug  4 12:23:19 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07147
	for <mpls-archive@lists.ietf.org>; Fri, 4 Aug 2000 12:23:19 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjaur06325;
	Fri, 4 Aug 2000 16:22:46 GMT
Received: by mail-control.mail.uu.net 
	id QQjaur17868
	for mpls-outgoing; Fri, 4 Aug 2000 16:22:16 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjaur17847
	for <mpls@mail-control.mail.uu.net>; Fri, 4 Aug 2000 16:22:01 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjaur09041
	for <mpls@UU.NET>; Fri, 4 Aug 2000 12:21:58 -0400 (EDT)
Received: from smtprch2.nortel.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtprch2.nortelnetworks.com [192.135.215.15])
	id QQjaur05716
	for <mpls@UU.NET>; Fri, 4 Aug 2000 16:21:43 GMT
Received: from zrchb213.us.nortel.com (actually zrchb213) 
          by smtprch2.nortel.com; Fri, 4 Aug 2000 11:14:10 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <QFL2AMZL>; Fri, 4 Aug 2000 11:17:35 -0500
Message-ID: <F033F6FEF3F1D111BD150000F8CD14310460EBD5@zcard007.ca.nortel.com>
From: "Don Fedyk" <dwfedyk@nortelnetworks.com>
To: John Sparr <johnrdb@yahoo.com>, mpls@UU.NET
Subject: RE: resource preemption
Date: Fri, 4 Aug 2000 11:17:23 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFFE2F.78DF4780"
X-Orig: <dwfedyk@americasm01.nt.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

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_01BFFE2F.78DF4780
Content-Type: text/plain;
	charset="iso-8859-1"

John

The compare is done in several places depending on 
how the path was calculated. 

Initially the path selection algorithm performs the 
compare at each node in the topology database. This step
can be skipped if you calculate the ERO manually or offline.

Then as a path message is processed at each single hop the 
comparison is performed again for each link traversed. 
The receiver does not have do anything, since the bandwidth 
has been allocated by all the single hops along the way. 

Don


> -----Original Message-----
> From: John Sparr [mailto:johnrdb@yahoo.com]
> Sent: Friday, August 04, 2000 10:30 AM
> To: mpls@UU.NET
> Subject: resource preemption
> 
> 
> Hi,
> 
> Quick question on resource preemption from RSVP-TE.
> 
> In section 4.8.3, it says when a new Path message is
> considered for admission, the bandwidth requested is
> compared with the bandwidth at the priority specified
> in the Setup Priority.
> 
> My question is who will do this compare, intermidiate
> nodes or receiver?
> 
> 
> Thanks in advance
> John
> 
> __________________________________________________
> Do You Yahoo!?
> Kick off your party with Yahoo! Invites.
> http://invites.yahoo.com/
> 

------_=_NextPart_001_01BFFE2F.78DF4780
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: resource preemption</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>John</FONT>
</P>

<P><FONT SIZE=2>The compare is done in several places depending on </FONT>
<BR><FONT SIZE=2>how the path was calculated. </FONT>
</P>

<P><FONT SIZE=2>Initially the path selection algorithm performs the </FONT>
<BR><FONT SIZE=2>compare at each node in the topology database. This step</FONT>
<BR><FONT SIZE=2>can be skipped if you calculate the ERO manually or offline.</FONT>
</P>

<P><FONT SIZE=2>Then as a path message is processed at each single hop the </FONT>
<BR><FONT SIZE=2>comparison is performed again for each link traversed. </FONT>
<BR><FONT SIZE=2>The receiver does not have do anything, since the bandwidth </FONT>
<BR><FONT SIZE=2>has been allocated by all the single hops along the way. </FONT>
</P>

<P><FONT SIZE=2>Don</FONT>
</P>
<BR>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: John Sparr [<A HREF="mailto:johnrdb@yahoo.com">mailto:johnrdb@yahoo.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Friday, August 04, 2000 10:30 AM</FONT>
<BR><FONT SIZE=2>&gt; To: mpls@UU.NET</FONT>
<BR><FONT SIZE=2>&gt; Subject: resource preemption</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Hi,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Quick question on resource preemption from RSVP-TE.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; In section 4.8.3, it says when a new Path message is</FONT>
<BR><FONT SIZE=2>&gt; considered for admission, the bandwidth requested is</FONT>
<BR><FONT SIZE=2>&gt; compared with the bandwidth at the priority specified</FONT>
<BR><FONT SIZE=2>&gt; in the Setup Priority.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; My question is who will do this compare, intermidiate</FONT>
<BR><FONT SIZE=2>&gt; nodes or receiver?</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Thanks in advance</FONT>
<BR><FONT SIZE=2>&gt; John</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; __________________________________________________</FONT>
<BR><FONT SIZE=2>&gt; Do You Yahoo!?</FONT>
<BR><FONT SIZE=2>&gt; Kick off your party with Yahoo! Invites.</FONT>
<BR><FONT SIZE=2>&gt; <A HREF="http://invites.yahoo.com/" TARGET="_blank">http://invites.yahoo.com/</A></FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BFFE2F.78DF4780--


From owner-mpls@UU.NET  Fri Aug  4 12:53:25 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15462
	for <mpls-archive@lists.ietf.org>; Fri, 4 Aug 2000 12:53:25 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjaut26155;
	Fri, 4 Aug 2000 16:53:00 GMT
Received: by mail-control.mail.uu.net 
	id QQjaut21206
	for mpls-outgoing; Fri, 4 Aug 2000 16:52:39 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjaut21198
	for <mpls@mail-control.mail.uu.net>; Fri, 4 Aug 2000 16:52:37 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjaut18220
	for <mpls@UU.NET>; Fri, 4 Aug 2000 12:52:29 -0400 (EDT)
Received: from web5401.mail.yahoo.com by wodc7mr2.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: web5401.mail.yahoo.com [216.115.106.132])
	id QQjaut08614
	for <mpls@UU.NET>; Fri, 4 Aug 2000 16:51:58 GMT
Message-ID: <20000804165144.19882.qmail@web5401.mail.yahoo.com>
Received: from [132.177.119.129] by web5401.mail.yahoo.com; Fri, 04 Aug 2000 09:51:44 PDT
Date: Fri, 4 Aug 2000 09:51:44 -0700 (PDT)
From: John Sparr <johnrdb@yahoo.com>
Subject: RE: resource preemption
To: "Sanford, Bill" <bills@netplane.com>
Cc: mpls@UU.NET
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Bill,

One more question: what's the meaning of "the only
priority left is the Holding priority in the LSP just
established" ?  It seems that the Setup priority is
reset or what others? My understanding is right?

Thanks
John

--- "Sanford, Bill" <bills@netplane.com> wrote:
> John, the setup priority is checked every hop.  Once
> a hop doesn't have the
> bandwidth, the setup priority in the PATH message
> checks to see if an LSP
> with a holding priority lower than itself can be
> bumped.  Two things can
> happen, either the PATH message is refused and a
> PATH_ERR is sent back to
> the Ingress or it bumps an LSP with a lower holding
> priority and moves
> downstream.  The setup priority in the PATH message
> will most likely do this
> multiple times downstream. 
> 
> Once the setup priority in the PATH message has
> successfully got to the
> Egress the only priority left is the Holding
> priority in the LSP just
> established. So as far as who will do the compare of
> the setup priority,
> every downsteam node does except the receiver.
> 
> -----Original Message-----
> From: John Sparr [mailto:johnrdb@yahoo.com]
> Sent: Friday, August 04, 2000 10:58 AM
> To: Sanford, Bill
> Cc: mpls@UU.NET
> Subject: RE: resource preemption
> 
> 
> 
> Bill,
> 
> I agree with you. But I think it should not be
> receiver because it just requires BW not allocates.
> Is
> that right?
> 
> 
> Thanks in advance
> John
> 
> 
> --- "Sanford, Bill" <bills@netplane.com> wrote:
> > Wouldn't it be the first node that didn't have the
> > bandwidth, wherever it
> > was?
> > 
> > Bill
> > -----Original Message-----
> > From: John Sparr [mailto:johnrdb@yahoo.com]
> > Sent: Friday, August 04, 2000 10:30 AM
> > To: mpls@UU.NET
> > Subject: resource preemption
> > 
> > 
> > Hi,
> > 
> > Quick question on resource preemption from
> RSVP-TE.
> > 
> > In section 4.8.3, it says when a new Path message
> is
> > considered for admission, the bandwidth requested
> is
> > compared with the bandwidth at the priority
> > specified
> > in the Setup Priority.
> > 
> > My question is who will do this compare,
> > intermidiate
> > nodes or receiver?
> > 
> > 
> > Thanks in advance
> > John
> > 
> > __________________________________________________
> > Do You Yahoo!?
> > Kick off your party with Yahoo! Invites.
> > http://invites.yahoo.com/
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Kick off your party with Yahoo! Invites.
> http://invites.yahoo.com/


__________________________________________________
Do You Yahoo!?
Kick off your party with Yahoo! Invites.
http://invites.yahoo.com/


From owner-mpls@UU.NET  Fri Aug  4 13:20:13 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21990
	for <mpls-archive@lists.ietf.org>; Fri, 4 Aug 2000 13:20:13 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjauv27956;
	Fri, 4 Aug 2000 17:19:28 GMT
Received: by mail-control.mail.uu.net 
	id QQjauv05572
	for mpls-outgoing; Fri, 4 Aug 2000 17:19:08 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjauv05562
	for <mpls@mail-control.mail.uu.net>; Fri, 4 Aug 2000 17:19:05 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjauv22811
	for <mpls@UU.NET>; Fri, 4 Aug 2000 13:18:45 -0400 (EDT)
Received: from empowertel.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [64.220.200.243])
	id QQjauv06315
	for <mpls@UU.NET>; Fri, 4 Aug 2000 17:18:30 GMT
Received: from navin ([192.168.111.106])
	by empowertel.com (8.9.3+Sun/8.9.3) with SMTP id KAA21633;
	Fri, 4 Aug 2000 10:15:52 -0700 (PDT)
From: "Navin" <navin@empowertel.com>
To: "John Sparr" <johnrdb@yahoo.com>, <mpls@UU.NET>
Subject: RE: resource preemption
Date: Fri, 4 Aug 2000 10:15:05 -0500
Message-ID: <NEBBJIEAGMMMEALNOJCCEEHBCAAA.navin@empowertel.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <20000804143006.4300.qmail@web5404.mail.yahoo.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi There,

First of all, you carry out admission control check while
processing the RESV message NOT PATH message.

Secondly, admission control check will be done at all the nodes
EXCEPT the receiver node as there you really don't reserve
anything.

Hope this helps,

Cheers,
Navin


-----Original Message-----
From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of John
Sparr
Sent: Friday, August 04, 2000 9:30 AM
To: mpls@UU.NET
Subject: resource preemption


Hi,

Quick question on resource preemption from RSVP-TE.

In section 4.8.3, it says when a new Path message is
considered for admission, the bandwidth requested is
compared with the bandwidth at the priority specified
in the Setup Priority.

My question is who will do this compare, intermidiate
nodes or receiver?


Thanks in advance
John

__________________________________________________
Do You Yahoo!?
Kick off your party with Yahoo! Invites.
http://invites.yahoo.com/


From owner-mpls@UU.NET  Fri Aug  4 14:19:49 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13547
	for <mpls-archive@lists.ietf.org>; Fri, 4 Aug 2000 14:19:48 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjauz19541;
	Fri, 4 Aug 2000 18:19:24 GMT
Received: by mail-control.mail.uu.net 
	id QQjauz23355
	for mpls-outgoing; Fri, 4 Aug 2000 18:18:54 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjauz23326
	for <mpls@mail-control.mail.uu.net>; Fri, 4 Aug 2000 18:18:37 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjauz06853
	for <mpls@uu.net>; Fri, 4 Aug 2000 14:18:29 -0400 (EDT)
Received: from web5404.mail.yahoo.com by wodc7mr2.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: web5404.mail.yahoo.com [216.115.106.142])
	id QQjauz18547
	for <mpls@uu.net>; Fri, 4 Aug 2000 18:18:09 GMT
Message-ID: <20000804181809.17943.qmail@web5404.mail.yahoo.com>
Received: from [132.177.119.129] by web5404.mail.yahoo.com; Fri, 04 Aug 2000 11:18:09 PDT
Date: Fri, 4 Aug 2000 11:18:09 -0700 (PDT)
From: John Sparr <johnrdb@yahoo.com>
Subject: RE: resource preemption
To: Navin <navin@empowertel.com>
Cc: mpls@UU.NET
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Navin,

It should be that Resv message triggers this compare.
But why the draft says "When a path message is
considered for admission"?(section 4.8.3) It seems
when a node received a Path message it checks if the
bandwidth is avialable. I think the bandwidth request
should be in Resv message. is that right?


Regards,
John

--- Navin <navin@empowertel.com> wrote:
> Hi There,
> 
> First of all, you carry out admission control check
> while
> processing the RESV message NOT PATH message.
> 
> Secondly, admission control check will be done at
> all the nodes
> EXCEPT the receiver node as there you really don't
> reserve
> anything.
> 
> Hope this helps,
> 
> Cheers,
> Navin
> 
> 
> -----Original Message-----
> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On
> Behalf Of John
> Sparr
> Sent: Friday, August 04, 2000 9:30 AM
> To: mpls@UU.NET
> Subject: resource preemption
> 
> 
> Hi,
> 
> Quick question on resource preemption from RSVP-TE.
> 
> In section 4.8.3, it says when a new Path message is
> considered for admission, the bandwidth requested is
> compared with the bandwidth at the priority
> specified
> in the Setup Priority.
> 
> My question is who will do this compare,
> intermidiate
> nodes or receiver?
> 
> 
> Thanks in advance
> John
> 
> __________________________________________________
> Do You Yahoo!?
> Kick off your party with Yahoo! Invites.
> http://invites.yahoo.com/


__________________________________________________
Do You Yahoo!?
Kick off your party with Yahoo! Invites.
http://invites.yahoo.com/


From owner-mpls@UU.NET  Fri Aug  4 14:34:38 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18587
	for <mpls-archive@lists.ietf.org>; Fri, 4 Aug 2000 14:34:38 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjava13182;
	Fri, 4 Aug 2000 18:34:11 GMT
Received: by mail-control.mail.uu.net 
	id QQjava25000
	for mpls-outgoing; Fri, 4 Aug 2000 18:33:34 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjava24995
	for <mpls@mail-control.mail.uu.net>; Fri, 4 Aug 2000 18:33:32 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjava06682
	for <mpls@UU.NET>; Fri, 4 Aug 2000 14:33:14 -0400 (EDT)
Received: from yarilo.pluris.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pluris.com [208.227.9.12])
	id QQjava29792
	for <mpls@UU.NET>; Fri, 4 Aug 2000 18:32:44 GMT
Received: from monterey.pluris.com (monterey.pluris.com [172.16.50.17])
	by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id LAA10878;
	Fri, 4 Aug 2000 11:32:41 -0700 (PDT)
Received: by MONTEREY with Internet Mail Service (5.5.2650.21)
	id <P5D9CZYA>; Fri, 4 Aug 2000 11:32:41 -0700
Message-ID: <E097FDA4F2FED311994000104B31A86115B5E3@MONTEREY>
From: Sundara Murugan <sundar@pluris.com>
To: "'John Sparr'" <johnrdb@yahoo.com>, Navin <navin@empowertel.com>
Cc: mpls@UU.NET
Subject: RE: resource preemption
Date: Fri, 4 Aug 2000 11:32:36 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

John ,

The resv message doesn't contain session attribute object and hence you
don't know the setup and holding priorities of the LSP. These are available
in the path message and hence Call admission should be done during path
message.

When there is not enough resources available to support the LSP, you can
find out how much is allocated to lower priority LSPs and based on that you
can generate the AdSepc. These lower priority must be preempted only when
you get the resv message.

-sundara  

-----Original Message-----
From: John Sparr [mailto:johnrdb@yahoo.com]
Sent: Friday, August 04, 2000 11:18 AM
To: Navin
Cc: mpls@UU.NET
Subject: RE: resource preemption


Hi Navin,

It should be that Resv message triggers this compare.
But why the draft says "When a path message is
considered for admission"?(section 4.8.3) It seems
when a node received a Path message it checks if the
bandwidth is avialable. I think the bandwidth request
should be in Resv message. is that right?


Regards,
John

--- Navin <navin@empowertel.com> wrote:
> Hi There,
> 
> First of all, you carry out admission control check
> while
> processing the RESV message NOT PATH message.
> 
> Secondly, admission control check will be done at
> all the nodes
> EXCEPT the receiver node as there you really don't
> reserve
> anything.
> 
> Hope this helps,
> 
> Cheers,
> Navin
> 
> 
> -----Original Message-----
> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On
> Behalf Of John
> Sparr
> Sent: Friday, August 04, 2000 9:30 AM
> To: mpls@UU.NET
> Subject: resource preemption
> 
> 
> Hi,
> 
> Quick question on resource preemption from RSVP-TE.
> 
> In section 4.8.3, it says when a new Path message is
> considered for admission, the bandwidth requested is
> compared with the bandwidth at the priority
> specified
> in the Setup Priority.
> 
> My question is who will do this compare,
> intermidiate
> nodes or receiver?
> 
> 
> Thanks in advance
> John
> 
> __________________________________________________
> Do You Yahoo!?
> Kick off your party with Yahoo! Invites.
> http://invites.yahoo.com/


__________________________________________________
Do You Yahoo!?
Kick off your party with Yahoo! Invites.
http://invites.yahoo.com/


From owner-mpls@UU.NET  Fri Aug  4 14:52:33 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24477
	for <mpls-archive@lists.ietf.org>; Fri, 4 Aug 2000 14:52:32 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjavb20495;
	Fri, 4 Aug 2000 18:51:50 GMT
Received: by mail-control.mail.uu.net 
	id QQjavb26776
	for mpls-outgoing; Fri, 4 Aug 2000 18:51:29 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjavb26770
	for <mpls@mail-control.mail.uu.net>; Fri, 4 Aug 2000 18:51:18 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjavb12510
	for <mpls@UU.NET>; Fri, 4 Aug 2000 14:51:15 -0400 (EDT)
Received: from zrtps06s.us.nortel.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [47.140.48.50])
	id QQjavb12600
	for <mpls@UU.NET>; Fri, 4 Aug 2000 18:50:47 GMT
Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com;
          Fri, 4 Aug 2000 14:50:00 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <P4SVMZPS>; Fri, 4 Aug 2000 14:50:02 -0400
Message-ID: <F033F6FEF3F1D111BD150000F8CD14310460ECE2@zcard007.ca.nortel.com>
From: "Don Fedyk" <dwfedyk@nortelnetworks.com>
To: Navin <navin@empowertel.com>
Cc: johnrdb@yahoo.com, mpls@UU.NET
Subject: RE: resource preemption
Date: Fri, 4 Aug 2000 14:48:49 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFFE44.A0C24260"
X-Orig: <dwfedyk@americasm01.nt.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

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_01BFFE44.A0C24260
Content-Type: text/plain;
	charset="iso-8859-1"

Hi

I think I know where your confusion comes from, the fact that although
you reserve on the path message you lock in the bandwidth on 
the resv message. So I wouldn't preempt until the resv 
comes back (because the path message might have failed at 
subsequent hops). So in reality you do a check in both messages.

Don

> -----Original Message-----
> From: Navin [mailto:navin@empowertel.com]
> Sent: Friday, August 04, 2000 11:15 AM
> To: John Sparr; mpls
> Subject: RE: resource preemption
> 
> 
> Hi There,
> 
> First of all, you carry out admission control check while
> processing the RESV message NOT PATH message.
> 
> Secondly, admission control check will be done at all the nodes
> EXCEPT the receiver node as there you really don't reserve
> anything.
> 
> Hope this helps,
> 
> Cheers,
> Navin
> 
> 
> -----Original Message-----
> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of John
> Sparr
> Sent: Friday, August 04, 2000 9:30 AM
> To: mpls@UU.NET
> Subject: resource preemption
> 
> 
> Hi,
> 
> Quick question on resource preemption from RSVP-TE.
> 
> In section 4.8.3, it says when a new Path message is
> considered for admission, the bandwidth requested is
> compared with the bandwidth at the priority specified
> in the Setup Priority.
> 
> My question is who will do this compare, intermidiate
> nodes or receiver?
> 
> 
> Thanks in advance
> John
> 
> __________________________________________________
> Do You Yahoo!?
> Kick off your party with Yahoo! Invites.
> http://invites.yahoo.com/
> 

------_=_NextPart_001_01BFFE44.A0C24260
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: resource preemption</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Hi</FONT>
</P>

<P><FONT SIZE=2>I think I know where your confusion comes from, the fact that although</FONT>
<BR><FONT SIZE=2>you reserve on the path message you lock in the bandwidth on </FONT>
<BR><FONT SIZE=2>the resv message. So I wouldn't preempt until the resv </FONT>
<BR><FONT SIZE=2>comes back (because the path message might have failed at </FONT>
<BR><FONT SIZE=2>subsequent hops). So in reality you do a check in both messages.</FONT>
</P>

<P><FONT SIZE=2>Don</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Navin [<A HREF="mailto:navin@empowertel.com">mailto:navin@empowertel.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Friday, August 04, 2000 11:15 AM</FONT>
<BR><FONT SIZE=2>&gt; To: John Sparr; mpls</FONT>
<BR><FONT SIZE=2>&gt; Subject: RE: resource preemption</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Hi There,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; First of all, you carry out admission control check while</FONT>
<BR><FONT SIZE=2>&gt; processing the RESV message NOT PATH message.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Secondly, admission control check will be done at all the nodes</FONT>
<BR><FONT SIZE=2>&gt; EXCEPT the receiver node as there you really don't reserve</FONT>
<BR><FONT SIZE=2>&gt; anything.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Hope this helps,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Cheers,</FONT>
<BR><FONT SIZE=2>&gt; Navin</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: owner-mpls@UU.NET [<A HREF="mailto:owner-mpls@UU.NET">mailto:owner-mpls@UU.NET</A>]On Behalf Of John</FONT>
<BR><FONT SIZE=2>&gt; Sparr</FONT>
<BR><FONT SIZE=2>&gt; Sent: Friday, August 04, 2000 9:30 AM</FONT>
<BR><FONT SIZE=2>&gt; To: mpls@UU.NET</FONT>
<BR><FONT SIZE=2>&gt; Subject: resource preemption</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Hi,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Quick question on resource preemption from RSVP-TE.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; In section 4.8.3, it says when a new Path message is</FONT>
<BR><FONT SIZE=2>&gt; considered for admission, the bandwidth requested is</FONT>
<BR><FONT SIZE=2>&gt; compared with the bandwidth at the priority specified</FONT>
<BR><FONT SIZE=2>&gt; in the Setup Priority.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; My question is who will do this compare, intermidiate</FONT>
<BR><FONT SIZE=2>&gt; nodes or receiver?</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Thanks in advance</FONT>
<BR><FONT SIZE=2>&gt; John</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; __________________________________________________</FONT>
<BR><FONT SIZE=2>&gt; Do You Yahoo!?</FONT>
<BR><FONT SIZE=2>&gt; Kick off your party with Yahoo! Invites.</FONT>
<BR><FONT SIZE=2>&gt; <A HREF="http://invites.yahoo.com/" TARGET="_blank">http://invites.yahoo.com/</A></FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BFFE44.A0C24260--


From owner-mpls@UU.NET  Fri Aug  4 14:58:33 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26412
	for <mpls-archive@lists.ietf.org>; Fri, 4 Aug 2000 14:58:33 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjavb17782;
	Fri, 4 Aug 2000 18:57:49 GMT
Received: by mail-control.mail.uu.net 
	id QQjavb27461
	for mpls-outgoing; Fri, 4 Aug 2000 18:57:30 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjavb27443
	for <mpls@mail-control.mail.uu.net>; Fri, 4 Aug 2000 18:57:19 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjavb13390
	for <mpls@UU.NET>; Fri, 4 Aug 2000 14:57:05 -0400 (EDT)
Received: from empowertel.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [64.220.200.243])
	id QQjavb17127
	for <mpls@UU.NET>; Fri, 4 Aug 2000 18:57:04 GMT
Received: from navin ([192.168.111.106])
	by empowertel.com (8.9.3+Sun/8.9.3) with SMTP id LAA26887;
	Fri, 4 Aug 2000 11:54:27 -0700 (PDT)
From: "Navin" <navin@empowertel.com>
To: "Sundara Murugan" <sundar@pluris.com>, "'John Sparr'" <johnrdb@yahoo.com>
Cc: <mpls@UU.NET>
Subject: RE: resource preemption
Date: Fri, 4 Aug 2000 11:53:53 -0500
Message-ID: <NEBBJIEAGMMMEALNOJCCIEHFCAAA.navin@empowertel.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <E097FDA4F2FED311994000104B31A86115B5E3@MONTEREY>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Folks,

>John ,
>
>The resv message doesn't contain session attribute object and hence you
>don't know the setup and holding priorities of the LSP. These are available
>in the path message and hence Call admission should be done during path
>message.

In any case, Once your LSP is 'setuped', the setup priority doesn't have any
meaning.
And the only priority which will be used is the holding priority.

A quick question. If you are implementing RFC2212 i.e GS, how would you
accomodate
R, if R > r. Considering that you would have already accepted the session
while
processing the Path message.

Anyway, Read RFC2209 and get the first hand info on RSVP message processing.

Have a nice weekend.

Over & out.

Navin

>
>When there is not enough resources available to support the LSP, you can
>find out how much is allocated to lower priority LSPs and based on that you
>can generate the AdSepc. These lower priority must be preempted only when
>you get the resv message.
>
>-sundara
>
>-----Original Message-----
>From: John Sparr [mailto:johnrdb@yahoo.com]
>Sent: Friday, August 04, 2000 11:18 AM
>To: Navin
>Cc: mpls@UU.NET
>Subject: RE: resource preemption
>
>
>Hi Navin,
>
>It should be that Resv message triggers this compare.
>But why the draft says "When a path message is
>considered for admission"?(section 4.8.3) It seems
>when a node received a Path message it checks if the
>bandwidth is avialable. I think the bandwidth request
>should be in Resv message. is that right?
>
>
>Regards,
>John
>
>--- Navin <navin@empowertel.com> wrote:
>> Hi There,
>>
>> First of all, you carry out admission control check
>> while
>> processing the RESV message NOT PATH message.
>>
>> Secondly, admission control check will be done at
>> all the nodes
>> EXCEPT the receiver node as there you really don't
>> reserve
>> anything.
>>
>> Hope this helps,
>>
>> Cheers,
>> Navin
>>
>>
>> -----Original Message-----
>> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On
>> Behalf Of John
>> Sparr
>> Sent: Friday, August 04, 2000 9:30 AM
>> To: mpls@UU.NET
>> Subject: resource preemption
>>
>>
>> Hi,
>>
>> Quick question on resource preemption from RSVP-TE.
>>
>> In section 4.8.3, it says when a new Path message is
>> considered for admission, the bandwidth requested is
>> compared with the bandwidth at the priority
>> specified
>> in the Setup Priority.
>>
>> My question is who will do this compare,
>> intermidiate
>> nodes or receiver?
>>
>>
>> Thanks in advance
>> John
>>
>> __________________________________________________
>> Do You Yahoo!?
>> Kick off your party with Yahoo! Invites.
>> http://invites.yahoo.com/
>
>
>__________________________________________________
>Do You Yahoo!?
>Kick off your party with Yahoo! Invites.
>http://invites.yahoo.com/



From owner-mpls@UU.NET  Fri Aug  4 15:24:09 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02825
	for <mpls-archive@lists.ietf.org>; Fri, 4 Aug 2000 15:24:08 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjavd06496;
	Fri, 4 Aug 2000 19:23:01 GMT
Received: by mail-control.mail.uu.net 
	id QQjavd10452
	for mpls-outgoing; Fri, 4 Aug 2000 19:22:31 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjavd10421
	for <mpls@mail-control.mail.uu.net>; Fri, 4 Aug 2000 19:22:28 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjavd17839
	for <mpls@UU.NET>; Fri, 4 Aug 2000 15:22:17 -0400 (EDT)
Received: from web5404.mail.yahoo.com by wodc7mr2.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: web5404.mail.yahoo.com [216.115.106.142])
	id QQjavd05672
	for <mpls@UU.NET>; Fri, 4 Aug 2000 19:22:02 GMT
Message-ID: <20000804192202.29007.qmail@web5404.mail.yahoo.com>
Received: from [132.177.119.129] by web5404.mail.yahoo.com; Fri, 04 Aug 2000 12:22:02 PDT
Date: Fri, 4 Aug 2000 12:22:02 -0700 (PDT)
From: John Sparr <johnrdb@yahoo.com>
Subject: RE: resource preemption
To: Navin <navin@empowertel.com>, Sundara Murugan <sundar@pluris.com>,
        bills@netplane.com
Cc: mpls@UU.NET
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Folks,

Is that possible for the case below:

     A---B, A and B are LER

A set up one LSP and then sends another new Path
message, if the bandwidth requested is not available,
what happened? A PathErr should be returned to LER A,
but who returned, LER B?

Thanks
John


--- Navin <navin@empowertel.com> wrote:
> Hi Folks,
> 
> >John ,
> >
> >The resv message doesn't contain session attribute
> object and hence you
> >don't know the setup and holding priorities of the
> LSP. These are available
> >in the path message and hence Call admission should
> be done during path
> >message.
> 
> In any case, Once your LSP is 'setuped', the setup
> priority doesn't have any
> meaning.
> And the only priority which will be used is the
> holding priority.
> 
> A quick question. If you are implementing RFC2212
> i.e GS, how would you
> accomodate
> R, if R > r. Considering that you would have already
> accepted the session
> while
> processing the Path message.
> 
> Anyway, Read RFC2209 and get the first hand info on
> RSVP message processing.
> 
> Have a nice weekend.
> 
> Over & out.
> 
> Navin
> 
> >
> >When there is not enough resources available to
> support the LSP, you can
> >find out how much is allocated to lower priority
> LSPs and based on that you
> >can generate the AdSepc. These lower priority must
> be preempted only when
> >you get the resv message.
> >
> >-sundara
> >
> >-----Original Message-----
> >From: John Sparr [mailto:johnrdb@yahoo.com]
> >Sent: Friday, August 04, 2000 11:18 AM
> >To: Navin
> >Cc: mpls@UU.NET
> >Subject: RE: resource preemption
> >
> >
> >Hi Navin,
> >
> >It should be that Resv message triggers this
> compare.
> >But why the draft says "When a path message is
> >considered for admission"?(section 4.8.3) It seems
> >when a node received a Path message it checks if
> the
> >bandwidth is avialable. I think the bandwidth
> request
> >should be in Resv message. is that right?
> >
> >
> >Regards,
> >John
> >
> >--- Navin <navin@empowertel.com> wrote:
> >> Hi There,
> >>
> >> First of all, you carry out admission control
> check
> >> while
> >> processing the RESV message NOT PATH message.
> >>
> >> Secondly, admission control check will be done at
> >> all the nodes
> >> EXCEPT the receiver node as there you really
> don't
> >> reserve
> >> anything.
> >>
> >> Hope this helps,
> >>
> >> Cheers,
> >> Navin
> >>
> >>
> >> -----Original Message-----
> >> From: owner-mpls@UU.NET
> [mailto:owner-mpls@UU.NET]On
> >> Behalf Of John
> >> Sparr
> >> Sent: Friday, August 04, 2000 9:30 AM
> >> To: mpls@UU.NET
> >> Subject: resource preemption
> >>
> >>
> >> Hi,
> >>
> >> Quick question on resource preemption from
> RSVP-TE.
> >>
> >> In section 4.8.3, it says when a new Path message
> is
> >> considered for admission, the bandwidth requested
> is
> >> compared with the bandwidth at the priority
> >> specified
> >> in the Setup Priority.
> >>
> >> My question is who will do this compare,
> >> intermidiate
> >> nodes or receiver?
> >>
> >>
> >> Thanks in advance
> >> John
> >>
> >>
> __________________________________________________
> >> Do You Yahoo!?
> >> Kick off your party with Yahoo! Invites.
> >> http://invites.yahoo.com/
> >
> >
> >__________________________________________________
> >Do You Yahoo!?
> >Kick off your party with Yahoo! Invites.
> >http://invites.yahoo.com/
> 


__________________________________________________
Do You Yahoo!?
Kick off your party with Yahoo! Invites.
http://invites.yahoo.com/


From owner-mpls@UU.NET  Fri Aug  4 15:54:51 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09588
	for <mpls-archive@lists.ietf.org>; Fri, 4 Aug 2000 15:54:51 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjavf12140;
	Fri, 4 Aug 2000 19:54:24 GMT
Received: by mail-control.mail.uu.net 
	id QQjavf12570
	for mpls-outgoing; Fri, 4 Aug 2000 19:54:05 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjavf12521
	for <mpls@mail-control.mail.uu.net>; Fri, 4 Aug 2000 19:53:52 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjavf23088
	for <mpls@UU.NET>; Fri, 4 Aug 2000 15:53:37 -0400 (EDT)
Received: from ennovatenetworks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ennovatenetworks.com [208.227.99.254])
	id QQjavf28566
	for <mpls@UU.NET>; Fri, 4 Aug 2000 19:53:37 GMT
Received: from tworster (dhcp114.tst.ennovatenetworks.com [10.1.3.114])
	by ennovatenetworks.com (8.8.7/8.8.7) with SMTP id PAA15959;
	Fri, 4 Aug 2000 15:53:36 -0400 (EDT)
	(envelope-from tom@ennovatenetworks.com)
From: "tom worster" <tom@ennovatenetworks.com>
To: "Mpls List (E-mail)" <mpls@UU.NET>, <routing-discussion@ietf.org>
Subject: mpls-in-ip slides
Date: Fri, 4 Aug 2000 15:54:16 -0400
Message-ID: <000201bffe4d$c5afe880$a8a8a8c0@ennovatenetworks.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

the slides i nearly used to present mpls-in-ip at the routing
area meeting are at:

http://thefsb.org/mpls-in-ip.ppt

c u
tom

______________________________________________________________________
tom worster, ennovate networks, 60 codman hill rd, boxborough ma 01719
tel: +1 978 206 0490   fax: +1 978 263 1090   tom@ennovatenetworks.com


From owner-mpls@UU.NET  Fri Aug  4 18:58:43 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15522
	for <mpls-archive@lists.ietf.org>; Fri, 4 Aug 2000 18:58:43 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjavr28587;
	Fri, 4 Aug 2000 22:58:14 GMT
Received: by mail-control.mail.uu.net 
	id QQjavr27918
	for mpls-outgoing; Fri, 4 Aug 2000 22:57:45 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjavr27913
	for <mpls@mail-control.mail.uu.net>; Fri, 4 Aug 2000 22:57:40 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjavr15679
	for <mpls@uu.net>; Fri, 4 Aug 2000 18:57:25 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQjavr27944
	for <mpls@uu.net>; Fri, 4 Aug 2000 22:57:24 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA09031
	for <mpls@uu.net>; Fri, 4 Aug 2000 18:57:17 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA27959
	for <mpls@uu.net>; Fri, 4 Aug 2000 18:57:20 -0400 (EDT)
Message-ID: <398B4A80.CE04994A@marconi.com>
Date: Fri, 04 Aug 2000 18:58:08 -0400
From: David Charlap <david.charlap@marconi.com>
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: resource preemption
References: <20000804181809.17943.qmail@web5404.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

John Sparr wrote:
> 
> It should be that Resv message triggers this compare.  But why the
> draft says "When a path message is considered for admission"? (section
> 4.8.3) It seems when a node received a Path message it checks if the
> bandwidth is avialable. I think the bandwidth request should be in
> Resv message. is that right?

The actual resources must be reserved and locked down while processing
the Resv message.

Some hardware and/or software implementation may find it useful or
necessary to reserve (or confirm the availability of) resources during
Path processing.

It is also, however, reasonable for a switch to just record the contents
of a Path message and do all admission control processing when the Resv
message is processed.

-- David


From owner-mpls@UU.NET  Fri Aug  4 18:59:27 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15683
	for <mpls-archive@lists.ietf.org>; Fri, 4 Aug 2000 18:59:27 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjavr29258;
	Fri, 4 Aug 2000 22:58:46 GMT
Received: by mail-control.mail.uu.net 
	id QQjavr27947
	for mpls-outgoing; Fri, 4 Aug 2000 22:58:29 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjavr27940
	for <mpls@mail-control.mail.uu.net>; Fri, 4 Aug 2000 22:58:21 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjavr15819
	for <mpls@uu.net>; Fri, 4 Aug 2000 18:58:15 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQjavr28161
	for <mpls@uu.net>; Fri, 4 Aug 2000 22:57:45 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA09047
	for <mpls@uu.net>; Fri, 4 Aug 2000 18:57:41 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA27987
	for <mpls@uu.net>; Fri, 4 Aug 2000 18:57:44 -0400 (EDT)
Message-ID: <398B4A97.49E9EE52@marconi.com>
Date: Fri, 04 Aug 2000 18:58:31 -0400
From: David Charlap <david.charlap@marconi.com>
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: resource preemption
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Don Fedyk wrote:
> 
> I think I know where your confusion comes from, the fact that although
> you reserve on the path message you lock in the bandwidth on the resv
> message. So I wouldn't preempt until the resv comes back (because the
> path message might have failed at subsequent hops). So in reality you
> do a check in both messages.

There is no requirement to reserve anything on the Path message,
although some implementations may find it convenient to do so.

-- David


From owner-mpls@UU.NET  Fri Aug  4 18:59:57 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15807
	for <mpls-archive@lists.ietf.org>; Fri, 4 Aug 2000 18:59:57 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjavr08724;
	Fri, 4 Aug 2000 22:59:18 GMT
Received: by mail-control.mail.uu.net 
	id QQjavr27964
	for mpls-outgoing; Fri, 4 Aug 2000 22:58:49 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjavr27959
	for <mpls@mail-control.mail.uu.net>; Fri, 4 Aug 2000 22:58:40 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjavr15843
	for <mpls@uu.net>; Fri, 4 Aug 2000 18:58:28 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQjavr28532
	for <mpls@uu.net>; Fri, 4 Aug 2000 22:58:13 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA09068
	for <mpls@uu.net>; Fri, 4 Aug 2000 18:58:09 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA28013
	for <mpls@uu.net>; Fri, 4 Aug 2000 18:58:12 -0400 (EDT)
Message-ID: <398B4AB3.EE43BD1E@marconi.com>
Date: Fri, 04 Aug 2000 18:58:59 -0400
From: David Charlap <david.charlap@marconi.com>
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: resource preemption
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Navin wrote:
> 
> Secondly, admission control check will be done at all the nodes EXCEPT
> the receiver node as there you really don't reserve anything.

However, the inbound interface on the receiver node may police the
packet flow.

-- David


From owner-mpls@UU.NET  Fri Aug  4 19:19:25 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19873
	for <mpls-archive@lists.ietf.org>; Fri, 4 Aug 2000 19:19:24 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjavj04124;
	Fri, 4 Aug 2000 20:45:58 GMT
Received: by mail-control.mail.uu.net 
	id QQjavj27057
	for mpls-outgoing; Fri, 4 Aug 2000 20:45:26 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjavj27050
	for <mpls@mail-control.mail.uu.net>; Fri, 4 Aug 2000 20:45:15 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjavi27271
	for <mpls@UU.NET>; Fri, 4 Aug 2000 16:44:52 -0400 (EDT)
Received: from ennovatenetworks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ennovatenetworks.com [208.227.99.254])
	id QQjavi03247
	for <mpls@UU.NET>; Fri, 4 Aug 2000 20:44:51 GMT
Received: from tworster (dhcp114.tst.ennovatenetworks.com [10.1.3.114])
	by ennovatenetworks.com (8.8.7/8.8.7) with SMTP id QAA17971
	for <mpls@UU.NET>; Fri, 4 Aug 2000 16:44:51 -0400 (EDT)
	(envelope-from tom@ennovatenetworks.com)
From: "tom worster" <tom@ennovatenetworks.com>
To: "Mpls List (E-mail)" <mpls@UU.NET>
Subject: mpls-in-ip i-d
Date: Fri, 4 Aug 2000 16:45:31 -0400
Message-ID: <000401bffe54$ee8c8e00$a8a8a8c0@ennovatenetworks.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

i have updated mpls-in-ip (incorporating eric r.'s comments) and 
submitted it to the i-d editor. 

i would now like to submit the i-d for adoption a wg draft.

copies are also available from:

http://thefsb.org/draft-worster-mpls-in-ip-02.txt
http://thefsb.org/draft-worster-mpls-in-ip-02.doc
http://thefsb.org/draft-worster-mpls-in-ip-02.pdf

c u
tom


From owner-mpls@UU.NET  Sun Aug  6 13:48:20 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04430
	for <mpls-archive@lists.ietf.org>; Sun, 6 Aug 2000 13:48:20 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbch04408;
	Sun, 6 Aug 2000 17:47:38 GMT
Received: by mail-control.mail.uu.net 
	id QQjbch20429
	for mpls-outgoing; Sun, 6 Aug 2000 17:47:18 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjbch20424
	for <mpls@mail-control.mail.uu.net>; Sun, 6 Aug 2000 17:47:17 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbch29504
	for <mpls@UU.NET>; Sun, 6 Aug 2000 13:47:10 -0400 (EDT)
Received: from ennovatenetworks.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ennovatenetworks.com [208.227.99.254])
	id QQjbch04235
	for <mpls@UU.NET>; Sun, 6 Aug 2000 17:47:10 GMT
Received: from tworster ([208.227.99.10])
	by ennovatenetworks.com (8.8.7/8.8.7) with SMTP id NAA02150;
	Sun, 6 Aug 2000 13:47:09 -0400 (EDT)
	(envelope-from tom@ennovatenetworks.com)
From: "tom worster" <tom@ennovatenetworks.com>
To: "'Mpls List (E-mail)'" <mpls@UU.NET>, <routing-discussion@ietf.org>
Subject: RE: mpls-in-ip slides
Date: Sun, 6 Aug 2000 13:47:51 -0400
Message-ID: <005301bfffce$71e62fc0$6640a8c0@thefsb.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <000201bffe4d$c5afe880$a8a8a8c0@ennovatenetworks.com>
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of tom worster
> 
> the slides i nearly used to present mpls-in-ip at the routing
> area meeting are at:
> 
> http://thefsb.org/mpls-in-ip.ppt
> 

it was pointed out to me that these slides contain a "confidential"
tag. this was a mistake. the material is not confidential. i have
taken this tag off these slides.

c u
tom


From owner-mpls@UU.NET  Sun Aug  6 21:05:06 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19663
	for <mpls-archive@lists.ietf.org>; Sun, 6 Aug 2000 21:05:06 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbdk00081;
	Mon, 7 Aug 2000 01:03:16 GMT
Received: by mail-control.mail.uu.net 
	id QQjbdk11505
	for mpls-outgoing; Mon, 7 Aug 2000 01:02:58 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjbdk11356
	for <mpls@mail-control.mail.uu.net>; Mon, 7 Aug 2000 01:02:51 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbdk12894
	for <mpls@uu.net>; Sun, 6 Aug 2000 21:02:44 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjbdk06562
	for <mpls@uu.net>; Mon, 7 Aug 2000 01:02:28 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id VAA29605
	for mpls@uu.net; Sun, 6 Aug 2000 21:02:28 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjbdk07130
	for <mpls@mail-control.mail.uu.net>; Mon, 7 Aug 2000 01:02:11 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjbdk12856
	for <mpls@UU.NET>; Sun, 6 Aug 2000 21:02:03 -0400 (EDT)
Received: from qhars002.nortel.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: qhars002.NortelNetworks.com [192.100.101.19])
	id QQjbdk29261
	for <mpls@UU.NET>; Mon, 7 Aug 2000 01:01:47 GMT
Received: from zhard00m.europe.nortel.com (actually zhard00m) 
          by qhars002.nortel.com; Mon, 7 Aug 2000 01:54:57 +0100
Received: from zvb1c002.corpemea.baynetworks.com ([141.251.160.82]) 
          by zhard00m.europe.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) 
          id PWJG18V8; Mon, 7 Aug 2000 01:54:56 +0100
Received: from nortelnetworks.com (bnw-cnc-77.corpwest.baynetworks.com [134.177.58.77]) 
          by zvb1c002.corpemea.baynetworks.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) 
          id P8TXV2LG; Mon, 7 Aug 2000 02:54:52 +0200
Message-ID: <398E088E.E664B94B@nortelnetworks.com>
Date: Mon, 07 Aug 2000 02:53:34 +0200
X-Sybari-Space: 00000000 00000000 00000000
From: "Loa Andersson" <loa.andersson@nortelnetworks.com>
Organization: Nortel Networks
X-Mailer: Mozilla 4.72 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "David Allan" <dallan@nortelnetworks.com>
CC: Scott Brim <sbrim@cisco.com>, "David R. Oran" <oran@cisco.com>,
        mpls <mpls@UU.NET>, IESG <iesg@ietf.org>, IAB <iab@isi.edu>
Subject: Re: Use of the term "end-to-end"
References: <6DDA62170439D31185750000F80826AC03597F1E@zmerd004.ca.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

This is fine with me, but the last time (back in the childhood of MPLS)
I tried to propose the term LER as part of the MPLS vocabulary it was 
not considered necessary. SO either we add it or use something else.

/Loa

David Allan wrote:
> 
> Agreed
> 
>      -----Original Message-----
>      From:   Scott Brim [SMTP:sbrim@cisco.com]
>      Sent:   Thursday, August 03, 2000 11:37 AM
>      To:     David R. Oran
>      Cc:     mpls; IESG; IAB
>      Subject:        Re: Use of the term "end-to-end"
> 
>      LER-to-LER
> 
>      <snip>

-- 

Loa Andersson
Director Routing Architecture Lab, EMEA
St Eriksgatan 115A, PO Box 6701
113 85 Stockholm, Sweden
phone: +46 8 50 88 36 34,   mobile + 46 70 522 78 34
e-mail: loa.andersson@nortelnetworks.com



From owner-mpls@UU.NET  Mon Aug  7 00:02:09 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24457
	for <mpls-archive@lists.ietf.org>; Mon, 7 Aug 2000 00:02:09 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbdv13565;
	Mon, 7 Aug 2000 03:55:32 GMT
Received: by mail-control.mail.uu.net 
	id QQjbdv14236
	for mpls-outgoing; Mon, 7 Aug 2000 03:54:59 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjbdv14231
	for <mpls@mail-control.mail.uu.net>; Mon, 7 Aug 2000 03:54:56 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjbdv11770
	for <mpls@UU.NET>; Sun, 6 Aug 2000 23:54:44 -0400 (EDT)
Received: from granger.mail.mindspring.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: granger.mail.mindspring.net [207.69.200.148])
	id QQjbdv13034
	for <mpls@UU.NET>; Mon, 7 Aug 2000 03:54:43 GMT
Received: from mindspring.com (user-33qtj97.dialup.mindspring.com [199.174.205.39])
	by granger.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id XAA22334;
	Sun, 6 Aug 2000 23:54:30 -0400 (EDT)
Message-ID: <398E338E.5A90AD2C@mindspring.com>
Date: Sun, 06 Aug 2000 20:57:02 -0700
From: Eric Gray <ewgray@mindspring.com>
Reply-To: ewgray@mindspring.com
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Loa Andersson <loa.andersson@nortelnetworks.com>
CC: David Allan <dallan@nortelnetworks.com>, Scott Brim <sbrim@cisco.com>,
        "David R. Oran" <oran@cisco.com>, mpls <mpls@UU.NET>,
        IESG <iesg@ietf.org>, IAB <iab@isi.edu>
Subject: Re: Use of the term "end-to-end"
References: <6DDA62170439D31185750000F80826AC03597F1E@zmerd004.ca.nortel.com> <398E088E.E664B94B@nortelnetworks.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Loa,

    I distinctly remember your proposing the term and
its more-or-less being rejected.  Never-the-less, it has
come to be accepted as a real term.  Many slides and
charts now contain some subset of this picture:

  LER -- LSR -- ... -- LSR -- LER

While it is still debatable that a box which is exclusively
either an LER or an LSR will be a long-term survivor
in the market place, it is useful to think of LSR verses
LER functionality.

Loa Andersson wrote:

> This is fine with me, but the last time (back in the childhood of MPLS)
> I tried to propose the term LER as part of the MPLS vocabulary it was
> not considered necessary. SO either we add it or use something else.
>
> /Loa
>
> David Allan wrote:
> >
> > Agreed
> >
> >      -----Original Message-----
> >      From:   Scott Brim [SMTP:sbrim@cisco.com]
> >      Sent:   Thursday, August 03, 2000 11:37 AM
> >      To:     David R. Oran
> >      Cc:     mpls; IESG; IAB
> >      Subject:        Re: Use of the term "end-to-end"
> >
> >      LER-to-LER
> >
> >      <snip>
>
> --
>
> Loa Andersson
> Director Routing Architecture Lab, EMEA
> St Eriksgatan 115A, PO Box 6701
> 113 85 Stockholm, Sweden
> phone: +46 8 50 88 36 34,   mobile + 46 70 522 78 34
> e-mail: loa.andersson@nortelnetworks.com



From owner-mpls@UU.NET  Mon Aug  7 04:57:33 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04076
	for <mpls-archive@lists.ietf.org>; Mon, 7 Aug 2000 04:57:33 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbep09461;
	Mon, 7 Aug 2000 08:56:28 GMT
Received: by mail-control.mail.uu.net 
	id QQjbep07457
	for mpls-outgoing; Mon, 7 Aug 2000 08:55:57 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjbep07452
	for <mpls@mail-control.mail.uu.net>; Mon, 7 Aug 2000 08:55:47 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjbep04545
	for <mpls@uu.net>; Mon, 7 Aug 2000 04:55:29 -0400 (EDT)
From: seenu@samsung.co.kr
Received: from omail01.samsung.co.kr by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: omail01.samsung.co.kr [203.254.197.73])
	id QQjbep08700
	for <mpls@uu.net>; Mon, 7 Aug 2000 08:55:28 GMT
Received: from localhost (root@localhost)
	by gp_xman. (8.8.8H1/8.8.8) with ESMTP id RAA18243;
	Mon, 7 Aug 2000 17:56:17 +0900 (KST)
X-OpenMail-Hops: 3
Date: Mon, 7 Aug 2000 17:57:27 +0900
Message-Id: <H0000e6501a35f91.0965638501.secsw0@MHS>
Subject: label encapsulation for LAN media
MIME-Version: 1.0
TO: chetanpinto@hotmail.com, mpls@UU.NET
Content-Type: text/plain; charset=EUC-KR
Content-Disposition: inline; filename="mail.txt"
	;Creation-Date="Mon, 7 Aug 2000 17:55:04 +0900"
	;Modification-Date="Mon, 7 Aug 2000 17:57:21 +0900"
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA04076

Hi,

I have the following doubts on mpls-ethernet.

Draft-ietf-mpls-label-encaps-07.txt  says that the Label Stack (label encapsulation on LAN media) must appear AFTER the data link layer headers, but BEFORE any network layer headers.

But the draft-srinivasan-mpls-lans-label-00.txt says that: (ARIS too)

	The main drawback of using the above approach for label-encapsulation is that accessing the labels requires that the frames be processed by software, reducing the benefit offered by label switching. Alternatively, hardware technology specific to label switching may be developed. However, standardized devices incorporating this technology do not exist today and cannot be built until the MPLS standard becomes stable. 

	And this draft has proposed the use of destination MAC address field for label encapsulation.


Now, my doubts are:

· If one follows the first case (label-encaps-07.txt), how the label swapping will be done (s/w or h/w)
· Is there any ethernet standard (h/w) that supports the above type of switching (label-encaps-07.txt).
· Which is the standard draft that is being followed.
· If any of u have implemented the above, pls help me.


Thanks in advance

regards
seenu


From owner-mpls@UU.NET  Mon Aug  7 04:59:46 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05148
	for <mpls-archive@lists.ietf.org>; Mon, 7 Aug 2000 04:59:46 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbep10471;
	Mon, 7 Aug 2000 08:58:56 GMT
Received: by mail-control.mail.uu.net 
	id QQjbep07620
	for mpls-outgoing; Mon, 7 Aug 2000 08:58:19 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjbep07607
	for <mpls@mail-control.mail.uu.net>; Mon, 7 Aug 2000 08:58:04 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjbep04828
	for <mpls@uu.net>; Mon, 7 Aug 2000 04:57:48 -0400 (EDT)
From: seenu@samsung.co.kr
Received: from omail01.samsung.co.kr by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: omail01.samsung.co.kr [203.254.197.73])
	id QQjbep10088
	for <mpls@uu.net>; Mon, 7 Aug 2000 08:57:47 GMT
Received: from localhost (root@localhost)
	by gp_xman. (8.8.8H1/8.8.8) with ESMTP id RAA20740;
	Mon, 7 Aug 2000 17:58:29 +0900 (KST)
X-OpenMail-Hops: 3
Date: Mon, 7 Aug 2000 17:59:44 +0900
Message-Id: <H0000e6501a35f98.0965638729.secsw0@MHS>
In-Reply-To: <NABBJDOPDKGCDCNBNEDOOEJPCEAA.ybae@cisco.com>
Subject: (Reply) Re: mpls-ethernet
MIME-Version: 1.0
TO: mpls@UU.NET, ybae@cisco.com
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline; filename="mail.txt"
	;Creation-Date="Mon, 7 Aug 2000 17:58:50 +0900"
	;Modification-Date="Mon, 7 Aug 2000 17:59:38 +0900"
Content-Transfer-Encoding: 8bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit

The draft-martini-l2circuit-trans-mpls-02.txt has proposed the use of new Virtual Circuit FEC TLV element for label distribution.
Is it necessary? If so, why has it not been included in the standard mpls draft?

regards
seenu


From owner-mpls@UU.NET  Mon Aug  7 09:05:49 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26098
	for <mpls-archive@lists.ietf.org>; Mon, 7 Aug 2000 09:05:49 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbey11489;
	Mon, 7 Aug 2000 11:02:11 GMT
Received: by mail-control.mail.uu.net 
	id QQjbey13220
	for mpls-outgoing; Mon, 7 Aug 2000 11:01:39 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjbey13160
	for <mpls@mail-control.mail.uu.net>; Mon, 7 Aug 2000 11:01:33 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjbey19419
	for <mpls@UU.NET>; Mon, 7 Aug 2000 07:01:26 -0400 (EDT)
Received: from daewoo.dti.daewoo.co.kr by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [165.133.13.60])
	id QQjbey22371
	for <mpls@UU.NET>; Mon, 7 Aug 2000 11:00:46 GMT
Received: from santosh (santosh [165.133.13.16])
	by daewoo.dti.daewoo.co.kr (8.8.8+Sun/8.8.8) with SMTP id QAA10735
	for <mpls@UU.NET>; Mon, 7 Aug 2000 16:25:13 -0600 (GMT)
Message-ID: <006d01c0005e$a9f05680$100d85a5@dti.daewoo.co.kr>
Reply-To: "Santosh Gupta" <santoshg@daewoo.dti.daewoo.co.kr>
From: "Santosh Gupta" <santoshg@daewoo.dti.daewoo.co.kr>
To: <mpls@UU.NET>
Subject: LDP - Path Vector TLV
Date: Mon, 7 Aug 2000 16:30:10 +0530
Organization: Daewoo Telecom
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_006A_01C0008C.C1A03F60"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_006A_01C0008C.C1A03F60
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello
    I have some doubts regarding Path Vector TLV in LDP. Could someone =
help me.
  1.. Why do we need to have Path Vector TLV in Label Map Message? If we =
follow Downstream On demand Ordered Control Mode of Label Distribution =
then what could be the need for Path Vector TLV in Label Map Message. =
The same path was followed in Request Message.=20
  2.. The only use that I can think of Path Vector TLV in Label Map =
Message is when Egress LER didnt receive any Path Vector TLV/ Hop Count =
TLV so it sends back Label Map message so as to make sure that no loop =
is formed.=20
  3.. There are 2 ways in which an LSR could know it's HopCount. Either =
it receives a Label Request Message which carries it's previous Hop's =
"HopCount" or if it is 0 then the Label Map message ( which comes from =
DownStream peer ) will contain the "HopCount" once this LSP is formed =
till the Egress point. So is the LSR supposed to maintain 2 "HopCount" =
values for different directions?=20
  4.. How can each LSR know the no. of Hops in the LSP? Is it to be made =
from no. of entries in PathVector TLV when in Label Map message or their =
is some other means?
thanx in advance.

santosh


------=_NextPart_000_006A_01C0008C.C1A03F60
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hello</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; I have some doubts =
regarding=20
Path Vector TLV in LDP. Could someone help me.</FONT></DIV>
<OL>
  <LI><FONT face=3DArial size=3D2>Why do we need to have Path Vector TLV =
in Label=20
  Map Message? If we follow Downstream On demand Ordered Control Mode of =
Label=20
  Distribution then what could be the need for Path Vector TLV in Label =
Map=20
  Message. The same path was followed in Request Message. </FONT></LI>
  <LI><FONT face=3DArial size=3D2>The only use that I can think of Path =
Vector TLV=20
  in Label Map Message is when Egress LER didnt receive any Path Vector =
TLV/ Hop=20
  Count TLV so it sends back Label Map message so as to make sure that =
no loop=20
  is formed. </FONT></LI>
  <LI><FONT face=3DArial size=3D2>There are 2 ways in which an LSR could =
know it's=20
  HopCount. Either it receives a Label Request Message which carries =
it's=20
  previous Hop's "HopCount" or if it is 0 then the Label Map message ( =
which=20
  comes from DownStream peer ) will contain the "HopCount" once this LSP =
is=20
  formed till the Egress point. So is the LSR supposed to maintain 2 =
"HopCount"=20
  values for different directions? </FONT></LI>
  <LI><FONT face=3DArial size=3D2>How can each LSR know the no. of Hops =
in the LSP?=20
  Is it to be made from no. of entries in PathVector TLV when in Label =
Map=20
  message or their is some other means?</FONT></LI></OL>
<DIV><FONT face=3DArial size=3D2>thanx in advance.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>santosh</FONT></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_006A_01C0008C.C1A03F60--



From owner-mpls@UU.NET  Mon Aug  7 09:24:31 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07779
	for <mpls-archive@lists.ietf.org>; Mon, 7 Aug 2000 09:24:31 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbfh22806;
	Mon, 7 Aug 2000 13:23:49 GMT
Received: by mail-control.mail.uu.net 
	id QQjbfh19358
	for mpls-outgoing; Mon, 7 Aug 2000 13:23:18 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjbfh19347
	for <mpls@mail-control.mail.uu.net>; Mon, 7 Aug 2000 13:23:04 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbfh08479
	for <mpls@UU.NET>; Mon, 7 Aug 2000 09:22:53 -0400 (EDT)
Received: from web5401.mail.yahoo.com by wodc7mr1.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: web5401.mail.yahoo.com [216.115.106.132])
	id QQjbfh22515
	for <mpls@UU.NET>; Mon, 7 Aug 2000 13:22:52 GMT
Message-ID: <20000807132252.1130.qmail@web5401.mail.yahoo.com>
Received: from [132.177.119.129] by web5401.mail.yahoo.com; Mon, 07 Aug 2000 06:22:52 PDT
Date: Mon, 7 Aug 2000 06:22:52 -0700 (PDT)
From: John Sparr <johnrdb@yahoo.com>
Subject: Re: resource preemption
To: David Charlap <david.charlap@marconi.com>, mpls@UU.NET
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk


Hi David,

Quick question on PathErr message return:

If we just have two RSVP nodes A and B. First A setup
a LSP A---B. And then A want another LSP, also it is
A---B. But there is no available bandwidth exist and
the second LSP can't preempt the first LSP. A PathErr
should be returned back. Since the egress node doesn't
do the compare work, who will do the compare work and
return the PathErr msg back?


Thanks a lot!

Regards
John

--- David Charlap <david.charlap@marconi.com> wrote:
> John Sparr wrote:
> > 
> > It should be that Resv message triggers this
> compare.  But why the
> > draft says "When a path message is considered for
> admission"? (section
> > 4.8.3) It seems when a node received a Path
> message it checks if the
> > bandwidth is avialable. I think the bandwidth
> request should be in
> > Resv message. is that right?
> 
> The actual resources must be reserved and locked
> down while processing
> the Resv message.
> 
> Some hardware and/or software implementation may
> find it useful or
> necessary to reserve (or confirm the availability
> of) resources during
> Path processing.
> 
> It is also, however, reasonable for a switch to just
> record the contents
> of a Path message and do all admission control
> processing when the Resv
> message is processed.
> 
> -- David


__________________________________________________
Do You Yahoo!?
Kick off your party with Yahoo! Invites.
http://invites.yahoo.com/


From owner-mpls@UU.NET  Mon Aug  7 09:52:48 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24970
	for <mpls-archive@lists.ietf.org>; Mon, 7 Aug 2000 09:52:48 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbfj14962;
	Mon, 7 Aug 2000 13:52:47 GMT
Received: by mail-control.mail.uu.net 
	id QQjbfj21118
	for mpls-outgoing; Mon, 7 Aug 2000 13:52:20 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjbfj21107
	for <mpls@mail-control.mail.uu.net>; Mon, 7 Aug 2000 13:52:16 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjbfj21506
	for <mpls@uu.net>; Mon, 7 Aug 2000 09:52:01 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88])
	id QQjbfj13856
	for <mpls@uu.net>; Mon, 7 Aug 2000 13:51:30 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id GAA21621
	for <mpls@uu.net>; Mon, 7 Aug 2000 06:51:47 -0700 (PDT)
Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA02365 for mpls@uu.net; Mon, 7 Aug 2000 09:51:28 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjaul17212
	for <mpls@mail-control.mail.uu.net>; Fri, 4 Aug 2000 14:45:21 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjaul15045
	for <mpls@UU.NET>; Fri, 4 Aug 2000 10:45:13 -0400 (EDT)
Received: from xover.hjinc.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [38.160.241.130])
	id QQjaul21126
	for <mpls@UU.NET>; Fri, 4 Aug 2000 14:45:13 GMT
Received: by xover.hjinc.com with Internet Mail Service (5.5.2650.21)
	id <NYPNXW2W>; Fri, 4 Aug 2000 10:41:10 -0400
Message-ID: <87009604743AD411B1F600508BA0F959040B72@xover.hjinc.com>
From: "Sanford, Bill" <bills@netplane.com>
To: "'John Sparr'" <johnrdb@yahoo.com>
Cc: mpls@UU.NET
Subject: RE: resource preemption
Date: Fri, 4 Aug 2000 10:41:06 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Wouldn't it be the first node that didn't have the bandwidth, wherever it
was?

Bill
-----Original Message-----
From: John Sparr [mailto:johnrdb@yahoo.com]
Sent: Friday, August 04, 2000 10:30 AM
To: mpls@UU.NET
Subject: resource preemption


Hi,

Quick question on resource preemption from RSVP-TE.

In section 4.8.3, it says when a new Path message is
considered for admission, the bandwidth requested is
compared with the bandwidth at the priority specified
in the Setup Priority.

My question is who will do this compare, intermidiate
nodes or receiver?


Thanks in advance
John

__________________________________________________
Do You Yahoo!?
Kick off your party with Yahoo! Invites.
http://invites.yahoo.com/



From owner-mpls@UU.NET  Mon Aug  7 09:53:01 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25113
	for <mpls-archive@lists.ietf.org>; Mon, 7 Aug 2000 09:53:01 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbfj03031;
	Mon, 7 Aug 2000 13:53:01 GMT
Received: by mail-control.mail.uu.net 
	id QQjbfj21121
	for mpls-outgoing; Mon, 7 Aug 2000 13:52:24 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjbfj21111
	for <mpls@mail-control.mail.uu.net>; Mon, 7 Aug 2000 13:52:16 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbfj21510
	for <mpls@uu.net>; Mon, 7 Aug 2000 09:52:01 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11])
	id QQjbfj02384
	for <mpls@uu.net>; Mon, 7 Aug 2000 13:51:45 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id GAA26967
	for <mpls@uu.net>; Mon, 7 Aug 2000 06:52:00 -0700 (PDT)
Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA02369 for mpls@uu.net; Mon, 7 Aug 2000 09:51:43 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjauo02161
	for <mpls@mail-control.mail.uu.net>; Fri, 4 Aug 2000 15:37:26 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjauo26688
	for <mpls@UU.NET>; Fri, 4 Aug 2000 11:37:23 -0400 (EDT)
Received: from xover.hjinc.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [38.160.241.130])
	id QQjauo29718
	for <mpls@UU.NET>; Fri, 4 Aug 2000 15:37:23 GMT
Received: by xover.hjinc.com with Internet Mail Service (5.5.2650.21)
	id <NYPNXWML>; Fri, 4 Aug 2000 11:33:21 -0400
Message-ID: <87009604743AD411B1F600508BA0F959040B73@xover.hjinc.com>
From: "Sanford, Bill" <bills@netplane.com>
To: "'John Sparr'" <johnrdb@yahoo.com>
Cc: mpls@UU.NET
Subject: RE: resource preemption
Date: Fri, 4 Aug 2000 11:33:20 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

John, the setup priority is checked every hop.  Once a hop doesn't have the
bandwidth, the setup priority in the PATH message checks to see if an LSP
with a holding priority lower than itself can be bumped.  Two things can
happen, either the PATH message is refused and a PATH_ERR is sent back to
the Ingress or it bumps an LSP with a lower holding priority and moves
downstream.  The setup priority in the PATH message will most likely do this
multiple times downstream. 

Once the setup priority in the PATH message has successfully got to the
Egress the only priority left is the Holding priority in the LSP just
established. So as far as who will do the compare of the setup priority,
every downsteam node does except the receiver.

-----Original Message-----
From: John Sparr [mailto:johnrdb@yahoo.com]
Sent: Friday, August 04, 2000 10:58 AM
To: Sanford, Bill
Cc: mpls@UU.NET
Subject: RE: resource preemption



Bill,

I agree with you. But I think it should not be
receiver because it just requires BW not allocates. Is
that right?


Thanks in advance
John


--- "Sanford, Bill" <bills@netplane.com> wrote:
> Wouldn't it be the first node that didn't have the
> bandwidth, wherever it
> was?
> 
> Bill
> -----Original Message-----
> From: John Sparr [mailto:johnrdb@yahoo.com]
> Sent: Friday, August 04, 2000 10:30 AM
> To: mpls@UU.NET
> Subject: resource preemption
> 
> 
> Hi,
> 
> Quick question on resource preemption from RSVP-TE.
> 
> In section 4.8.3, it says when a new Path message is
> considered for admission, the bandwidth requested is
> compared with the bandwidth at the priority
> specified
> in the Setup Priority.
> 
> My question is who will do this compare,
> intermidiate
> nodes or receiver?
> 
> 
> Thanks in advance
> John
> 
> __________________________________________________
> Do You Yahoo!?
> Kick off your party with Yahoo! Invites.
> http://invites.yahoo.com/


__________________________________________________
Do You Yahoo!?
Kick off your party with Yahoo! Invites.
http://invites.yahoo.com/



From owner-mpls@UU.NET  Mon Aug  7 09:53:35 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25467
	for <mpls-archive@lists.ietf.org>; Mon, 7 Aug 2000 09:53:35 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbfj15854;
	Mon, 7 Aug 2000 13:53:35 GMT
Received: by mail-control.mail.uu.net 
	id QQjbfj21124
	for mpls-outgoing; Mon, 7 Aug 2000 13:52:27 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjbfj21112
	for <mpls@mail-control.mail.uu.net>; Mon, 7 Aug 2000 13:52:16 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjbfj21502
	for <mpls@uu.net>; Mon, 7 Aug 2000 09:51:59 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88])
	id QQjbfj14291
	for <mpls@uu.net>; Mon, 7 Aug 2000 13:51:58 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id GAA21968
	for <mpls@uu.net>; Mon, 7 Aug 2000 06:52:15 -0700 (PDT)
Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA02375 for mpls@uu.net; Mon, 7 Aug 2000 09:51:57 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjauy22564
	for <mpls@mail-control.mail.uu.net>; Fri, 4 Aug 2000 18:12:47 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjauy05924
	for <mpls@UU.NET>; Fri, 4 Aug 2000 14:12:36 -0400 (EDT)
Received: from xover.hjinc.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [38.160.241.130])
	id QQjauy04747
	for <mpls@UU.NET>; Fri, 4 Aug 2000 18:12:35 GMT
Received: by xover.hjinc.com with Internet Mail Service (5.5.2650.21)
	id <NYPNXWSG>; Fri, 4 Aug 2000 14:08:33 -0400
Message-ID: <87009604743AD411B1F600508BA0F959040B74@xover.hjinc.com>
From: "Sanford, Bill" <bills@netplane.com>
To: "'John Sparr'" <johnrdb@yahoo.com>
Cc: mpls@UU.NET
Subject: RE: resource preemption
Date: Fri, 4 Aug 2000 14:08:28 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

The setup priority and the holding priority are sent downstream in a PATH
message.

Let's say you try to setup yet another LSP with a higher priority then the
last example.  The PATH message will then again look and see if the
bandwidth is available downstream and if not, then look at the active LSPs
to see which one it could bump.  It uses the setup priority in the new PATH
message to compare to the holding priorities of the active LSP's PATH
messages to determine if it can bump an LSP or not.  The LSPs have both
priority fields, but the setup is used actively to determine preemption and
the holding is used passively used to compare if the setup can preempt it.

This comparison stops at the previous hop to the receiver.

-----Original Message-----
From: John Sparr [mailto:johnrdb@yahoo.com]
Sent: Friday, August 04, 2000 12:52 PM
To: Sanford, Bill
Cc: mpls@UU.NET
Subject: RE: resource preemption


Bill,

One more question: what's the meaning of "the only
priority left is the Holding priority in the LSP just
established" ?  It seems that the Setup priority is
reset or what others? My understanding is right?

Thanks
John

--- "Sanford, Bill" <bills@netplane.com> wrote:
> John, the setup priority is checked every hop.  Once
> a hop doesn't have the
> bandwidth, the setup priority in the PATH message
> checks to see if an LSP
> with a holding priority lower than itself can be
> bumped.  Two things can
> happen, either the PATH message is refused and a
> PATH_ERR is sent back to
> the Ingress or it bumps an LSP with a lower holding
> priority and moves
> downstream.  The setup priority in the PATH message
> will most likely do this
> multiple times downstream. 
> 
> Once the setup priority in the PATH message has
> successfully got to the
> Egress the only priority left is the Holding
> priority in the LSP just
> established. So as far as who will do the compare of
> the setup priority,
> every downsteam node does except the receiver.
> 
> -----Original Message-----
> From: John Sparr [mailto:johnrdb@yahoo.com]
> Sent: Friday, August 04, 2000 10:58 AM
> To: Sanford, Bill
> Cc: mpls@UU.NET
> Subject: RE: resource preemption
> 
> 
> 
> Bill,
> 
> I agree with you. But I think it should not be
> receiver because it just requires BW not allocates.
> Is
> that right?
> 
> 
> Thanks in advance
> John
> 
> 
> --- "Sanford, Bill" <bills@netplane.com> wrote:
> > Wouldn't it be the first node that didn't have the
> > bandwidth, wherever it
> > was?
> > 
> > Bill
> > -----Original Message-----
> > From: John Sparr [mailto:johnrdb@yahoo.com]
> > Sent: Friday, August 04, 2000 10:30 AM
> > To: mpls@UU.NET
> > Subject: resource preemption
> > 
> > 
> > Hi,
> > 
> > Quick question on resource preemption from
> RSVP-TE.
> > 
> > In section 4.8.3, it says when a new Path message
> is
> > considered for admission, the bandwidth requested
> is
> > compared with the bandwidth at the priority
> > specified
> > in the Setup Priority.
> > 
> > My question is who will do this compare,
> > intermidiate
> > nodes or receiver?
> > 
> > 
> > Thanks in advance
> > John
> > 
> > __________________________________________________
> > Do You Yahoo!?
> > Kick off your party with Yahoo! Invites.
> > http://invites.yahoo.com/
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Kick off your party with Yahoo! Invites.
> http://invites.yahoo.com/


__________________________________________________
Do You Yahoo!?
Kick off your party with Yahoo! Invites.
http://invites.yahoo.com/



From owner-mpls@UU.NET  Mon Aug  7 10:50:06 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26740
	for <mpls-archive@lists.ietf.org>; Mon, 7 Aug 2000 10:50:05 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbfn26454;
	Mon, 7 Aug 2000 14:50:05 GMT
Received: by mail-control.mail.uu.net 
	id QQjbfn05789
	for mpls-outgoing; Mon, 7 Aug 2000 14:49:45 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjbfn05776
	for <mpls@mail-control.mail.uu.net>; Mon, 7 Aug 2000 14:49:41 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjbfn01912
	for <mpls@UU.NET>; Mon, 7 Aug 2000 10:49:36 -0400 (EDT)
Received: from zrtps06s.us.nortel.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [47.140.48.50])
	id QQjbfn28494
	for <mpls@UU.NET>; Mon, 7 Aug 2000 14:49:36 GMT
Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com;
          Mon, 7 Aug 2000 10:48:11 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <P4SVNMCZ>; Mon, 7 Aug 2000 10:48:10 -0400
Message-ID: <F033F6FEF3F1D111BD150000F8CD14310460EEBF@zcard007.ca.nortel.com>
From: "Don Fedyk" <dwfedyk@nortelnetworks.com>
To: David Charlap <david.charlap@marconi.com>, mpls@UU.NET
Subject: RE: resource preemption
Date: Mon, 7 Aug 2000 10:48:07 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0007E.7FB520B0"
X-Orig: <dwfedyk@americasm01.nt.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

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_01C0007E.7FB520B0
Content-Type: text/plain;
	charset="iso-8859-1"

David Charlap wrote:

> 
> It is also, however, reasonable for a switch to just record 
> the contents
> of a Path message and do all admission control processing 
> when the Resv
> message is processed.
> 
> -- David
> 

Reasonable ? What happens when you have to unwind the path 
because the Resv fails ?  Seems like a lot of work that 
could easily have been avoided.

It may be what the spec says, but it is not optimal.

Don

------_=_NextPart_001_01C0007E.7FB520B0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: resource preemption</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>David Charlap wrote:</FONT>
</P>

<P><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; It is also, however, reasonable for a switch to just record </FONT>
<BR><FONT SIZE=2>&gt; the contents</FONT>
<BR><FONT SIZE=2>&gt; of a Path message and do all admission control processing </FONT>
<BR><FONT SIZE=2>&gt; when the Resv</FONT>
<BR><FONT SIZE=2>&gt; message is processed.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; -- David</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

<P><FONT SIZE=2>Reasonable ? What happens when you have to unwind the path </FONT>
<BR><FONT SIZE=2>because the Resv fails ?&nbsp; Seems like a lot of work that </FONT>
<BR><FONT SIZE=2>could easily have been avoided.</FONT>
</P>

<P><FONT SIZE=2>It may be what the spec says, but it is not optimal.</FONT>
</P>

<P><FONT SIZE=2>Don</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0007E.7FB520B0--


From owner-mpls@UU.NET  Mon Aug  7 11:01:31 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03841
	for <mpls-archive@lists.ietf.org>; Mon, 7 Aug 2000 11:01:31 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbfo01208;
	Mon, 7 Aug 2000 15:01:31 GMT
Received: by mail-control.mail.uu.net 
	id QQjbfo09245
	for mpls-outgoing; Mon, 7 Aug 2000 15:01:05 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjbfo09027
	for <mpls@mail-control.mail.uu.net>; Mon, 7 Aug 2000 15:00:56 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjbfo26863
	for <mpls@uu.net>; Mon, 7 Aug 2000 11:00:50 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQjbfo06953
	for <mpls@uu.net>; Mon, 7 Aug 2000 15:00:50 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA06420
	for <mpls@uu.net>; Mon, 7 Aug 2000 11:00:48 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA04367
	for <mpls@uu.net>; Mon, 7 Aug 2000 11:00:44 -0400 (EDT)
Message-ID: <398ECF57.FCF4A714@marconi.com>
Date: Mon, 07 Aug 2000 11:01:43 -0400
From: David Charlap <david.charlap@marconi.com>
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: resource preemption
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Don Fedyk wrote:
> David Charlap wrote:
>>
>> It is also, however, reasonable for a switch to just record the
>> contents of a Path message and do all admission control processing
>> when the Resv message is processed.
> 
> Reasonable ? What happens when you have to unwind the path
> because the Resv fails ?  Seems like a lot of work that
> could easily have been avoided.
> 
> It may be what the spec says, but it is not optimal.

As opposed to reserving resources before you know whether the path
signalled will even reach its destination?

There are justifiable reasons for both models.  The decision of which
one to choose is as much religious as it is technical.

-- David


From owner-mpls@UU.NET  Mon Aug  7 11:53:42 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06338
	for <mpls-archive@lists.ietf.org>; Mon, 7 Aug 2000 11:53:42 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbfr23707;
	Mon, 7 Aug 2000 15:53:28 GMT
Received: by mail-control.mail.uu.net 
	id QQjbfr21386
	for mpls-outgoing; Mon, 7 Aug 2000 15:52:56 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjbfr21380
	for <mpls@mail-control.mail.uu.net>; Mon, 7 Aug 2000 15:52:48 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjbfr07206
	for <mpls@uu.net>; Mon, 7 Aug 2000 11:52:20 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjbfr16160
	for <mpls@uu.net>; Mon, 7 Aug 2000 15:51:49 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA27943
	for mpls@uu.net; Mon, 7 Aug 2000 11:51:48 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjbfr21258
	for <mpls@mail-control.mail.uu.net>; Mon, 7 Aug 2000 15:51:23 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjbfr07041
	for <mpls@UU.NET>; Mon, 7 Aug 2000 11:51:09 -0400 (EDT)
Received: from qhars002.nortel.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: qhars002.NortelNetworks.com [192.100.101.19])
	id QQjbfr15645
	for <mpls@UU.NET>; Mon, 7 Aug 2000 15:51:04 GMT
Received: from zhard00d.europe.nortel.com (actually zhard00d) 
          by qhars002.nortel.com; Mon, 7 Aug 2000 16:37:24 +0100
Received: from zvb1c002.corpemea.baynetworks.com ([141.251.160.82]) 
          by zhard00d.europe.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) 
          id PHRZ63SZ; Mon, 7 Aug 2000 16:37:24 +0100
Received: from nortelnetworks.com (dhcp225-233.engeast.baynetworks.com [192.32.225.233]) 
          by zvb1c002.corpemea.baynetworks.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) 
          id P8TXV2ZF; Mon, 7 Aug 2000 17:37:21 +0200
Message-ID: <398ED764.CF7A7AC8@nortelnetworks.com>
Date: Mon, 07 Aug 2000 17:36:04 +0200
X-Sybari-Space: 00000000 00000000 00000000
From: "Loa Andersson" <loa.andersson@nortelnetworks.com>
Organization: Nortel Networks
X-Mailer: Mozilla 4.72 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: ewgray@mindspring.com
CC: "Loa Andersson" <loa.andersson@nortelnetworks.com>,
        "David Allan" <dallan@nortelnetworks.com>,
        Scott Brim <sbrim@cisco.com>, "David R. Oran" <oran@cisco.com>,
        mpls <mpls@UU.NET>, IESG <iesg@ietf.org>, IAB <iab@isi.edu>
Subject: Re: Use of the term "end-to-end"
References: <6DDA62170439D31185750000F80826AC03597F1E@zmerd004.ca.nortel.com> <398E088E.E664B94B@nortelnetworks.com> <398E338E.5A90AD2C@mindspring.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Eric,

well yes! And it was precisely the argument - no boxes will do only
LER functionality in the long run, so they will all be LSRs anyway.
So what I proposed was "a functional group" called LER and another
called LSR for network modeling purposes. But it was felt that that
level of abstraction wasn't needed, but it seems that it is.

So any of the architecture people care to put it in?

/Loa

Eric Gray wrote:
> 
> Loa,
> 
>     I distinctly remember your proposing the term and
> its more-or-less being rejected.  Never-the-less, it has
> come to be accepted as a real term.  Many slides and
> charts now contain some subset of this picture:
> 
>   LER -- LSR -- ... -- LSR -- LER
> 
> While it is still debatable that a box which is exclusively
> either an LER or an LSR will be a long-term survivor
> in the market place, it is useful to think of LSR verses
> LER functionality.
> 
> Loa Andersson wrote:
> 
> > This is fine with me, but the last time (back in the childhood of MPLS)
> > I tried to propose the term LER as part of the MPLS vocabulary it was
> > not considered necessary. SO either we add it or use something else.
> >
> > /Loa
> >
> > David Allan wrote:
> > >
> > > Agreed
> > >
> > >      -----Original Message-----
> > >      From:   Scott Brim [SMTP:sbrim@cisco.com]
> > >      Sent:   Thursday, August 03, 2000 11:37 AM
> > >      To:     David R. Oran
> > >      Cc:     mpls; IESG; IAB
> > >      Subject:        Re: Use of the term "end-to-end"
> > >
> > >      LER-to-LER
> > >
> > >      <snip>
> >
> > --
> >
> > Loa Andersson
> > Director Routing Architecture Lab, EMEA
> > St Eriksgatan 115A, PO Box 6701
> > 113 85 Stockholm, Sweden
> > phone: +46 8 50 88 36 34,   mobile + 46 70 522 78 34
> > e-mail: loa.andersson@nortelnetworks.com

-- 

Loa Andersson
Director Routing Architecture Lab, EMEA
St Eriksgatan 115A, PO Box 6701
113 85 Stockholm, Sweden
phone: +46 8 50 88 36 34,   mobile + 46 70 522 78 34
e-mail: loa.andersson@nortelnetworks.com



From owner-mpls@UU.NET  Mon Aug  7 12:54:07 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09621
	for <mpls-archive@lists.ietf.org>; Mon, 7 Aug 2000 12:54:06 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbfv02137;
	Mon, 7 Aug 2000 16:53:54 GMT
Received: by mail-control.mail.uu.net 
	id QQjbfv06683
	for mpls-outgoing; Mon, 7 Aug 2000 16:53:17 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjbfv06677
	for <mpls@mail-control.mail.uu.net>; Mon, 7 Aug 2000 16:53:06 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbfv24537
	for <mpls@UU.NET>; Mon, 7 Aug 2000 12:52:47 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11])
	id QQjbfv15323
	for <mpls@UU.NET>; Mon, 7 Aug 2000 16:52:32 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id JAA06013;
	Mon, 7 Aug 2000 09:51:44 -0700 (PDT)
Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id MAA03316; Mon, 7 Aug 2000 12:51:26 -0400 (EDT)
Message-Id: <200008071651.MAA03316@erosen-sun.cisco.com>
X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs
To: "Loa Andersson" <loa.andersson@nortelnetworks.com>
cc: ewgray@mindspring.com, "David Allan" <dallan@nortelnetworks.com>,
        Scott Brim <sbrim@cisco.com>, "David R. Oran" <oran@cisco.com>,
        mpls <mpls@UU.NET>, IESG <iesg@ietf.org>, IAB <iab@isi.edu>
Subject: Re: Use of the term "end-to-end" 
In-reply-to: Your message of Mon, 07 Aug 2000 17:36:04 +0200.
             <398ED764.CF7A7AC8@nortelnetworks.com> 
Reply-To: erosen@cisco.com
User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1
 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1)
 MULE/4.0 (HANANOEN)
MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune")
Content-Type: text/plain; charset=US-ASCII
Date: Mon, 07 Aug 2000 12:51:26 -0400
From: Eric Rosen <erosen@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

I have to say  that I don't see what the problem is.  Or rather, I don't see
that  there   is  a   problem  which  requires   any  modification   of  the
specifications. 

I don't think that "end-to-end" is used  in any of the MPLS documents, and I
believe  that  those documents  contain  terminology  which  is adequate  to
precisely state any necessary concepts.

In discussing MPLS, the term  "end-to-end" is sometimes used colloquially in
contexts  where it is  clear to  most that  it doesn't  mean "host-to-host".
Dave might be  right to deplore this usage.   However, increasing the number
of precisely  defined terms and acronyms  will not do anything  to stamp out
such colloquialisms. 



From owner-mpls@UU.NET  Mon Aug  7 13:24:03 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26062
	for <mpls-archive@lists.ietf.org>; Mon, 7 Aug 2000 13:24:02 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbfx26773;
	Mon, 7 Aug 2000 17:23:54 GMT
Received: by mail-control.mail.uu.net 
	id QQjbfx19427
	for mpls-outgoing; Mon, 7 Aug 2000 17:23:20 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjbfx19422
	for <mpls@mail-control.mail.uu.net>; Mon, 7 Aug 2000 17:23:06 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjbfx29070
	for <mpls@uu.net>; Mon, 7 Aug 2000 13:22:45 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjbfx22148
	for <mpls@uu.net>; Mon, 7 Aug 2000 17:22:44 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA11569
	for mpls@uu.net; Mon, 7 Aug 2000 13:22:44 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjbfx19325
	for <mpls@mail-control.mail.uu.net>; Mon, 7 Aug 2000 17:22:21 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjbfx29026
	for <mpls@uu.net>; Mon, 7 Aug 2000 13:21:58 -0400 (EDT)
Received: from tnnt3.tachion.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [198.139.117.130])
	id QQjbfx21324
	for <mpls@uu.net>; Mon, 7 Aug 2000 17:21:27 GMT
Received: by TNNT3 with Internet Mail Service (5.5.2650.21)
	id <PL7F44Z5>; Mon, 7 Aug 2000 13:24:55 -0400
Message-ID: <A64EB7AC0201D411B864009027DC856C0D8331@TNNT3>
From: Jane Chen <jchen@tachion.com>
To: "'mpls@uu.net'" <mpls@UU.NET>
Subject: subscribe
Date: Mon, 7 Aug 2000 13:24:47 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C00094.668CB592"
Sender: owner-mpls@UU.NET
Precedence: bulk

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_01C00094.668CB592
Content-Type: text/plain;
	charset="iso-8859-1"

subscribe

------_=_NextPart_001_01C00094.668CB592
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2650.12">
<TITLE>subscribe</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2 FACE="Arial">subscribe</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C00094.668CB592--



From owner-mpls@UU.NET  Mon Aug  7 14:33:22 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09810
	for <mpls-archive@lists.ietf.org>; Mon, 7 Aug 2000 14:33:22 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbgc25244;
	Mon, 7 Aug 2000 18:32:58 GMT
Received: by mail-control.mail.uu.net 
	id QQjbgc05198
	for mpls-outgoing; Mon, 7 Aug 2000 18:32:36 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjbgc05193
	for <mpls@mail-control.mail.uu.net>; Mon, 7 Aug 2000 18:32:31 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjbgc11504
	for <mpls@uu.net>; Mon, 7 Aug 2000 14:32:16 -0400 (EDT)
Received: from ziggy.stardust.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ns.stardust.com [205.184.205.34])
	id QQjbgc13547
	for <mpls@uu.net>; Mon, 7 Aug 2000 18:32:15 GMT
Received: from pleiades (dhcp204-96.stardust.com [205.184.204.96])
	by ziggy.stardust.com (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA28487
	for <mpls@uu.net>; Mon, 7 Aug 2000 11:29:41 -0700
Message-Id: <3.0.5.32.20000807112943.01434ab0@stardust.com>
X-Sender: jasonu@stardust.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Mon, 07 Aug 2000 11:29:43 -0700
To: mpls@UU.NET
From: Jason Utz <jasonu@stardust.com>
Subject: Call for MPLS and DiffServ papers - iBAND at ISPCON
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA09810

Greetings!

MPLS and DiffServ are some of the core technologies covered at the iBAND
events. We would like to continue its progress at the upcoming iBAND at
ISPCON Conference on November 8-10, 2000, in San Jose, CA. iBAND at ISPCON
is a gathering place for key industry people to come together and learn
about developments in the new Internet technologies:

* Service Provisioning * Traffic Management * Performance Measurement *

Your iBAND at ISPCON participation will help expose network engineers and
other technology savvy professionals to the latest and greatest in MPLS and
DiffServ technology.
 
My name is Jason Utz, conference manager for iBAND at ISPCON Conference.
Stardust.com's CTO Martin Hall and I would like to invite you to share you
progress and ideas with other relevant professionals in one or more ways:

· Speaker Proposal * BOF Proposal * Showcase Participation *

We value your expertise and look forward to receiving your speaker
proposals to reflect the state of the art in MPLS and DiffServ technology.
Proposals are due no later than Friday, August 18, 2000. To find guidance
and more information, please visit 

http://www.stardust.com/iband5/speakers.htm

http://www.stardust.com for network engineers offers additional
opportunities to supply information and progress for MPLS and DiffServ
updates and technologies:

- conference sessions available in MP3 format,
- live interviews on Stardust.com TalkRadio,
- provide white papers and have them maintained in a Stardust.com Web library.

All these options provide you with a large arena to deliver your working
group's information and other updates. Please visit http://www.stardust.com
to see what our site offers to its visitors.

We want to help you drive this technology area forward so please let me
know how you'd like to participate. Please contact me via email with any
questions.


Best regards,

Jason Utz
Conference Manager
Stardust.com
Jasonu@stardust.com
www.stardust.com

***************** Stardust.com*********************
	            Visit Stardust.com
	       http://www.stardust.com
	   Making sense of new Internet stuff
    Visit Stardust Talkradio Mondays in MP3 Format!
***************************************************
Home of the IP Multicast Initiative (IPMI)
the QoS Forum (QOSF) and the
Wireless Multimedia Forum (WMF) NEW!
***************************************************
UPCOMING EVENTS:
*iBAND at ISPCON - Nov. 8-10, 2000, San Jose, CA
*WISE, The Wireless Internet Services Event - Nov. 6-7, San Jose, CA
*****************************************************
Jason Utz          
Conference Manager

15575 Los Gatos Blvd Suite C        Fax  408/402-0567
Los Gatos, CA 95032 


From owner-mpls@UU.NET  Mon Aug  7 14:37:05 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12117
	for <mpls-archive@lists.ietf.org>; Mon, 7 Aug 2000 14:37:04 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbgc16893;
	Mon, 7 Aug 2000 18:36:51 GMT
Received: by mail-control.mail.uu.net 
	id QQjbgc05437
	for mpls-outgoing; Mon, 7 Aug 2000 18:36:27 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjbgc05432
	for <mpls@mail-control.mail.uu.net>; Mon, 7 Aug 2000 18:36:25 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjbgc12137
	for <mpls@UU.NET>; Mon, 7 Aug 2000 14:36:10 -0400 (EDT)
Received: from rottweiler.cwusa.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rottweiler-dmz.cwusa.com [146.135.88.50])
	id QQjbgc16308
	for <mpls@UU.NET>; Mon, 7 Aug 2000 18:36:10 GMT
Received: from us-cwi-exc-a10.cwusa.com (us-cwi-exc-a10.cwusa.com [146.135.85.143])
	by rottweiler.cwusa.com (8.9.1/8.9.1) with ESMTP id OAA28877;
	Mon, 7 Aug 2000 14:31:58 -0400 (EDT)
Received: by us-cwi-exc-a10.cwi.cablew.com with Internet Mail Service (5.5.2650.21)
	id <Q1DNX7AR>; Mon, 7 Aug 2000 14:31:57 -0400
Message-ID: <3BDB6337A881D311BDB20008C7EBB2E9D477FA@us-cwi-exc-a09.cwi.cablew.com>
From: "Mohan, Ram" <Ram.Mohan@CWUSA.COM>
To: "'erosen@cisco.com'" <erosen@cisco.com>,
        Loa Andersson
	 <loa.andersson@nortelnetworks.com>
Cc: ewgray@mindspring.com, David Allan <dallan@nortelnetworks.com>,
        Scott Brim <sbrim@cisco.com>, "David R. Oran" <oran@cisco.com>,
        mpls
	 <mpls@UU.NET>, IESG <iesg@ietf.org>, IAB <iab@isi.edu>
Subject: RE: Use of the term "end-to-end" 
Date: Mon, 7 Aug 2000 14:31:51 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

In the MPLS scenario, does end-to-end mean edge router-to-edge router in an
IP backbone network or customer-premise router-to-customer premise router?
My assumption is that in a service provider environment, a customer premise
router connects to an edge router or aggregation router, which is basically
a provider edge router.  If anyone could kindly clarify this, I'd really
appreciate it.  Thanks again.

-----Original Message-----
From: Eric Rosen [mailto:erosen@cisco.com]
Sent: Monday, August 07, 2000 12:51 PM
To: Loa Andersson
Cc: ewgray@mindspring.com; David Allan; Scott Brim; David R. Oran; mpls;
IESG; IAB
Subject: Re: Use of the term "end-to-end" 


I have to say  that I don't see what the problem is.  Or rather, I don't see
that  there   is  a   problem  which  requires   any  modification   of  the
specifications. 

I don't think that "end-to-end" is used  in any of the MPLS documents, and I
believe  that  those documents  contain  terminology  which  is adequate  to
precisely state any necessary concepts.

In discussing MPLS, the term  "end-to-end" is sometimes used colloquially in
contexts  where it is  clear to  most that  it doesn't  mean "host-to-host".
Dave might be  right to deplore this usage.   However, increasing the number
of precisely  defined terms and acronyms  will not do anything  to stamp out
such colloquialisms. 


From owner-mpls@UU.NET  Mon Aug  7 15:46:26 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24471
	for <mpls-archive@lists.ietf.org>; Mon, 7 Aug 2000 15:46:25 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbgh23782;
	Mon, 7 Aug 2000 19:46:22 GMT
Received: by mail-control.mail.uu.net 
	id QQjbgh21523
	for mpls-outgoing; Mon, 7 Aug 2000 19:45:49 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjbgh21516
	for <mpls@mail-control.mail.uu.net>; Mon, 7 Aug 2000 19:45:44 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjbgh19273
	for <mpls@uu.net>; Mon, 7 Aug 2000 15:45:30 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjbgh07221
	for <mpls@uu.net>; Mon, 7 Aug 2000 19:45:29 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA03291
	for mpls@uu.net; Mon, 7 Aug 2000 15:45:29 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjbgg21299
	for <mpls@mail-control.mail.uu.net>; Mon, 7 Aug 2000 19:44:57 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjbgg24265
	for <mpls@UU.NET>; Mon, 7 Aug 2000 15:44:43 -0400 (EDT)
Received: from volsung.pluris.COM by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pluris.com [208.227.9.12])
	id QQjbgg06644
	for <mpls@UU.NET>; Mon, 7 Aug 2000 19:44:43 GMT
Received: from pluris.com (IDENT:akyol@akyol [127.0.0.1])
	by volsung.pluris.COM (8.9.3/8.9.3) with ESMTP id MAA01616;
	Mon, 7 Aug 2000 12:44:57 -0700
Message-ID: <398F11B9.3202CA1C@pluris.com>
Date: Mon, 07 Aug 2000 12:44:57 -0700
From: Bora Akyol <akyol@pluris.com>
Reply-To: akyol@pluris.com
X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.16-3 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: seenu@samsung.co.kr
CC: chetanpinto@hotmail.com, mpls@UU.NET
Subject: Re: label encapsulation for LAN media
References: <H0000e6501a35f91.0965638501.secsw0@MHS>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

seenu@samsung.co.kr wrote:

> Hi,
>
> I have the following doubts on mpls-ethernet.
>
> Draft-ietf-mpls-label-encaps-07.txt  says that the Label Stack (label encapsulation on LAN media) must appear AFTER the data link layer headers, but BEFORE any network layer headers.
>
> But the draft-srinivasan-mpls-lans-label-00.txt says that: (ARIS too)
>
>         The main drawback of using the above approach for label-encapsulation is that accessing the labels requires that the frames be processed by software, reducing the benefit offered by label switching. Alternatively, hardware technology specific to label switching may be developed. However, standardized devices incorporating this technology do not exist today and cannot be built until the MPLS standard becomes stable.
>
>         And this draft has proposed the use of destination MAC address field for label encapsulation.
>
> Now, my doubts are:
>
> ? If one follows the first case (label-encaps-07.txt), how the label swapping will be done (s/w or h/w)
> ? Is there any ethernet standard (h/w) that supports the above type of switching (label-encaps-07.txt).
> ? Which is the standard draft that is being followed.
> ? If any of u have implemented the above, pls help me.
>
> Thanks in advance
>
> regards
> seenu

I haven't read this draft, but I see no reason why having the shime header between IP and Ethernet headers would cause packets to be processed in SW.

Bora





From owner-mpls@UU.NET  Mon Aug  7 17:37:05 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19493
	for <mpls-archive@lists.ietf.org>; Mon, 7 Aug 2000 17:37:04 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbgo27170;
	Mon, 7 Aug 2000 21:37:03 GMT
Received: by mail-control.mail.uu.net 
	id QQjbgo21362
	for mpls-outgoing; Mon, 7 Aug 2000 21:36:31 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjbgo21357
	for <mpls@mail-control.mail.uu.net>; Mon, 7 Aug 2000 21:36:24 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbgo09061
	for <mpls@UU.NET>; Mon, 7 Aug 2000 17:36:16 -0400 (EDT)
Received: from exchsrv1.cosinecom.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail.cosinecom.com [63.88.104.16])
	id QQjbgo04329
	for <mpls@UU.NET>; Mon, 7 Aug 2000 21:36:00 GMT
Received: by exchsrv1.cosinecom.com with Internet Mail Service (5.5.2650.21)
	id <PYRGRMTS>; Mon, 7 Aug 2000 14:35:36 -0700
Message-ID: <7EB7C6B62C4FD41196A80090279A29110BD780@exchsrv1.cosinecom.com>
From: Anoop Ghanwani <anoop@cosinecom.com>
To: "'seenu@samsung.co.kr'" <seenu@samsung.co.kr>, chetanpinto@hotmail.com,
        mpls@UU.NET
Subject: RE: label encapsulation for LAN media
Date: Mon, 7 Aug 2000 14:35:28 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C000B7.677E27B0"
Sender: owner-mpls@UU.NET
Precedence: bulk

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_01C000B7.677E27B0
Content-Type: text/plain;
	charset="KS_C_5601-1987"

Seenu,

The standard for MPLS over Ethernet media is the one specified
in draft-ietf-mpls-label-encaps-07.txt.  The one presented in
draft-srinivasan-mpls-lans-label-00.txt had some issues that
needed to be addressed with regard to  bridge learning.
As such we decided not to pursue it, and the draft has since
expired.

-Anoop

> -----Original Message-----
> From: seenu@samsung.co.kr [mailto:seenu@samsung.co.kr]
> Sent: Monday, August 07, 2000 1:57 AM
> To: chetanpinto@hotmail.com; mpls@UU.NET
> Subject: label encapsulation for LAN media
> 
> 
> Hi,
> 
> I have the following doubts on mpls-ethernet.
> 
> Draft-ietf-mpls-label-encaps-07.txt  says that the Label 
> Stack (label encapsulation on LAN media) must appear AFTER 
> the data link layer headers, but BEFORE any network layer headers.
> 
> But the draft-srinivasan-mpls-lans-label-00.txt says that: (ARIS too)
> 
> 	The main drawback of using the above approach for 
> label-encapsulation is that accessing the labels requires 
> that the frames be processed by software, reducing the 
> benefit offered by label switching. Alternatively, hardware 
> technology specific to label switching may be developed. 
> However, standardized devices incorporating this technology 
> do not exist today and cannot be built until the MPLS 
> standard becomes stable. 
> 
> 	And this draft has proposed the use of destination MAC 
> address field for label encapsulation.
> 
> 
> Now, my doubts are:
> 
> ? If one follows the first case (label-encaps-07.txt), how 
> the label swapping will be done (s/w or h/w)
> ? Is there any ethernet standard (h/w) that supports the 
> above type of switching (label-encaps-07.txt).
> ? Which is the standard draft that is being followed.
> ? If any of u have implemented the above, pls help me.
> 
> 
> Thanks in advance
> 
> regards
> seenu
> 

------_=_NextPart_001_01C000B7.677E27B0
Content-Type: text/html;
	charset="KS_C_5601-1987"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=KS_C_5601-1987">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: label encapsulation for LAN media</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Seenu,</FONT>
</P>

<P><FONT SIZE=2>The standard for MPLS over Ethernet media is the one specified</FONT>
<BR><FONT SIZE=2>in draft-ietf-mpls-label-encaps-07.txt.&nbsp; The one presented in</FONT>
<BR><FONT SIZE=2>draft-srinivasan-mpls-lans-label-00.txt had some issues that</FONT>
<BR><FONT SIZE=2>needed to be addressed with regard to&nbsp; bridge learning.</FONT>
<BR><FONT SIZE=2>As such we decided not to pursue it, and the draft has since</FONT>
<BR><FONT SIZE=2>expired.</FONT>
</P>

<P><FONT SIZE=2>-Anoop</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: seenu@samsung.co.kr [<A HREF="mailto:seenu@samsung.co.kr">mailto:seenu@samsung.co.kr</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Monday, August 07, 2000 1:57 AM</FONT>
<BR><FONT SIZE=2>&gt; To: chetanpinto@hotmail.com; mpls@UU.NET</FONT>
<BR><FONT SIZE=2>&gt; Subject: label encapsulation for LAN media</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Hi,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I have the following doubts on mpls-ethernet.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Draft-ietf-mpls-label-encaps-07.txt&nbsp; says that the Label </FONT>
<BR><FONT SIZE=2>&gt; Stack (label encapsulation on LAN media) must appear AFTER </FONT>
<BR><FONT SIZE=2>&gt; the data link layer headers, but BEFORE any network layer headers.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; But the draft-srinivasan-mpls-lans-label-00.txt says that: (ARIS too)</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The main drawback of using the above approach for </FONT>
<BR><FONT SIZE=2>&gt; label-encapsulation is that accessing the labels requires </FONT>
<BR><FONT SIZE=2>&gt; that the frames be processed by software, reducing the </FONT>
<BR><FONT SIZE=2>&gt; benefit offered by label switching. Alternatively, hardware </FONT>
<BR><FONT SIZE=2>&gt; technology specific to label switching may be developed. </FONT>
<BR><FONT SIZE=2>&gt; However, standardized devices incorporating this technology </FONT>
<BR><FONT SIZE=2>&gt; do not exist today and cannot be built until the MPLS </FONT>
<BR><FONT SIZE=2>&gt; standard becomes stable. </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; And this draft has proposed the use of destination MAC </FONT>
<BR><FONT SIZE=2>&gt; address field for label encapsulation.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Now, my doubts are:</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; ? If one follows the first case (label-encaps-07.txt), how </FONT>
<BR><FONT SIZE=2>&gt; the label swapping will be done (s/w or h/w)</FONT>
<BR><FONT SIZE=2>&gt; ? Is there any ethernet standard (h/w) that supports the </FONT>
<BR><FONT SIZE=2>&gt; above type of switching (label-encaps-07.txt).</FONT>
<BR><FONT SIZE=2>&gt; ? Which is the standard draft that is being followed.</FONT>
<BR><FONT SIZE=2>&gt; ? If any of u have implemented the above, pls help me.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Thanks in advance</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; regards</FONT>
<BR><FONT SIZE=2>&gt; seenu</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C000B7.677E27B0--


From owner-mpls@UU.NET  Mon Aug  7 18:05:06 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03763
	for <mpls-archive@lists.ietf.org>; Mon, 7 Aug 2000 18:05:05 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbgq13736;
	Mon, 7 Aug 2000 22:05:04 GMT
Received: by mail-control.mail.uu.net 
	id QQjbgq04029
	for mpls-outgoing; Mon, 7 Aug 2000 22:04:30 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjbgq04021
	for <mpls@mail-control.mail.uu.net>; Mon, 7 Aug 2000 22:04:22 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjbgq13465
	for <mpls@uu.net>; Mon, 7 Aug 2000 18:04:10 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjbgq15256
	for <mpls@uu.net>; Mon, 7 Aug 2000 22:03:39 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id SAA21938
	for mpls@uu.net; Mon, 7 Aug 2000 18:03:39 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjbgq29059
	for <mpls@mail-control.mail.uu.net>; Mon, 7 Aug 2000 22:02:22 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjbgq16415
	for <mpls@UU.NET>; Mon, 7 Aug 2000 18:02:02 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11])
	id QQjbgq14145
	for <mpls@UU.NET>; Mon, 7 Aug 2000 22:01:47 GMT
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id PAA06706;
	Mon, 7 Aug 2000 15:01:00 -0700 (PDT)
Received: from sbrim-nt.cisco.com ([10.82.192.5])
	by airborne.cisco.com (Mirapoint)
	with ESMTP id AAD00801;
	Mon, 7 Aug 2000 15:00:36 -0700 (PDT)
Message-Id: <4.3.2.7.2.20000807174655.00b1f100@airborne.cisco.com>
X-Sender: sbrim@airborne.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 07 Aug 2000 18:00:14 -0400
To: erosen@cisco.com
From: Scott Brim <sbrim@cisco.com>
Subject: Re: Use of the term "end-to-end" 
Cc: <mpls@UU.NET>, IESG <iesg@ietf.org>, IAB <iab@isi.edu>
In-Reply-To: <200008071651.MAA03316@erosen-sun.cisco.com>
References: <Your message of Mon, 07 Aug 2000 17:36:04 +0200. <398ED764.CF7A7AC8@nortelnetworks.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

At 12:51 PM 08/07/2000 -0400, Eric Rosen wrote:
>I have to say  that I don't see what the problem is.  Or rather, I don't see
>that  there   is  a   problem  which  requires   any  modification   of  the
>specifications.
>
>I don't think that "end-to-end" is used  in any of the MPLS documents, and I
>believe  that  those documents  contain  terminology  which  is adequate  to
>precisely state any necessary concepts.
>
>In discussing MPLS, the term  "end-to-end" is sometimes used colloquially in
>contexts  where it is  clear to  most that  it doesn't  mean "host-to-host".
>Dave might be  right to deplore this usage.   However, increasing the number
>of precisely  defined terms and acronyms  will not do anything  to stamp out
>such colloquialisms.

But (1) we can do the right thing and not use "end-to-end" in a way that 
further erodes its meaning. and (2) if it's a confusing term then we 
shouldn't use it anyway.  I like LER because it's a clearly defined 
functionality, within the context of MPLS, regardless of whether the box 
that is an LER is doing other things as well.

...Scott




From owner-mpls@UU.NET  Mon Aug  7 18:25:03 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13488
	for <mpls-archive@lists.ietf.org>; Mon, 7 Aug 2000 18:25:03 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbgr28915;
	Mon, 7 Aug 2000 22:25:02 GMT
Received: by mail-control.mail.uu.net 
	id QQjbgr05541
	for mpls-outgoing; Mon, 7 Aug 2000 22:24:30 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjbgr05536
	for <mpls@mail-control.mail.uu.net>; Mon, 7 Aug 2000 22:24:25 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjbgr19162
	for <mpls@UU.NET>; Mon, 7 Aug 2000 18:24:16 -0400 (EDT)
Received: from griffin.host4u.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: griffin.host4u.net [209.150.128.163])
	id QQjbgr28399
	for <mpls@UU.NET>; Mon, 7 Aug 2000 22:24:15 GMT
Received: from toy.labn.net (jgateadsl.cais.net [205.252.5.196])
	by griffin.host4u.net (8.8.5/8.8.5) with ESMTP id RAA11043;
	Mon, 7 Aug 2000 17:24:09 -0500
Message-Id: <4.3.2.7.2.20000807182340.00d33ef0@mail.labn.net>
X-Sender: lberger@mail.labn.net
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 07 Aug 2000 18:24:39 -0400
To: mpls@UU.NET
From: Lou Berger <lberger@labn.net>
Subject: Fwd: RSVP-LSP-TUNNEL
Cc: swallow@cisco.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

FYI -

>Reply-To: <iana@iana.org>
>From: "IANA" <iana@ISI.EDU>
>To: <swallow@cisco.com>, <lberger@labn.net>
>Cc: <braden@ISI.EDU>
>Subject: RSVP-LSP-TUNNEL
>Date: Mon, 7 Aug 2000 15:02:32 -0700
>X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
>Importance: Normal
>
>George and Lou,
>
>We have updated the RSVP-parameters file.  We apologize for long
>delay in completing this.  This is to confirm that we have assigned
>all the values requested to the RSVP protocol parameters file.  Please
>check the following file for these assignments:
>
><http://www.isi.edu/in-notes/iana/assignments/rsvp-parameters>
>
>Thank you,
>
>Michelle Schipper
>IANA
>
>Requested Assignments below (**changes)
>----------------------------------------------------------------------------
>Object and C-Type Assignments:
>
>LABEL Object  (this is already assigned, but should change from Davie
>                to the RFC number which gets assigned.)
>    LABEL class = 16
>
>Label Request Object
>    LABEL_REQUEST Class = 19
>    Label Request without Label Range            C_Type = 1
>    Label Request with ATM Label Range           C_Type = 2
>    Label Request with Frame Relay Label Range   C_Type = 3
>
>Explicit Route Object
>     EXPLICIT_ROUTE Class = 20
>     Type 1 Explicit Route                       C_Type = 1
>
>   Subobjects of the Type 1 EXPLICIT_ROUTE object
>     0   Reserved
>     1   IPv4 prefix
>     2   IPv6 prefix
>    32   Autonomous system number
>
>Record Route Object
>     ROUTE_RECORD Class = 21
>     Type 1 Record Route                          C_Type = 1
>
>   Subobjects of the Type 1 RECORD_ROUTE object
>     0   Reserved
>     1   IPv4 address
>     2   IPv6 address
>
>Session Object
>    LSP_TUNNEL_IPv4   C-Type = 7
>    LSP_TUNNEL_IPv6   C-Type = 8
>
>Sender Template Object
>    LSP_TUNNEL_IPv4   C-Type = 7
>    LSP_TUNNEL_IPv6   C-Type = 8
>
>Filter Specification Object
>    LSP_TUNNEL_IPv4   C-Type = 7
>    LSP_TUNNEL_IPv6   C-Type = 8
>
>SESSION_ATTRIBUTE object
>    Session Attribute Class = 207
>    LSP_TUNNEL       C-Type = 7
>
>Sender Tspec Object
>     Class-of-Service  C-Type = 3
>
>Flowspec Object
>     Class-of-Service  C-Type = 3
>
>HELLO Object
>     HELLO Class =  22
>     HELLO REQUEST   C_Type = 1
>     HELLO ACK       C_Type = 2
>
>*Message Assignment
>*Hello Message
>    Msg Type 14  **Assigned Value 20
>
>Error Code Assignments
>
>"Routing Problem" error code = 24
>"Notify" error code = 25
>
>The following defines error values for the Routing Problem Error Code:
>       Value Error:
>       1     Bad EXPLICIT_ROUTE object
>       2     Bad strict node
>       3     Bad loose node
>       4     Bad initial subobject
>       5     No route available toward destination
>       6     RRO syntax error detected
>       7     RRO indicated routing loops
>       8     MPLS being negotiated, but a non-RSVP-capable router
>             stands in the path
>       9     MPLS label allocation failure
>       10    Unsupported L3PID
>
>For the Notify Error Code, the 16 bits of the Error Value field are:
>       ss00 cccc cccc cccc
>The high order bits are as defined under Error Code 1. RFC2205
>When ss = 00, the following subcode is defined:
>        1    RRO too large for MTU
>        2    RRO notification



From owner-mpls@UU.NET  Tue Aug  8 08:15:41 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04657
	for <mpls-archive@lists.ietf.org>; Tue, 8 Aug 2000 08:15:40 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbhf29133;
	Tue, 8 Aug 2000 01:54:34 GMT
Received: by mail-control.mail.uu.net 
	id QQjbhf20693
	for mpls-outgoing; Tue, 8 Aug 2000 01:53:22 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjbhf20686
	for <mpls@mail-control.mail.uu.net>; Tue, 8 Aug 2000 01:53:15 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjbhf11196
	for <mpls@uu.net>; Mon, 7 Aug 2000 21:47:25 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjbhf25312
	for <mpls@uu.net>; Tue, 8 Aug 2000 01:47:24 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id VAA10302
	for mpls@uu.net; Mon, 7 Aug 2000 21:47:24 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjbhf20471
	for <mpls@mail-control.mail.uu.net>; Tue, 8 Aug 2000 01:46:26 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjbhf09150
	for <mpls@UU.NET>; Mon, 7 Aug 2000 21:45:18 -0400 (EDT)
Received: from zipper.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: zipper.cisco.com [171.69.25.142])
	id QQjbhf24037
	for <mpls@UU.NET>; Tue, 8 Aug 2000 01:45:17 GMT
Received: from qma-nt (dhcp-171-70-57-1.cisco.com [171.70.57.1]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id SAA01583; Mon, 7 Aug 2000 18:44:44 -0700 (PDT)
Message-Id: <4.2.0.58.20000807183217.01b4cbd0@zipper.cisco.com>
X-Sender: qma@zipper.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Mon, 07 Aug 2000 18:43:17 -0700
To: Ping Pan <pingpan@cs.columbia.edu>, Qingming Ma <qma@cisco.com>
From: Qingming Ma <qma@cisco.com>
Subject: Re: traces to simulate QoS requests
Cc: Peter Ashwood-Smith <petera@nortelnetworks.com>, mpls <mpls@UU.NET>
In-Reply-To: <Pine.GSO.4.21.0008071952170.10295-100000@bourbon.cs.columb
 ia.edu>
References: <4.2.0.58.20000807162158.01b87030@zipper.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

Ping,

I don't think anything is wrong with possion arrival for QoS requests. At
least not what I am aware of. There may be some co-relations among
different QoS flows, but the relationship can be application dependent.

Thanks,

Qingming



At 08:01 PM 8/7/00 -0400, Ping Pan wrote:

>Hi,
>
>To study RSVP behavior, you can also modify the ns-2 RSVP code. Please go
>to http://www.cs.columbia.edu/~pingpan/paper_list.html for one of my
>recent papers on lightweight reservation mechanisms. I had simulated a
>good sized network and generated on/off RSVP requests with different bw
>requirements. The call duration is also adjustable. We had found some
>interesting problems with RSVP blockade mechanism, and worked out some
>enhancements.
>
>BTW, I know we cannot model data flows in possion, but what's wrong with
>possion arrival for reservation requests?
>
>Thanks!
>
>- Ping Pan
>
>
>On Mon, 7 Aug 2000, Qingming Ma wrote:
>
> > In my dissertation work on QoS routing, I used various different traffic
> > models for QoS session arrivals, bandwidth requirements, and call
> > holding time distributions. You can check out details from my dissertation.
> > Let me know if you want to have a copy.
> >
> > Thank you,
> >
> > Qingming
> >
> >
> > At 08:56 AM 5/4/00 -0400, Peter Ashwood-Smith wrote:
> > >MPLS wrote:
> > > >
> > > > Hi all,
> > > > We are trying to simulate a workmodel for handling QoS requests.
> > > >
> > > > In this respect, are there any publicly available traces for real time
> > > > call requests that request bandwidth at the ISPs.
> > > >
> > > > If not, is there some study that says what is a feasible
> > > > distribution for the following:
> > > > 1. b/w requirement of a QoS call
> > > > 2. QoS call request arrival rate
> > > > 3. QoS call duration
> > > >
> > > > Most of the reserach work has been done using uniform ditsribution
> > > > for b/w requirement, poisson for arrival rate, and exponential for call
> > > > duration.
> > > > How close to the real life scenario are these assumptions.
> > > >
> > > > Thanks in advance,
> > > >
> > > > Gargi Banerjee
> > >
> > >   I'm not aware of a source of the data you are looking for however I'd
> > >warn you against using any of the nice clean models like poisson etc.
> > >You may be able to extrapolate from some existing ATM networks as a
> > >starting point.
> > >
> > >   The rate that LSPs arrive, depart and how long they hold will depend
> > >on the applications using them and we cannot easily predict what 
> applications
> > >will tend to do with them. Initially you will see REALLY long hold times
> > >but these will come down in time as more and more uses for LSPs evolve.
> > >
> > >   My gut feeling is that LSPs will eventually have behavior like data 
> only
> > >at a slower rate. I.e. chaotic, bursty etc.
> > >
> > >   Cheers,
> > >
> > >   Peter
> >
> >
> >
>




From owner-mpls@UU.NET  Tue Aug  8 08:43:58 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00005
	for <mpls-archive@lists.ietf.org>; Tue, 8 Aug 2000 03:46:51 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbho09385;
	Tue, 8 Aug 2000 04:00:19 GMT
Received: by mail-control.mail.uu.net 
	id QQjbhn19264
	for mpls-outgoing; Tue, 8 Aug 2000 03:59:22 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjbhn19259
	for <mpls@mail-control.mail.uu.net>; Tue, 8 Aug 2000 03:59:16 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjbhn22826
	for <mpls@uu.net>; Mon, 7 Aug 2000 23:55:19 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjbhn05923
	for <mpls@uu.net>; Tue, 8 Aug 2000 03:54:48 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id XAA17112
	for mpls@uu.net; Mon, 7 Aug 2000 23:54:48 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjbhn19105
	for <mpls@mail-control.mail.uu.net>; Tue, 8 Aug 2000 03:53:32 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjbhn22333
	for <mpls@UU.NET>; Mon, 7 Aug 2000 23:49:30 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88])
	id QQjbhn02944
	for <mpls@UU.NET>; Tue, 8 Aug 2000 03:49:15 GMT
Received: from bulkrate.cisco.com (bulkrate.cisco.com [171.71.160.24])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id UAA18763;
	Mon, 7 Aug 2000 20:49:02 -0700 (PDT)
Received: from jlawrenc-pc.cisco.com (jlawrenc-isdn.cisco.com [144.254.141.30])
	by bulkrate.cisco.com (Mirapoint)
	with ESMTP id ABC10892;
	Mon, 7 Aug 2000 20:48:48 -0700 (PDT)
Message-Id: <4.3.2.7.2.20000808134159.00aec180@bulkrate.cisco.com>
X-Sender: jlawrenc@bulkrate.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 08 Aug 2000 13:48:10 +1000
To: seenu@samsung.co.kr
From: Jeremy Lawrence <jlawrenc@cisco.com>
Subject: Re: label encapsulation for LAN media
Cc: chetanpinto@hotmail.com, mpls@UU.NET, akyol@pluris.com
In-Reply-To: <398F11B9.3202CA1C@pluris.com>
References: <H0000e6501a35f91.0965638501.secsw0@MHS>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-mpls@UU.NET
Precedence: bulk

One more comment:

At 12:44 08/07/2000 -0700, Bora Akyol wrote:
>seenu@samsung.co.kr wrote:
[...]
>> Draft-ietf-mpls-label-encaps-07.txt  says that the Label Stack (label encapsulation on LAN media) must appear AFTER the data link layer headers, but BEFORE any network layer headers.
>>
>> But the draft-srinivasan-mpls-lans-label-00.txt says that: (ARIS too)
>>
>>         The main drawback of using the above approach for label-encapsulation is that accessing the labels requires that the frames be processed by software, reducing the benefit offered by label switching. Alternatively, hardware technology specific to label switching may be developed. However, standardized devices incorporating this technology do not exist today and cannot be built until the MPLS standard becomes stable.
>>
>>         And this draft has proposed the use of destination MAC address field for label encapsulation.
>>
>> Now, my doubts are:
>>
>> ? If one follows the first case (label-encaps-07.txt), how the label swapping will be done (s/w or h/w)
>> ? Is there any ethernet standard (h/w) that supports the above type of switching (label-encaps-07.txt).
>> ? Which is the standard draft that is being followed.

draft-ietf-mpls-label-encaps-07.txt has been approved as a Proposed
Standard RFC, but can't yet be published as one as it's waiting for
the LDP draft. See http://www.rfc-editor.org/queue.html

draft-srinivasan-mpls-lans-label-00.txt is long expired, and there
were significant doubts expressed at the time about interoperability
with existing LAN switches.

>I haven't read this draft, but I see no reason why having the shime header between IP and Ethernet headers would cause packets to be processed in SW.
>
>Bora




From owner-mpls@UU.NET  Tue Aug  8 09:22:14 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15632
	for <mpls-archive@lists.ietf.org>; Tue, 8 Aug 2000 09:22:14 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbin17624;
	Tue, 8 Aug 2000 10:17:57 GMT
Received: by mail-control.mail.uu.net 
	id QQjbin27999
	for mpls-outgoing; Tue, 8 Aug 2000 10:17:02 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjbin27987
	for <mpls@mail-control.mail.uu.net>; Tue, 8 Aug 2000 10:16:47 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbin05927
	for <mpls@uu.net>; Tue, 8 Aug 2000 06:16:35 -0400 (EDT)
Received: from rout-LRC-01.lrc.deene.ufu.br by wodc7mr1.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: rout-lrc-01.lrc.deene.ufu.br [200.19.152.13])
	id QQjbin07792
	for <mpls@uu.net>; Tue, 8 Aug 2000 10:16:18 GMT
Received: from lrc.deene.ufu.br (200.19.148.192) by rout-LRC-01.lrc.deene.ufu.br
 (EMWAC SMTPRS 0.80) with SMTP id <B0000046878@rout-LRC-01.lrc.deene.ufu.br>;
 Tue, 08 Aug 2000 07:18:15 -0300
Message-ID: <398FDF0C.C8D05D9B@lrc.deene.ufu.br>
Date: Tue, 08 Aug 2000 07:21:00 -0300
From: Daniela Cunha <daniela@lrc.deene.ufu.br>
X-Mailer: Mozilla 4.72 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Qingming Ma <qma@cisco.com>
CC: Peter Ashwood-Smith <petera@nortelnetworks.com>, mpls <mpls@UU.NET>
Subject: Re: traces to simulate QoS requests
References: <Pine.GSO.3.95.1000503170700.1970H-100000@discovery.mctr.umbc.edu> <4.2.0.58.20000807162158.01b87030@zipper.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Qingming Ma,

Your dissertation really interested me. In it is possible I would like you to send
me a copy.

Thank you
Daniela Cunha

Qingming Ma wrote:

> In my dissertation work on QoS routing, I used various different traffic
> models for QoS session arrivals, bandwidth requirements, and call
> holding time distributions. You can check out details from my dissertation.
> Let me know if you want to have a copy.
>
> Thank you,
>
> Qingming
>
> At 08:56 AM 5/4/00 -0400, Peter Ashwood-Smith wrote:
> >MPLS wrote:
> > >
> > > Hi all,
> > > We are trying to simulate a workmodel for handling QoS requests.
> > >
> > > In this respect, are there any publicly available traces for real time
> > > call requests that request bandwidth at the ISPs.
> > >
> > > If not, is there some study that says what is a feasible
> > > distribution for the following:
> > > 1. b/w requirement of a QoS call
> > > 2. QoS call request arrival rate
> > > 3. QoS call duration
> > >
> > > Most of the reserach work has been done using uniform ditsribution
> > > for b/w requirement, poisson for arrival rate, and exponential for call
> > > duration.
> > > How close to the real life scenario are these assumptions.
> > >
> > > Thanks in advance,
> > >
> > > Gargi Banerjee
> >
> >   I'm not aware of a source of the data you are looking for however I'd
> >warn you against using any of the nice clean models like poisson etc.
> >You may be able to extrapolate from some existing ATM networks as a
> >starting point.
> >
> >   The rate that LSPs arrive, depart and how long they hold will depend
> >on the applications using them and we cannot easily predict what applications
> >will tend to do with them. Initially you will see REALLY long hold times
> >but these will come down in time as more and more uses for LSPs evolve.
> >
> >   My gut feeling is that LSPs will eventually have behavior like data only
> >at a slower rate. I.e. chaotic, bursty etc.
> >
> >   Cheers,
> >
> >   Peter



From owner-mpls@UU.NET  Tue Aug  8 09:58:32 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05700
	for <mpls-archive@lists.ietf.org>; Tue, 8 Aug 2000 09:58:30 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbjb11560;
	Tue, 8 Aug 2000 13:58:27 GMT
Received: by mail-control.mail.uu.net 
	id QQjbjb13377
	for mpls-outgoing; Tue, 8 Aug 2000 13:57:52 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjbjb13372
	for <mpls@mail-control.mail.uu.net>; Tue, 8 Aug 2000 13:57:48 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjbjb02298
	for <mpls@UU.NET>; Tue, 8 Aug 2000 09:54:48 -0400 (EDT)
From: neil.2.harrison@bt.com
Received: from marvin.axion.bt.co.uk by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: marvin.axion.bt.co.uk [132.146.16.82])
	id QQjbjb02925
	for <mpls@UU.NET>; Tue, 8 Aug 2000 13:54:17 GMT
Received: from cirwm3nt01.nor.bt.com by marvin (local) with ESMTP;
          Tue, 8 Aug 2000 14:53:14 +0100
Received: by cirwm3nt01.nor.bt.com with Internet Mail Service (5.5.2651.88) 
          id <QGFTAF50>; Tue, 8 Aug 2000 14:53:03 +0100
Message-ID: <B9571FDEBD3DD21181E500606DD5EE0507B162AA@mbddmknt01.hc.bt.com>
To: ewgray@mindspring.com, loa.andersson@nortelnetworks.com
Cc: dallan@nortelnetworks.com, sbrim@cisco.com, oran@cisco.com, mpls@UU.NET,
        iesg@ietf.org, iab@isi.edu
Subject: RE: Use of the term "end-to-end"
Date: Tue, 8 Aug 2000 14:52:49 +0100 
X-Mailer: Internet Mail Service (5.5.2651.88)
MIME-version: 1.0
Content-type: text/plain; charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

All,

End-to-end is subjective since it depends on your perspective....think about
nested LSPs, we have to cater for these.  LER-to-LER is architecturally
restrictive being just one specific case of an LSP, and (as Eric points out)
related to 'current box names'.  I believe we need a generic term that
captures the essence of the LSP entity at whatever level it exists in a
label stacked hierarchy of LSPs.  If we borrow from functional modelling
terminology developed in G.805 by the ITU for SDH and ATM, I suspect that
'trail termination points' (ie an LSP exists between them) is the closest
match to the function we are trying to describe. I attach the extracted
references from G.805 below for your information.
3.1	trail termination sink: A "transport processing function" which
accepts the characteristic information of the layer network at its input,
removes the information related to "trail" monitoring and presents the
remaining information at its output.
3.2	trail termination source: A "transport processing function" which
accepts adapted "characteristic information" from a client layer network at
its input, adds information to allow the "trail" to be monitored and
presents the characteristic information of the layer network at its output.
The trail termination source can operate without an input from a client
layer network.

Whilst these are not perfect matches we could start to use them I guess (or
invent our own).  Also note that as MPLS expands to cover other technologies
(eg optical networks) then we need a common architectural term for the LSP
object irrespective of the technology.
BTW....I understand the ITU are going to develop a functional model of
optical and IP/MPLS networks in due course.

So perhaps we could use LSP_TTP-LSP_TTP (or LTTP-LTTP, or indeed whatever
looks nice) to define this entity.....and to be honest I don't think its
name is that important, just so long as we agree on (functionally) what that
entity is. 

The only thing that concerns me now is PHP......as I said in a mail several
weeks ago (wrt defect detection and consequent action, eg restoration) I
really don't like the idea that the LSP (sink) trail termination point is a
moveable feast.

Regards, Neil

> -----Original Message-----
> From:	Eric Gray [SMTP:ewgray@mindspring.com]
> Sent:	Monday, August 07, 2000 4:57 AM
> To:	Loa Andersson
> Cc:	David Allan; Scott Brim; David R. Oran; mpls; IESG; IAB
> Subject:	Re: Use of the term "end-to-end"
> 
> Loa,
> 
>     I distinctly remember your proposing the term and
> its more-or-less being rejected.  Never-the-less, it has
> come to be accepted as a real term.  Many slides and
> charts now contain some subset of this picture:
> 
>   LER -- LSR -- ... -- LSR -- LER
> 
> While it is still debatable that a box which is exclusively
> either an LER or an LSR will be a long-term survivor
> in the market place, it is useful to think of LSR verses
> LER functionality.
> 
> Loa Andersson wrote:
> 
> > This is fine with me, but the last time (back in the childhood of MPLS)
> > I tried to propose the term LER as part of the MPLS vocabulary it was
> > not considered necessary. SO either we add it or use something else.
> >
> > /Loa
> >
> > David Allan wrote:
> > >
> > > Agreed
> > >
> > >      -----Original Message-----
> > >      From:   Scott Brim [SMTP:sbrim@cisco.com]
> > >      Sent:   Thursday, August 03, 2000 11:37 AM
> > >      To:     David R. Oran
> > >      Cc:     mpls; IESG; IAB
> > >      Subject:        Re: Use of the term "end-to-end"
> > >
> > >      LER-to-LER
> > >
> > >      <snip>
> >
> > --
> >
> > Loa Andersson
> > Director Routing Architecture Lab, EMEA
> > St Eriksgatan 115A, PO Box 6701
> > 113 85 Stockholm, Sweden
> > phone: +46 8 50 88 36 34,   mobile + 46 70 522 78 34
> > e-mail: loa.andersson@nortelnetworks.com


From owner-mpls@UU.NET  Tue Aug  8 10:21:01 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05032
	for <mpls-archive@lists.ietf.org>; Tue, 8 Aug 2000 10:21:01 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbjd22632;
	Tue, 8 Aug 2000 14:20:54 GMT
Received: by mail-control.mail.uu.net 
	id QQjbjd26178
	for mpls-outgoing; Tue, 8 Aug 2000 14:20:32 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjbjd26170
	for <mpls@mail-control.mail.uu.net>; Tue, 8 Aug 2000 14:20:28 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjbjd06813
	for <mpls@uu.net>; Tue, 8 Aug 2000 10:20:12 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjbjd21595
	for <mpls@uu.net>; Tue, 8 Aug 2000 14:20:12 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA24200
	for mpls@uu.net; Tue, 8 Aug 2000 10:20:11 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjbjd26114
	for <mpls@mail-control.mail.uu.net>; Tue, 8 Aug 2000 14:19:20 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbjd12041
	for <mpls@uu.net>; Tue, 8 Aug 2000 10:19:04 -0400 (EDT)
Received: from ietf.org by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: odin.ietf.org [132.151.1.176])
	id QQjbjd21581
	for <mpls@uu.net>; Tue, 8 Aug 2000 14:19:03 GMT
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03683;
	Tue, 8 Aug 2000 10:19:00 -0400 (EDT)
Message-Id: <200008081419.KAA03683@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;
Cc: mpls@UU.NET
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mpls-icmp-02.txt
Date: Tue, 08 Aug 2000 10:19:00 -0400
Sender: owner-mpls@UU.NET
Precedence: bulk

--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		: ICMP Extensions for MultiProtocol Label Switching
	Author(s)	: R. Bonica, D. Tappan, D. Gan
	Filename	: draft-ietf-mpls-icmp-02.txt
	Pages		: 10
	Date		: 07-Aug-00
	
The current memo proposes extensions to ICMP that permit Label
Switching Routers to append MPLS information to ICMP messages.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-icmp-02.txt

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-icmp-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-mpls-icmp-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:	<20000807142324.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mpls-icmp-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mpls-icmp-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000807142324.I-D@ietf.org>

--OtherAccess--

--NextPart--





From owner-mpls@UU.NET  Tue Aug  8 10:21:09 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05134
	for <mpls-archive@lists.ietf.org>; Tue, 8 Aug 2000 10:21:09 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbjd22441;
	Tue, 8 Aug 2000 14:21:08 GMT
Received: by mail-control.mail.uu.net 
	id QQjbjd26181
	for mpls-outgoing; Tue, 8 Aug 2000 14:20:35 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjbjd26171
	for <mpls@mail-control.mail.uu.net>; Tue, 8 Aug 2000 14:20:28 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjbjd06875
	for <mpls@uu.net>; Tue, 8 Aug 2000 10:20:23 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjbjd21544
	for <mpls@uu.net>; Tue, 8 Aug 2000 14:20:08 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA24164
	for mpls@uu.net; Tue, 8 Aug 2000 10:20:07 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjbjd26137
	for <mpls@mail-control.mail.uu.net>; Tue, 8 Aug 2000 14:19:53 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbjd06690
	for <mpls@uu.net>; Tue, 8 Aug 2000 10:19:22 -0400 (EDT)
Received: from ietf.org by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: odin.ietf.org [132.151.1.176])
	id QQjbjd21751
	for <mpls@uu.net>; Tue, 8 Aug 2000 14:19:21 GMT
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03903;
	Tue, 8 Aug 2000 10:19:19 -0400 (EDT)
Message-Id: <200008081419.KAA03903@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;
Cc: mpls@UU.NET
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mpls-ldp-09.txt
Date: Tue, 08 Aug 2000 10:19:19 -0400
Sender: owner-mpls@UU.NET
Precedence: bulk

--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		: LDP Specification
	Author(s)	: L. Andersson, P. Doolan, N. Feldman,
                          A. Fredette, B. Thomas
	Filename	: draft-ietf-mpls-ldp-09.txt
	Pages		: 135
	Date		: 07-Aug-00
	
The architecture for Multi Protocol Label Switching (MPLS) is
described in [ARCH].  A fundamental concept in MPLS is that two Label
Switching Routers (LSRs) must agree on the meaning of the labels used
to forward traffic between and through them.  This common
understanding is achieved by using a set of procedures, called a
label distribution protocol, by which one LSR informs another of
label bindings it has made.  This document defines a set of such
procedures called LDP (for Label Distribution Protocol) by which LSRs
distribute labels to support MPLS forwarding along normally routed
paths [LDPAPPLIC].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-09.txt

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-ldp-09.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-ldp-09.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:	<20000807142347.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mpls-ldp-09.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mpls-ldp-09.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000807142347.I-D@ietf.org>

--OtherAccess--

--NextPart--





From owner-mpls@UU.NET  Tue Aug  8 10:21:38 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05495
	for <mpls-archive@lists.ietf.org>; Tue, 8 Aug 2000 10:21:37 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbjd23258;
	Tue, 8 Aug 2000 14:21:34 GMT
Received: by mail-control.mail.uu.net 
	id QQjbjd26186
	for mpls-outgoing; Tue, 8 Aug 2000 14:20:37 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjbjd26172
	for <mpls@mail-control.mail.uu.net>; Tue, 8 Aug 2000 14:20:29 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjbjd06874
	for <mpls@uu.net>; Tue, 8 Aug 2000 10:20:23 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjbjd21535
	for <mpls@uu.net>; Tue, 8 Aug 2000 14:20:07 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA24163
	for mpls@uu.net; Tue, 8 Aug 2000 10:20:07 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjbjd26130
	for <mpls@mail-control.mail.uu.net>; Tue, 8 Aug 2000 14:19:44 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbjd12119
	for <mpls@uu.net>; Tue, 8 Aug 2000 10:19:27 -0400 (EDT)
Received: from ietf.org by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: odin.ietf.org [132.151.1.176])
	id QQjbjd21815
	for <mpls@uu.net>; Tue, 8 Aug 2000 14:19:26 GMT
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03957;
	Tue, 8 Aug 2000 10:19:24 -0400 (EDT)
Message-Id: <200008081419.KAA03957@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;
Cc: mpls@UU.NET
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mpls-vcid-atm-05.txt
Date: Tue, 08 Aug 2000 10:19:23 -0400
Sender: owner-mpls@UU.NET
Precedence: bulk

--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		: VCID Notification over ATM link for LDP
	Author(s)	: K. Nagami, N. Demizu, H. Esaki, 
                          Y. Katsube, P. Doolan
	Filename	: draft-ietf-mpls-vcid-atm-05.txt
	Pages		: 16
	Date		: 07-Aug-00
	
The ATM Label Switching Router (ATM-LSR) is one of the major
applications of label switching. Because the ATM layer labels (VPI
and VCI) associated with a VC rewritten with new value at every ATM
switch nodes, it is not possible to use them to identify a VC in
label mapping messages. The concept of Virtual Connection Identifier
(VCID) is introduced to solve this problem.  VCID has the same value
at both ends of a VC.  This document specifies the procedures for the
communication of VCID values between neighboring ATM-LSRs that must
occur in order to ensure this property.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-vcid-atm-05.txt

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-vcid-atm-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mpls-vcid-atm-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20000807142357.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mpls-vcid-atm-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mpls-vcid-atm-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000807142357.I-D@ietf.org>

--OtherAccess--

--NextPart--





From owner-mpls@UU.NET  Tue Aug  8 10:22:02 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05763
	for <mpls-archive@lists.ietf.org>; Tue, 8 Aug 2000 10:22:01 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbjd23324;
	Tue, 8 Aug 2000 14:21:53 GMT
Received: by mail-control.mail.uu.net 
	id QQjbjd26191
	for mpls-outgoing; Tue, 8 Aug 2000 14:20:39 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjbjd26173
	for <mpls@mail-control.mail.uu.net>; Tue, 8 Aug 2000 14:20:29 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjbjd06810
	for <mpls@uu.net>; Tue, 8 Aug 2000 10:20:12 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjbjd21594
	for <mpls@uu.net>; Tue, 8 Aug 2000 14:20:12 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA24201
	for mpls@uu.net; Tue, 8 Aug 2000 10:20:11 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjbjd26116
	for <mpls@mail-control.mail.uu.net>; Tue, 8 Aug 2000 14:19:21 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbjd12089
	for <mpls@uu.net>; Tue, 8 Aug 2000 10:19:18 -0400 (EDT)
Received: from ietf.org by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: odin.ietf.org [132.151.1.176])
	id QQjbjd21662
	for <mpls@uu.net>; Tue, 8 Aug 2000 14:19:16 GMT
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03842;
	Tue, 8 Aug 2000 10:19:14 -0400 (EDT)
Message-Id: <200008081419.KAA03842@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;
Cc: mpls@UU.NET
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mpls-ldp-applic-02.txt
Date: Tue, 08 Aug 2000 10:19:14 -0400
Sender: owner-mpls@UU.NET
Precedence: bulk

--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		: LDP Applicability
	Author(s)	: B. Thomas, E. Gray
	Filename	: draft-ietf-mpls-ldp-applic-02.txt
	Pages		: 6
	Date		: 07-Aug-00
	
Multiprotocol Label Switching (MPLS) is a method for forwarding
packets that uses short, fixed-length values carried by packets,
called labels, to determine packet nexthops [MPLS-ARCH]).  A
fundamental concept in MPLS is that two Label Switching Routers
(LSRs) must agree on the meaning of the labels used to forward
traffic between and through them.  This common understanding is
achieved by using a set of procedures, called a label distribution
protocol, by which one LSR informs another of label bindings it has
made.  This document describes the applicability of a set of such
procedures called LDP (for Label Distribution Protocol) [LDP] by
wich LSRs distribute labels to support MPLS forwarding along
normally routed paths.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-applic-02.txt

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-ldp-applic-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-mpls-ldp-applic-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:	<20000807142336.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mpls-ldp-applic-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mpls-ldp-applic-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000807142336.I-D@ietf.org>

--OtherAccess--

--NextPart--





From owner-mpls@UU.NET  Tue Aug  8 10:34:03 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12576
	for <mpls-archive@lists.ietf.org>; Tue, 8 Aug 2000 10:34:02 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbje02489;
	Tue, 8 Aug 2000 14:33:59 GMT
Received: by mail-control.mail.uu.net 
	id QQjbje27110
	for mpls-outgoing; Tue, 8 Aug 2000 14:33:23 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjbje27103
	for <mpls@mail-control.mail.uu.net>; Tue, 8 Aug 2000 14:33:03 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjbje14825
	for <mpls@UU.NET>; Tue, 8 Aug 2000 10:32:50 -0400 (EDT)
Received: from ferdowsi.um.ac.ir by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [194.165.12.40])
	id QQjbje01075
	for <mpls@UU.NET>; Tue, 8 Aug 2000 14:32:12 GMT
Received: from kamal.um.ac.ir ([194.165.13.159])
	by ferdowsi.um.ac.ir (8.9.3/8.8.7) with ESMTP id WAA28635;
	Tue, 8 Aug 2000 22:44:59 +0430
Message-ID: <3990544F.3146D363@kamal.um.ac.ir>
Date: Tue, 08 Aug 2000 23:11:19 +0430
From: "M.Hossien Yaghmaee" <hyaghmae@ferdowsi.um.ac.ir>
X-Mailer: Mozilla 4.6 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Qingming Ma <qma@cisco.com>, mpls@UU.NET
Subject: Re: traces to simulate QoS requests
References: <Pine.GSO.3.95.1000503170700.1970H-100000@discovery.mctr.umbc.edu> <4.2.0.58.20000807162158.01b87030@zipper.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Dear Qingming Ma ,

I am also interested to your traffic models for QoS routing. Could you please send
me more details.

Regards,

M.H.Yaghmaee


Qingming Ma wrote:

> In my dissertation work on QoS routing, I used various different traffic
> models for QoS session arrivals, bandwidth requirements, and call
> holding time distributions. You can check out details from my dissertation.
> Let me know if you want to have a copy.
>
> Thank you,
>
> Qingming
>
> At 08:56 AM 5/4/00 -0400, Peter Ashwood-Smith wrote:
> >MPLS wrote:
> > >
> > > Hi all,
> > > We are trying to simulate a workmodel for handling QoS requests.
> > >
> > > In this respect, are there any publicly available traces for real time
> > > call requests that request bandwidth at the ISPs.
> > >
> > > If not, is there some study that says what is a feasible
> > > distribution for the following:
> > > 1. b/w requirement of a QoS call
> > > 2. QoS call request arrival rate
> > > 3. QoS call duration
> > >
> > > Most of the reserach work has been done using uniform ditsribution
> > > for b/w requirement, poisson for arrival rate, and exponential for call
> > > duration.
> > > How close to the real life scenario are these assumptions.
> > >
> > > Thanks in advance,
> > >
> > > Gargi Banerjee
> >
> >   I'm not aware of a source of the data you are looking for however I'd
> >warn you against using any of the nice clean models like poisson etc.
> >You may be able to extrapolate from some existing ATM networks as a
> >starting point.
> >
> >   The rate that LSPs arrive, depart and how long they hold will depend
> >on the applications using them and we cannot easily predict what applications
> >will tend to do with them. Initially you will see REALLY long hold times
> >but these will come down in time as more and more uses for LSPs evolve.
> >
> >   My gut feeling is that LSPs will eventually have behavior like data only
> >at a slower rate. I.e. chaotic, bursty etc.
> >
> >   Cheers,
> >
> >   Peter



From owner-mpls@UU.NET  Tue Aug  8 11:09:12 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06700
	for <mpls-archive@lists.ietf.org>; Tue, 8 Aug 2000 11:09:10 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbgw07922;
	Mon, 7 Aug 2000 23:31:45 GMT
Received: by mail-control.mail.uu.net 
	id QQjbgw20514
	for mpls-outgoing; Mon, 7 Aug 2000 23:30:53 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjbgw20507
	for <mpls@mail-control.mail.uu.net>; Mon, 7 Aug 2000 23:30:39 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbgw24685
	for <mpls@uu.net>; Mon, 7 Aug 2000 19:30:07 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjbgv07236
	for <mpls@uu.net>; Mon, 7 Aug 2000 23:29:36 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id TAA00640
	for mpls@uu.net; Mon, 7 Aug 2000 19:29:36 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjbgv20453
	for <mpls@mail-control.mail.uu.net>; Mon, 7 Aug 2000 23:29:10 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbgv24443
	for <mpls@UU.NET>; Mon, 7 Aug 2000 19:28:04 -0400 (EDT)
Received: from zipper.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: zipper.cisco.com [171.69.25.142])
	id QQjbgv06905
	for <mpls@UU.NET>; Mon, 7 Aug 2000 23:28:03 GMT
Received: from qma-nt (dhcp-171-70-57-1.cisco.com [171.70.57.1]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id QAA17856; Mon, 7 Aug 2000 16:28:01 -0700 (PDT)
Message-Id: <4.2.0.58.20000807162158.01b87030@zipper.cisco.com>
X-Sender: qma@zipper.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Mon, 07 Aug 2000 16:26:34 -0700
To: Peter Ashwood-Smith <petera@nortelnetworks.com>, mpls <mpls@UU.NET>
From: Qingming Ma <qma@cisco.com>
Subject: Re: traces to simulate QoS requests
In-Reply-To: <39117373.83474558@americasm01.nt.com>
References: <Pine.GSO.3.95.1000503170700.1970H-100000@discovery.mctr.umbc.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

In my dissertation work on QoS routing, I used various different traffic
models for QoS session arrivals, bandwidth requirements, and call
holding time distributions. You can check out details from my dissertation.
Let me know if you want to have a copy.

Thank you,

Qingming


At 08:56 AM 5/4/00 -0400, Peter Ashwood-Smith wrote:
>MPLS wrote:
> >
> > Hi all,
> > We are trying to simulate a workmodel for handling QoS requests.
> >
> > In this respect, are there any publicly available traces for real time
> > call requests that request bandwidth at the ISPs.
> >
> > If not, is there some study that says what is a feasible
> > distribution for the following:
> > 1. b/w requirement of a QoS call
> > 2. QoS call request arrival rate
> > 3. QoS call duration
> >
> > Most of the reserach work has been done using uniform ditsribution
> > for b/w requirement, poisson for arrival rate, and exponential for call
> > duration.
> > How close to the real life scenario are these assumptions.
> >
> > Thanks in advance,
> >
> > Gargi Banerjee
>
>   I'm not aware of a source of the data you are looking for however I'd
>warn you against using any of the nice clean models like poisson etc.
>You may be able to extrapolate from some existing ATM networks as a
>starting point.
>
>   The rate that LSPs arrive, depart and how long they hold will depend
>on the applications using them and we cannot easily predict what applications
>will tend to do with them. Initially you will see REALLY long hold times
>but these will come down in time as more and more uses for LSPs evolve.
>
>   My gut feeling is that LSPs will eventually have behavior like data only
>at a slower rate. I.e. chaotic, bursty etc.
>
>   Cheers,
>
>   Peter




From owner-mpls@UU.NET  Tue Aug  8 11:33:29 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21987
	for <mpls-archive@lists.ietf.org>; Tue, 8 Aug 2000 11:33:29 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbji18977;
	Tue, 8 Aug 2000 15:33:23 GMT
Received: by mail-control.mail.uu.net 
	id QQjbji12052
	for mpls-outgoing; Tue, 8 Aug 2000 15:32:35 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjbji12047
	for <mpls@mail-control.mail.uu.net>; Tue, 8 Aug 2000 15:32:31 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjbji25932
	for <mpls@uu.net>; Tue, 8 Aug 2000 11:32:03 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11])
	id QQjbji17735
	for <mpls@uu.net>; Tue, 8 Aug 2000 15:31:32 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA03574
	for <mpls@uu.net>; Tue, 8 Aug 2000 08:31:48 -0700 (PDT)
Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id LAA05016 for mpls@uu.net; Tue, 8 Aug 2000 11:31:30 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjbgy28379
	for <mpls@mail-control.mail.uu.net>; Tue, 8 Aug 2000 00:01:58 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbgy28804
	for <mpls@UU.NET>; Mon, 7 Aug 2000 20:01:16 -0400 (EDT)
Received: from cs.columbia.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cs.columbia.edu [128.59.16.20])
	id QQjbgy15611
	for <mpls@UU.NET>; Tue, 8 Aug 2000 00:01:15 GMT
Received: from bourbon.cs.columbia.edu (bourbon.cs.columbia.edu [128.59.19.24])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id UAA06546;
	Mon, 7 Aug 2000 20:01:15 -0400 (EDT)
Received: from localhost (pingpan@localhost)
	by bourbon.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id UAA10358;
	Mon, 7 Aug 2000 20:01:14 -0400 (EDT)
Date: Mon, 7 Aug 2000 20:01:14 -0400 (EDT)
From: Ping Pan <pingpan@cs.columbia.edu>
To: Qingming Ma <qma@cisco.com>
cc: Peter Ashwood-Smith <petera@nortelnetworks.com>, mpls <mpls@UU.NET>
Subject: Re: traces to simulate QoS requests
In-Reply-To: <4.2.0.58.20000807162158.01b87030@zipper.cisco.com>
Message-ID: <Pine.GSO.4.21.0008071952170.10295-100000@bourbon.cs.columbia.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk


Hi,

To study RSVP behavior, you can also modify the ns-2 RSVP code. Please go
to http://www.cs.columbia.edu/~pingpan/paper_list.html for one of my 
recent papers on lightweight reservation mechanisms. I had simulated a
good sized network and generated on/off RSVP requests with different bw
requirements. The call duration is also adjustable. We had found some
interesting problems with RSVP blockade mechanism, and worked out some
enhancements.

BTW, I know we cannot model data flows in possion, but what's wrong with
possion arrival for reservation requests? 

Thanks!

- Ping Pan


On Mon, 7 Aug 2000, Qingming Ma wrote:

> In my dissertation work on QoS routing, I used various different traffic
> models for QoS session arrivals, bandwidth requirements, and call
> holding time distributions. You can check out details from my dissertation.
> Let me know if you want to have a copy.
> 
> Thank you,
> 
> Qingming
> 
> 
> At 08:56 AM 5/4/00 -0400, Peter Ashwood-Smith wrote:
> >MPLS wrote:
> > >
> > > Hi all,
> > > We are trying to simulate a workmodel for handling QoS requests.
> > >
> > > In this respect, are there any publicly available traces for real time
> > > call requests that request bandwidth at the ISPs.
> > >
> > > If not, is there some study that says what is a feasible
> > > distribution for the following:
> > > 1. b/w requirement of a QoS call
> > > 2. QoS call request arrival rate
> > > 3. QoS call duration
> > >
> > > Most of the reserach work has been done using uniform ditsribution
> > > for b/w requirement, poisson for arrival rate, and exponential for call
> > > duration.
> > > How close to the real life scenario are these assumptions.
> > >
> > > Thanks in advance,
> > >
> > > Gargi Banerjee
> >
> >   I'm not aware of a source of the data you are looking for however I'd
> >warn you against using any of the nice clean models like poisson etc.
> >You may be able to extrapolate from some existing ATM networks as a
> >starting point.
> >
> >   The rate that LSPs arrive, depart and how long they hold will depend
> >on the applications using them and we cannot easily predict what applications
> >will tend to do with them. Initially you will see REALLY long hold times
> >but these will come down in time as more and more uses for LSPs evolve.
> >
> >   My gut feeling is that LSPs will eventually have behavior like data only
> >at a slower rate. I.e. chaotic, bursty etc.
> >
> >   Cheers,
> >
> >   Peter
> 
> 
> 




From owner-mpls@UU.NET  Tue Aug  8 11:35:22 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23221
	for <mpls-archive@lists.ietf.org>; Tue, 8 Aug 2000 11:35:22 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbji20618;
	Tue, 8 Aug 2000 15:35:22 GMT
Received: by mail-control.mail.uu.net 
	id QQjbji12111
	for mpls-outgoing; Tue, 8 Aug 2000 15:34:31 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjbji12102
	for <mpls@mail-control.mail.uu.net>; Tue, 8 Aug 2000 15:34:22 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjbji20172
	for <mpls@uu.net>; Tue, 8 Aug 2000 11:33:33 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11])
	id QQjbji18708
	for <mpls@uu.net>; Tue, 8 Aug 2000 15:33:02 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA04866
	for <mpls@uu.net>; Tue, 8 Aug 2000 08:33:17 -0700 (PDT)
Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id LAA05030 for mpls@uu.net; Tue, 8 Aug 2000 11:33:00 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjbjf28165
	for <mpls@mail-control.mail.uu.net>; Tue, 8 Aug 2000 14:48:32 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbjf17783
	for <mpls@UU.NET>; Tue, 8 Aug 2000 10:48:13 -0400 (EDT)
Received: from mail-gw.hursley.ibm.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-gw.hursley.ibm.com [194.196.110.15])
	id QQjbjf15309
	for <mpls@UU.NET>; Tue, 8 Aug 2000 14:47:41 GMT
Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id PAA167346; Tue, 8 Aug 2000 15:45:26 +0100
Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id PAA22004; Tue, 8 Aug 2000 15:46:12 +0100 (BST)
Message-ID: <39901D3A.CF9754C9@hursley.ibm.com>
Date: Tue, 08 Aug 2000 09:46:18 -0500
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en,fr
MIME-Version: 1.0
To: neil.2.harrison@bt.com
CC: ewgray@mindspring.com, loa.andersson@nortelnetworks.com,
        dallan@nortelnetworks.com, sbrim@cisco.com, oran@cisco.com,
        mpls@UU.NET, iesg@ietf.org, iab@ISI.EDU
Subject: Re: Use of the term "end-to-end"
References: <B9571FDEBD3DD21181E500606DD5EE0507B162AA@mbddmknt01.hc.bt.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

No, end-to-end is very explicit in the Internet and not at all
subjective. Please see RFC 1958.

   Brian

neil.2.harrison@bt.com wrote:
> 
> All,
> 
> End-to-end is subjective since it depends on your perspective....think about
> nested LSPs, we have to cater for these.  LER-to-LER is architecturally
> restrictive being just one specific case of an LSP, and (as Eric points out)
> related to 'current box names'.  I believe we need a generic term that
> captures the essence of the LSP entity at whatever level it exists in a
> label stacked hierarchy of LSPs.  If we borrow from functional modelling
> terminology developed in G.805 by the ITU for SDH and ATM, I suspect that
> 'trail termination points' (ie an LSP exists between them) is the closest
> match to the function we are trying to describe. I attach the extracted
> references from G.805 below for your information.
> 3.1     trail termination sink: A "transport processing function" which
> accepts the characteristic information of the layer network at its input,
> removes the information related to "trail" monitoring and presents the
> remaining information at its output.
> 3.2     trail termination source: A "transport processing function" which
> accepts adapted "characteristic information" from a client layer network at
> its input, adds information to allow the "trail" to be monitored and
> presents the characteristic information of the layer network at its output.
> The trail termination source can operate without an input from a client
> layer network.
> 
> Whilst these are not perfect matches we could start to use them I guess (or
> invent our own).  Also note that as MPLS expands to cover other technologies
> (eg optical networks) then we need a common architectural term for the LSP
> object irrespective of the technology.
> BTW....I understand the ITU are going to develop a functional model of
> optical and IP/MPLS networks in due course.
> 
> So perhaps we could use LSP_TTP-LSP_TTP (or LTTP-LTTP, or indeed whatever
> looks nice) to define this entity.....and to be honest I don't think its
> name is that important, just so long as we agree on (functionally) what that
> entity is.
> 
> The only thing that concerns me now is PHP......as I said in a mail several
> weeks ago (wrt defect detection and consequent action, eg restoration) I
> really don't like the idea that the LSP (sink) trail termination point is a
> moveable feast.
> 
> Regards, Neil
> 
> > -----Original Message-----
> > From: Eric Gray [SMTP:ewgray@mindspring.com]
> > Sent: Monday, August 07, 2000 4:57 AM
> > To:   Loa Andersson
> > Cc:   David Allan; Scott Brim; David R. Oran; mpls; IESG; IAB
> > Subject:      Re: Use of the term "end-to-end"
> >
> > Loa,
> >
> >     I distinctly remember your proposing the term and
> > its more-or-less being rejected.  Never-the-less, it has
> > come to be accepted as a real term.  Many slides and
> > charts now contain some subset of this picture:
> >
> >   LER -- LSR -- ... -- LSR -- LER
> >
> > While it is still debatable that a box which is exclusively
> > either an LER or an LSR will be a long-term survivor
> > in the market place, it is useful to think of LSR verses
> > LER functionality.
> >
> > Loa Andersson wrote:
> >
> > > This is fine with me, but the last time (back in the childhood of MPLS)
> > > I tried to propose the term LER as part of the MPLS vocabulary it was
> > > not considered necessary. SO either we add it or use something else.
> > >
> > > /Loa
> > >
> > > David Allan wrote:
> > > >
> > > > Agreed
> > > >
> > > >      -----Original Message-----
> > > >      From:   Scott Brim [SMTP:sbrim@cisco.com]
> > > >      Sent:   Thursday, August 03, 2000 11:37 AM
> > > >      To:     David R. Oran
> > > >      Cc:     mpls; IESG; IAB
> > > >      Subject:        Re: Use of the term "end-to-end"
> > > >
> > > >      LER-to-LER
> > > >
> > > >      <snip>
> > >
> > > --
> > >
> > > Loa Andersson
> > > Director Routing Architecture Lab, EMEA
> > > St Eriksgatan 115A, PO Box 6701
> > > 113 85 Stockholm, Sweden
> > > phone: +46 8 50 88 36 34,   mobile + 46 70 522 78 34
> > > e-mail: loa.andersson@nortelnetworks.com



From owner-mpls@UU.NET  Tue Aug  8 12:31:26 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00749
	for <mpls-archive@lists.ietf.org>; Tue, 8 Aug 2000 12:31:25 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbjm05235;
	Tue, 8 Aug 2000 16:31:19 GMT
Received: by mail-control.mail.uu.net 
	id QQjbjm26577
	for mpls-outgoing; Tue, 8 Aug 2000 16:30:52 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjbjm26572
	for <mpls@mail-control.mail.uu.net>; Tue, 8 Aug 2000 16:30:46 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbjm06332
	for <mpls@UU.NET>; Tue, 8 Aug 2000 12:30:12 -0400 (EDT)
Received: from ennovatenetworks.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ennovatenetworks.com [208.227.99.254])
	id QQjbjm04809
	for <mpls@UU.NET>; Tue, 8 Aug 2000 16:30:12 GMT
Received: from broncos (broncos.tst.ennovatenetworks.com [10.1.1.208])
	by ennovatenetworks.com (8.8.7/8.8.7) with SMTP id MAA15092;
	Tue, 8 Aug 2000 12:29:47 -0400 (EDT)
	(envelope-from bkumar@ennovatenetworks.com)
Reply-To: <bkumar@ennovatenetworks.com>
From: "Brijesh Kumar" <bkumar@ennovatenetworks.com>
To: <neil.2.harrison@bt.com>, <ewgray@mindspring.com>,
        <loa.andersson@nortelnetworks.com>
Cc: <dallan@nortelnetworks.com>, <sbrim@cisco.com>, <oran@cisco.com>,
        <mpls@UU.NET>, <iesg@ietf.org>, <iab@isi.edu>
Subject: RE: Use of the term "end-to-end"
Date: Tue, 8 Aug 2000 12:29:41 -0400
Message-ID: <00b201c00155$db4a4720$d001010a@tst.ennovatenetworks.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <B9571FDEBD3DD21181E500606DD5EE0507B162AA@mbddmknt01.hc.bt.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Importance: Normal
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi neil,

End-to-End has certain well understood meaning ( the closest IETF doc
explaining this term is RFC 1958 - Architectural Principles of the
Internet). There is no need to overload this term. The use of LSP
Ingress Point/Router/Node/Edge (LIP, LIR, LIN or LER) to LSP Egress
Point/Router/Node/Edge (LEP, LER, LEN or LER) will be lot better.

Cheers,

--brijesh
Ennovate Networks Inc.


> -----Original Message-----
> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of
> neil.2.harrison@bt.com
> Sent: Tuesday, August 08, 2000 9:53 AM
> To: ewgray@mindspring.com; loa.andersson@nortelnetworks.com
> Cc: dallan@nortelnetworks.com; sbrim@cisco.com; oran@cisco.com;
> mpls@UU.NET; iesg@ietf.org; iab@isi.edu
> Subject: RE: Use of the term "end-to-end"
>
>
> All,
>
> End-to-end is subjective since it depends on your
> perspective....think about
> nested LSPs, we have to cater for these.  LER-to-LER is
> architecturally
> restrictive being just one specific case of an LSP, and (as
> Eric points out)
> related to 'current box names'.  I believe we need a generic term
that
> captures the essence of the LSP entity at whatever level it
> exists in a
> label stacked hierarchy of LSPs.  If we borrow from
> functional modelling
> terminology developed in G.805 by the ITU for SDH and ATM, I
> suspect that
> 'trail termination points' (ie an LSP exists between them) is
> the closest
> match to the function we are trying to describe. I attach the
> extracted
> references from G.805 below for your information.
> 3.1	trail termination sink: A "transport processing function" which
> accepts the characteristic information of the layer network
> at its input,
> removes the information related to "trail" monitoring and presents
the
> remaining information at its output.
> 3.2	trail termination source: A "transport processing
> function" which
> accepts adapted "characteristic information" from a client
> layer network at
> its input, adds information to allow the "trail" to be monitored and
> presents the characteristic information of the layer network
> at its output.
> The trail termination source can operate without an input
> from a client
> layer network.
>
> Whilst these are not perfect matches we could start to use
> them I guess (or
> invent our own).  Also note that as MPLS expands to cover
> other technologies
> (eg optical networks) then we need a common architectural
> term for the LSP
> object irrespective of the technology.
> BTW....I understand the ITU are going to develop a functional model
of
> optical and IP/MPLS networks in due course.
>
> So perhaps we could use LSP_TTP-LSP_TTP (or LTTP-LTTP, or
> indeed whatever
> looks nice) to define this entity.....and to be honest I
> don't think its
> name is that important, just so long as we agree on
> (functionally) what that
> entity is.
>
> The only thing that concerns me now is PHP......as I said in
> a mail several
> weeks ago (wrt defect detection and consequent action, eg
> restoration) I
> really don't like the idea that the LSP (sink) trail
> termination point is a
> moveable feast.
>
> Regards, Neil
>
>
>



From owner-mpls@UU.NET  Tue Aug  8 12:41:11 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08295
	for <mpls-archive@lists.ietf.org>; Tue, 8 Aug 2000 12:41:10 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbjm06875;
	Tue, 8 Aug 2000 16:41:04 GMT
Received: by mail-control.mail.uu.net 
	id QQjbjm27123
	for mpls-outgoing; Tue, 8 Aug 2000 16:40:12 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjbjm27116
	for <mpls@mail-control.mail.uu.net>; Tue, 8 Aug 2000 16:40:03 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjbjm07721
	for <mpls@UU.NET>; Tue, 8 Aug 2000 12:39:39 -0400 (EDT)
Received: from ihemlsrv.firewall.lucent.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ihemail1.lucent.com [192.11.222.161])
	id QQjbjm05822
	for <mpls@UU.NET>; Tue, 8 Aug 2000 16:39:38 GMT
Received: from ihemlsrv.firewall.lucent.com (localhost [127.0.0.1])
	by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id MAA29050
	for <mpls@UU.NET>; Tue, 8 Aug 2000 12:39:38 -0400 (EDT)
Received: from hotair.hobl.lucent.com (h199-118-135-2.lucent.com [199.118.135.2])
	by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id MAA29027;
	Tue, 8 Aug 2000 12:39:37 -0400 (EDT)
Received: from hotair.hobl.lucent.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2)
	id MAA07492; Tue, 8 Aug 2000 12:39:35 -0400
Message-ID: <3990338E.71747B8F@hotair.hobl.lucent.com>
Date: Tue, 08 Aug 2000 12:21:34 -0400
From: "S.Sankaranarayanan 3C-508A" <ssnarayanan@lucent.com>
Reply-To: ssnarayanan@lucent.com
Organization: JJ0C21010
X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Brian E Carpenter <brian@hursley.ibm.com>
CC: neil.2.harrison@bt.com, ewgray@mindspring.com,
        loa.andersson@nortelnetworks.com, dallan@nortelnetworks.com,
        sbrim@cisco.com, oran@cisco.com, mpls@UU.NET, iesg@ietf.org,
        iab@ISI.EDU
Subject: Re: Use of the term "end-to-end"
References: <B9571FDEBD3DD21181E500606DD5EE0507B162AA@mbddmknt01.hc.bt.com> <39901D3A.CF9754C9@hursley.ibm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

While, the term end-to-end is explicit in RFC 1958, I think there is a
implicit assumption that end-to-end means the end applications
that are sitting at the end-points of a communication system.  This is
probably a good definition in the case of 
the public Internet which is by default "not owned or operated" by a
single entity.  However, the term end-to-end
needs to be defined for the case of a "managed IP network" like that
ones that operators who would like to provide revenue generating
services operate.  I dont think there is any doubt that operators want
to identify the end-points
of LSP segment that "belongs to them" so as to be able to engineer that
part of the segment to be able to provide value added services to their
customers like QoS guarantees.  To this
effect, I support Neil's usage of LSP_TTP or LTTP as it is most generic
and captures functionality abstractly rather than using boxes,
additionally the notion of a TTP is generic to any connection oriented
network and works well in heterogeneous networks.

Regards,
Shiva
------------------
Sivakumar Sankaranarayanan
Lucent Technologies


From owner-mpls@UU.NET  Tue Aug  8 12:48:18 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12356
	for <mpls-archive@lists.ietf.org>; Tue, 8 Aug 2000 12:48:17 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbgu29112;
	Mon, 7 Aug 2000 23:13:39 GMT
Received: by mail-control.mail.uu.net 
	id QQjbgu19391
	for mpls-outgoing; Mon, 7 Aug 2000 23:12:53 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjbgu19386
	for <mpls@mail-control.mail.uu.net>; Mon, 7 Aug 2000 23:12:51 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjbgu22434
	for <mpls@UU.NET>; Mon, 7 Aug 2000 19:12:35 -0400 (EDT)
Received: from crufty.research.bell-labs.com by wodc7mr2.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: ns2.research.bell-labs.com [204.178.16.49])
	id QQjbgu28138
	for <mpls@UU.NET>; Mon, 7 Aug 2000 23:12:05 GMT
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Mon Aug  7 19:11:30 EDT 2000
Received: from dnrc.bell-labs.com (dhcp-6-168.pa.bell-labs.com [135.250.6.168])
	by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id TAA03624;
	Mon, 7 Aug 2000 19:12:38 -0400 (EDT)
Message-ID: <398F4315.6D092D9B@dnrc.bell-labs.com>
Date: Mon, 07 Aug 2000 16:15:33 -0700
From: Grenville Armitage <gja@dnrc.bell-labs.com>
Organization: Bell Laboratories, Lucent Technologies
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Scott Brim <sbrim@cisco.com>
CC: mpls@UU.NET, IESG <iesg@ietf.org>, IAB <iab@isi.edu>
Subject: Re: Use of the term "end-to-end"
References: <Your message of Mon, 07 Aug 2000 17:36:04 +0200. <398ED764.CF7A7AC8@nortelnetworks.com> <4.3.2.7.2.20000807174655.00b1f100@airborne.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


LER-to-LER makes sense because it contains the notion
of "edge" (the 'E' in LER) as opposed to "end".  Which makes
me think the better phrase is just "edge to edge" since it really
isn't a new term per se, generalizes neatly to similar concepts
in Diffserv, and captures the non-end2end nature of what we're talking
about without constraining the mental model to start/end on an
MPLS-specific functional element.

cheers,
gja

Scott Brim wrote:
	[..]
> But (1) we can do the right thing and not use "end-to-end" in a way that
> further erodes its meaning. and (2) if it's a confusing term then we
> shouldn't use it anyway.  I like LER because it's a clearly defined
> functionality, within the context of MPLS, regardless of whether the box
> that is an LER is doing other things as well.


From owner-mpls@UU.NET  Tue Aug  8 12:51:13 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13984
	for <mpls-archive@lists.ietf.org>; Tue, 8 Aug 2000 12:51:12 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbjn13567;
	Tue, 8 Aug 2000 16:51:02 GMT
Received: by mail-control.mail.uu.net 
	id QQjbjn27765
	for mpls-outgoing; Tue, 8 Aug 2000 16:50:32 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjbjn27758
	for <mpls@mail-control.mail.uu.net>; Tue, 8 Aug 2000 16:50:18 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjbjn09676
	for <mpls@UU.NET>; Tue, 8 Aug 2000 12:49:58 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88])
	id QQjbjn14702
	for <mpls@UU.NET>; Tue, 8 Aug 2000 16:49:57 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id JAA20512;
	Tue, 8 Aug 2000 09:49:02 -0700 (PDT)
Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id MAA05449; Tue, 8 Aug 2000 12:48:43 -0400 (EDT)
Message-Id: <200008081648.MAA05449@erosen-sun.cisco.com>
X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs
To: Brian E Carpenter <brian@hursley.ibm.com>
cc: neil.2.harrison@bt.com, ewgray@mindspring.com,
        loa.andersson@nortelnetworks.com, dallan@nortelnetworks.com,
        sbrim@cisco.com, oran@cisco.com, mpls@UU.NET, iesg@ietf.org,
        iab@ISI.EDU
Subject: Re: Use of the term "end-to-end" 
In-reply-to: Your message of Tue, 08 Aug 2000 09:46:18 -0500.
             <39901D3A.CF9754C9@hursley.ibm.com> 
Reply-To: erosen@cisco.com
User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1
 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1)
 MULE/4.0 (HANANOEN)
MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune")
Content-Type: text/plain; charset=US-ASCII
Date: Tue, 08 Aug 2000 12:48:42 -0400
From: Eric Rosen <erosen@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

(I don't know why I want to add more to this silly thread, but ...)

Could someone  quote the passage in  RFC 1958 that  defines "end-to-end"?  I
can't seem to locate it.  




From owner-mpls@UU.NET  Tue Aug  8 13:04:11 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23459
	for <mpls-archive@lists.ietf.org>; Tue, 8 Aug 2000 13:04:10 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbjo24868;
	Tue, 8 Aug 2000 17:03:58 GMT
Received: by mail-control.mail.uu.net 
	id QQjbjo09150
	for mpls-outgoing; Tue, 8 Aug 2000 17:03:28 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjbjo09130
	for <mpls@mail-control.mail.uu.net>; Tue, 8 Aug 2000 17:03:22 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjbjo05750
	for <mpls@uu.net>; Tue, 8 Aug 2000 13:02:55 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88])
	id QQjbjo24134
	for <mpls@uu.net>; Tue, 8 Aug 2000 17:02:54 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id KAA03826
	for <mpls@uu.net>; Tue, 8 Aug 2000 10:03:11 -0700 (PDT)
Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id NAA05476 for mpls@uu.net; Tue, 8 Aug 2000 13:02:52 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjbjn27746
	for <mpls@mail-control.mail.uu.net>; Tue, 8 Aug 2000 16:50:07 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbjn09543
	for <mpls@UU.NET>; Tue, 8 Aug 2000 12:49:24 -0400 (EDT)
Received: from inner.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: avarice.inner.net [199.33.248.2])
	id QQjbjn12553
	for <mpls@UU.NET>; Tue, 8 Aug 2000 16:49:23 GMT
Received: from mosquito ([216.52.8.30])
	by inner.net (8.7.6/8.9.3) with ESMTP id QAA07347;
	Tue, 8 Aug 2000 16:47:50 GMT
Message-Id: <4.2.0.58.20000808124151.0099a990@avarice.inner.net>
X-Sender: rja@avarice.inner.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Tue, 08 Aug 2000 12:43:30 -0400
To: ssnarayanan@lucent.com
From: RJ Atkinson <rja@inet.org>
Subject: Re: Use of the term "end-to-end"
Cc: Brian E Carpenter <brian@hursley.ibm.com>, neil.2.harrison@bt.com,
        ewgray@mindspring.com, loa.andersson@nortelnetworks.com,
        dallan@nortelnetworks.com, sbrim@cisco.com, oran@cisco.com,
        mpls@UU.NET, iesg@ietf.org, iab@ISI.EDU
In-Reply-To: <3990338E.71747B8F@hotair.hobl.lucent.com>
References: <B9571FDEBD3DD21181E500606DD5EE0507B162AA@mbddmknt01.hc.bt.com>
 <39901D3A.CF9754C9@hursley.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-mpls@UU.NET
Precedence: bulk

Shiva,

	You are confused.  The term "end-to-end" is very well
defined within the IETF and Internet community as several 
folks have noted with references.  Please cease and desist in 
trying to change its meaning.  Other kind folk have suggested
various more precise and more clear terms for the MPLS context,
which is sensible since MPLS is not end-to-end.

Thank you kindly,

Ran
rja@inet.org




From owner-mpls@UU.NET  Tue Aug  8 14:25:38 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10761
	for <mpls-archive@lists.ietf.org>; Tue, 8 Aug 2000 14:25:37 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbjt22087;
	Tue, 8 Aug 2000 18:25:25 GMT
Received: by mail-control.mail.uu.net 
	id QQjbjt26119
	for mpls-outgoing; Tue, 8 Aug 2000 18:25:00 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjbjt26105
	for <mpls@mail-control.mail.uu.net>; Tue, 8 Aug 2000 18:24:56 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbjt27291
	for <mpls@uu.net>; Tue, 8 Aug 2000 14:23:34 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjbjt21361
	for <mpls@uu.net>; Tue, 8 Aug 2000 18:23:33 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA04613
	for mpls@uu.net; Tue, 8 Aug 2000 14:23:33 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjbjt25574
	for <mpls@mail-control.mail.uu.net>; Tue, 8 Aug 2000 18:19:45 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjbjt19550
	for <mpls@UU.NET>; Tue, 8 Aug 2000 14:19:14 -0400 (EDT)
Received: from picard.noroff.no by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [212.20.204.3])
	id QQjbjt21986
	for <mpls@UU.NET>; Tue, 8 Aug 2000 18:19:12 GMT
Received: by picard.noroff.no (Postfix, from userid 815)
	id EE4D022003; Tue,  8 Aug 2000 21:03:13 +0200 (CEST)
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177])
	by picard.noroff.no (Postfix) with ESMTP id 97A7FB3802
	for <magg@NOROFF.NO>; Tue,  8 Aug 2000 21:03:09 +0200 (CEST)
Received: (from adm@localhost)
	by loki.ietf.org (8.9.1b+Sun/8.9.1) id NAA29088
	for ietf-123-outbound.09@ietf.org; Tue, 8 Aug 2000 13:35:02 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])
	by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id KAA26815
	for <all-ietf@loki.ietf.org>; Tue, 8 Aug 2000 10:19:04 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03683;
	Tue, 8 Aug 2000 10:19:00 -0400 (EDT)
Message-Id: <200008081419.KAA03683@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;
Cc: mpls@UU.NET
From: Internet-Drafts@ietf.org
Reply-To: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mpls-icmp-02.txt
Date: Tue, 08 Aug 2000 10:19:00 -0400
X-AntiVirus: scanned for viruses by AMaViS 0.2.1-pre2 (http://amavis.org/)
Sender: owner-mpls@UU.NET
Precedence: bulk

--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		: ICMP Extensions for MultiProtocol Label Switching
	Author(s)	: R. Bonica, D. Tappan, D. Gan
	Filename	: draft-ietf-mpls-icmp-02.txt
	Pages		: 10
	Date		: 07-Aug-00
	
The current memo proposes extensions to ICMP that permit Label
Switching Routers to append MPLS information to ICMP messages.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-icmp-02.txt

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-icmp-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-mpls-icmp-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:	<20000807142324.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mpls-icmp-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mpls-icmp-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000807142324.I-D@ietf.org>

--OtherAccess--

--NextPart--





From owner-mpls@UU.NET  Tue Aug  8 14:26:12 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11122
	for <mpls-archive@lists.ietf.org>; Tue, 8 Aug 2000 14:26:12 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbjt27548;
	Tue, 8 Aug 2000 18:26:07 GMT
Received: by mail-control.mail.uu.net 
	id QQjbjt26146
	for mpls-outgoing; Tue, 8 Aug 2000 18:25:40 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjbjt26140
	for <mpls@mail-control.mail.uu.net>; Tue, 8 Aug 2000 18:25:34 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbjt27406
	for <mpls@uu.net>; Tue, 8 Aug 2000 14:24:37 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjbjt21616
	for <mpls@uu.net>; Tue, 8 Aug 2000 18:24:06 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA04747
	for mpls@uu.net; Tue, 8 Aug 2000 14:24:06 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjbjt26055
	for <mpls@mail-control.mail.uu.net>; Tue, 8 Aug 2000 18:23:34 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjbjt27247
	for <mpls@UU.NET>; Tue, 8 Aug 2000 14:23:09 -0400 (EDT)
Received: from picard.noroff.no by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [212.20.204.3])
	id QQjbjt25271
	for <mpls@UU.NET>; Tue, 8 Aug 2000 18:22:53 GMT
Received: by picard.noroff.no (Postfix, from userid 815)
	id C7F9522003; Tue,  8 Aug 2000 21:06:54 +0200 (CEST)
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177])
	by picard.noroff.no (Postfix) with ESMTP id 1E426B3802
	for <magg@NOROFF.NO>; Tue,  8 Aug 2000 21:06:52 +0200 (CEST)
Received: (from adm@localhost)
	by loki.ietf.org (8.9.1b+Sun/8.9.1) id NAA29228
	for ietf-123-outbound.09@ietf.org; Tue, 8 Aug 2000 13:45:02 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])
	by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id KAA26822
	for <all-ietf@loki.ietf.org>; Tue, 8 Aug 2000 10:19:18 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03842;
	Tue, 8 Aug 2000 10:19:14 -0400 (EDT)
Message-Id: <200008081419.KAA03842@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;
Cc: mpls@UU.NET
From: Internet-Drafts@ietf.org
Reply-To: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mpls-ldp-applic-02.txt
Date: Tue, 08 Aug 2000 10:19:14 -0400
X-AntiVirus: scanned for viruses by AMaViS 0.2.1-pre2 (http://amavis.org/)
Sender: owner-mpls@UU.NET
Precedence: bulk

--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		: LDP Applicability
	Author(s)	: B. Thomas, E. Gray
	Filename	: draft-ietf-mpls-ldp-applic-02.txt
	Pages		: 6
	Date		: 07-Aug-00
	
Multiprotocol Label Switching (MPLS) is a method for forwarding
packets that uses short, fixed-length values carried by packets,
called labels, to determine packet nexthops [MPLS-ARCH]).  A
fundamental concept in MPLS is that two Label Switching Routers
(LSRs) must agree on the meaning of the labels used to forward
traffic between and through them.  This common understanding is
achieved by using a set of procedures, called a label distribution
protocol, by which one LSR informs another of label bindings it has
made.  This document describes the applicability of a set of such
procedures called LDP (for Label Distribution Protocol) [LDP] by
wich LSRs distribute labels to support MPLS forwarding along
normally routed paths.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-applic-02.txt

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-ldp-applic-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-mpls-ldp-applic-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:	<20000807142336.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mpls-ldp-applic-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mpls-ldp-applic-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000807142336.I-D@ietf.org>

--OtherAccess--

--NextPart--





From owner-mpls@UU.NET  Tue Aug  8 14:30:40 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13951
	for <mpls-archive@lists.ietf.org>; Tue, 8 Aug 2000 14:30:38 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbju24925;
	Tue, 8 Aug 2000 18:30:36 GMT
Received: by mail-control.mail.uu.net 
	id QQjbju26660
	for mpls-outgoing; Tue, 8 Aug 2000 18:30:15 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjbju26655
	for <mpls@mail-control.mail.uu.net>; Tue, 8 Aug 2000 18:30:12 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbjt28407
	for <mpls@uu.net>; Tue, 8 Aug 2000 14:29:31 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjbjt24302
	for <mpls@uu.net>; Tue, 8 Aug 2000 18:29:31 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA07014
	for mpls@uu.net; Tue, 8 Aug 2000 14:29:30 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjbjt26525
	for <mpls@mail-control.mail.uu.net>; Tue, 8 Aug 2000 18:28:44 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbjt28174
	for <mpls@UU.NET>; Tue, 8 Aug 2000 14:28:08 -0400 (EDT)
Received: from picard.noroff.no by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [212.20.204.3])
	id QQjbjt23699
	for <mpls@UU.NET>; Tue, 8 Aug 2000 18:28:07 GMT
Received: by picard.noroff.no (Postfix, from userid 815)
	id 4B10A22003; Tue,  8 Aug 2000 21:12:08 +0200 (CEST)
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177])
	by picard.noroff.no (Postfix) with ESMTP id D8F97B3802
	for <magg@NOROFF.NO>; Tue,  8 Aug 2000 21:11:42 +0200 (CEST)
Received: (from adm@localhost)
	by loki.ietf.org (8.9.1b+Sun/8.9.1) id NAA29362
	for ietf-123-outbound.09@ietf.org; Tue, 8 Aug 2000 13:55:02 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])
	by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id KAA26829
	for <all-ietf@loki.ietf.org>; Tue, 8 Aug 2000 10:19:23 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03903;
	Tue, 8 Aug 2000 10:19:19 -0400 (EDT)
Message-Id: <200008081419.KAA03903@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;
Cc: mpls@UU.NET
From: Internet-Drafts@ietf.org
Reply-To: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mpls-ldp-09.txt
Date: Tue, 08 Aug 2000 10:19:19 -0400
X-AntiVirus: scanned for viruses by AMaViS 0.2.1-pre2 (http://amavis.org/)
Sender: owner-mpls@UU.NET
Precedence: bulk

--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		: LDP Specification
	Author(s)	: L. Andersson, P. Doolan, N. Feldman,
                          A. Fredette, B. Thomas
	Filename	: draft-ietf-mpls-ldp-09.txt
	Pages		: 135
	Date		: 07-Aug-00
	
The architecture for Multi Protocol Label Switching (MPLS) is
described in [ARCH].  A fundamental concept in MPLS is that two Label
Switching Routers (LSRs) must agree on the meaning of the labels used
to forward traffic between and through them.  This common
understanding is achieved by using a set of procedures, called a
label distribution protocol, by which one LSR informs another of
label bindings it has made.  This document defines a set of such
procedures called LDP (for Label Distribution Protocol) by which LSRs
distribute labels to support MPLS forwarding along normally routed
paths [LDPAPPLIC].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-09.txt

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-ldp-09.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-ldp-09.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:	<20000807142347.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mpls-ldp-09.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mpls-ldp-09.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000807142347.I-D@ietf.org>

--OtherAccess--

--NextPart--





From owner-mpls@UU.NET  Tue Aug  8 14:32:12 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14920
	for <mpls-archive@lists.ietf.org>; Tue, 8 Aug 2000 14:32:12 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbju03053;
	Tue, 8 Aug 2000 18:32:09 GMT
Received: by mail-control.mail.uu.net 
	id QQjbju26810
	for mpls-outgoing; Tue, 8 Aug 2000 18:31:33 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjbju26788
	for <mpls@mail-control.mail.uu.net>; Tue, 8 Aug 2000 18:31:14 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbju22117
	for <mpls@uu.net>; Tue, 8 Aug 2000 14:30:20 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjbju24721
	for <mpls@uu.net>; Tue, 8 Aug 2000 18:30:19 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA07390
	for mpls@uu.net; Tue, 8 Aug 2000 14:30:19 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjbjt26577
	for <mpls@mail-control.mail.uu.net>; Tue, 8 Aug 2000 18:29:24 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbjt21673
	for <mpls@UU.NET>; Tue, 8 Aug 2000 14:28:34 -0400 (EDT)
Received: from mail-gw.hursley.ibm.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-gw.hursley.ibm.com [194.196.110.15])
	id QQjbjt23891
	for <mpls@UU.NET>; Tue, 8 Aug 2000 18:28:18 GMT
Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id TAA155956; Tue, 8 Aug 2000 19:26:04 +0100
Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id TAA22686; Tue, 8 Aug 2000 19:26:52 +0100 (BST)
Message-ID: <3990502A.9FC4C65F@hursley.ibm.com>
Date: Tue, 08 Aug 2000 13:23:38 -0500
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en,fr
MIME-Version: 1.0
To: erosen@cisco.com
CC: neil.2.harrison@bt.com, ewgray@mindspring.com,
        loa.andersson@nortelnetworks.com, dallan@nortelnetworks.com,
        sbrim@cisco.com, oran@cisco.com, mpls@UU.NET, iesg@ietf.org,
        iab@ISI.EDU
Subject: Re: Use of the term "end-to-end"
References: <200008081648.MAA05449@erosen-sun.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Eric,

There isn't a capsule definition, but section 2.3 discusses e2e in 
some detail, and cites the classic reference. There is further
analysis of end-to-endness in RFC 2775, section 2.

As a matter of fact this is something that OSI recognised too.
The notion of an end-system is well defined in OSI, and the
Internet's end-to-end principle applies between end-systems.

Not between termination points of subnet technologies
such as ATM, Ethernet, frame relay, MPLS, or whatever.

  Brian

Eric Rosen wrote:
> 
> (I don't know why I want to add more to this silly thread, but ...)
> 
> Could someone  quote the passage in  RFC 1958 that  defines "end-to-end"?  I
> can't seem to locate it.



From owner-mpls@UU.NET  Tue Aug  8 14:37:55 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17944
	for <mpls-archive@lists.ietf.org>; Tue, 8 Aug 2000 14:37:54 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbju28155;
	Tue, 8 Aug 2000 18:37:46 GMT
Received: by mail-control.mail.uu.net 
	id QQjbju27196
	for mpls-outgoing; Tue, 8 Aug 2000 18:37:13 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjbju27191
	for <mpls@mail-control.mail.uu.net>; Tue, 8 Aug 2000 18:37:11 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbju29676
	for <mpls@uu.net>; Tue, 8 Aug 2000 14:36:22 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjbju27317
	for <mpls@uu.net>; Tue, 8 Aug 2000 18:36:05 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA09496
	for mpls@uu.net; Tue, 8 Aug 2000 14:36:05 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjbju27019
	for <mpls@mail-control.mail.uu.net>; Tue, 8 Aug 2000 18:34:57 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjbju22927
	for <mpls@uu.net>; Tue, 8 Aug 2000 14:34:19 -0400 (EDT)
Received: from ertpg14e1.nortelnetworks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ertpg14e1.nortelnetworks.com [47.234.0.35])
	id QQjbju04970
	for <mpls@uu.net>; Tue, 8 Aug 2000 18:34:19 GMT
Received: from zsc4c002.corpwest.baynetworks.com 
          by ertpg14e1.nortelnetworks.com; Tue, 8 Aug 2000 14:33:52 -0400
Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) 
          by zsc4c002.corpwest.baynetworks.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) 
          id QHJP7P3N; Tue, 8 Aug 2000 11:33:45 -0700
Received: from americasm06.nt.com (cheevers.engeast.baynetworks.com [192.32.134.63]) 
          by zbl6c002.corpeast.baynetworks.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) 
          id QG9ZGM62; Tue, 8 Aug 2000 14:32:55 -0400
Message-ID: <39905258.84B967E6@americasm06.nt.com>
Date: Tue, 08 Aug 2000 14:32:56 -0400
From: "Seshu Ganugapati" <sganugap@nortelnetworks.com>
Organization: Nortel Networks
X-Mailer: Mozilla 4.08 [en] (X11; U; SunOS 5.5.1 sun4m)
MIME-Version: 1.0
To: mpls@UU.NET
Subject: subscribe
Content-Type: multipart/alternative;
              boundary="------------A68C1A0FAEFE09ED2AD08544"
Sender: owner-mpls@UU.NET
Precedence: bulk


--------------A68C1A0FAEFE09ED2AD08544
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

subscribe seshug@nortelnetworks.com

--
Seshu S Ganugapati
IP networking Solutions,  Nortelnetworks
Email: seshug@nortelnetworks.com
Voice: ESN: 248-6534  External:(978)288-6534
"All network roads don't lead to Rome - they lead to IP"



--------------A68C1A0FAEFE09ED2AD08544
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<BODY TEXT="#000000" BGCOLOR="#FFCCCC" LINK="#3333FF" VLINK="#FF0000" ALINK="#000088">
subscribe seshug@nortelnetworks.com
<PRE>--&nbsp;
Seshu S Ganugapati
IP networking Solutions,&nbsp; Nortelnetworks
Email: seshug@nortelnetworks.com&nbsp;
Voice: ESN: 248-6534&nbsp; External:(978)288-6534
"All network roads don't lead to Rome - they lead to IP"</PRE>
&nbsp;
</BODY>
</HTML>

--------------A68C1A0FAEFE09ED2AD08544--




From owner-mpls@UU.NET  Tue Aug  8 14:44:25 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21370
	for <mpls-archive@lists.ietf.org>; Tue, 8 Aug 2000 14:44:24 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbju12569;
	Tue, 8 Aug 2000 18:44:22 GMT
Received: by mail-control.mail.uu.net 
	id QQjbju27642
	for mpls-outgoing; Tue, 8 Aug 2000 18:43:34 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjbju27627
	for <mpls@mail-control.mail.uu.net>; Tue, 8 Aug 2000 18:43:29 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbju24553
	for <mpls@uu.net>; Tue, 8 Aug 2000 14:42:24 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjbju00488
	for <mpls@uu.net>; Tue, 8 Aug 2000 18:42:24 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA11112
	for mpls@uu.net; Tue, 8 Aug 2000 14:42:23 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjbju27477
	for <mpls@mail-control.mail.uu.net>; Tue, 8 Aug 2000 18:41:21 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjbju24099
	for <mpls@UU.NET>; Tue, 8 Aug 2000 14:40:28 -0400 (EDT)
Received: from picard.noroff.no by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [212.20.204.3])
	id QQjbju09475
	for <mpls@UU.NET>; Tue, 8 Aug 2000 18:40:11 GMT
Received: by picard.noroff.no (Postfix, from userid 815)
	id 5DFE122003; Tue,  8 Aug 2000 21:24:12 +0200 (CEST)
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177])
	by picard.noroff.no (Postfix) with ESMTP id 96776B3802
	for <magg@NOROFF.NO>; Tue,  8 Aug 2000 21:24:10 +0200 (CEST)
Received: (from adm@localhost)
	by loki.ietf.org (8.9.1b+Sun/8.9.1) id OAA29469
	for ietf-123-outbound.09@ietf.org; Tue, 8 Aug 2000 14:05:02 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])
	by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id KAA26836
	for <all-ietf@loki.ietf.org>; Tue, 8 Aug 2000 10:19:28 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03957;
	Tue, 8 Aug 2000 10:19:24 -0400 (EDT)
Message-Id: <200008081419.KAA03957@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;
Cc: mpls@UU.NET
From: Internet-Drafts@ietf.org
Reply-To: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mpls-vcid-atm-05.txt
Date: Tue, 08 Aug 2000 10:19:23 -0400
X-AntiVirus: scanned for viruses by AMaViS 0.2.1-pre2 (http://amavis.org/)
Sender: owner-mpls@UU.NET
Precedence: bulk

--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		: VCID Notification over ATM link for LDP
	Author(s)	: K. Nagami, N. Demizu, H. Esaki, 
                          Y. Katsube, P. Doolan
	Filename	: draft-ietf-mpls-vcid-atm-05.txt
	Pages		: 16
	Date		: 07-Aug-00
	
The ATM Label Switching Router (ATM-LSR) is one of the major
applications of label switching. Because the ATM layer labels (VPI
and VCI) associated with a VC rewritten with new value at every ATM
switch nodes, it is not possible to use them to identify a VC in
label mapping messages. The concept of Virtual Connection Identifier
(VCID) is introduced to solve this problem.  VCID has the same value
at both ends of a VC.  This document specifies the procedures for the
communication of VCID values between neighboring ATM-LSRs that must
occur in order to ensure this property.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-vcid-atm-05.txt

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-vcid-atm-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mpls-vcid-atm-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20000807142357.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mpls-vcid-atm-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mpls-vcid-atm-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000807142357.I-D@ietf.org>

--OtherAccess--

--NextPart--





From owner-mpls@UU.NET  Tue Aug  8 15:02:54 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01818
	for <mpls-archive@lists.ietf.org>; Tue, 8 Aug 2000 15:02:54 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbjw26451;
	Tue, 8 Aug 2000 19:02:47 GMT
Received: by mail-control.mail.uu.net 
	id QQjbjw05204
	for mpls-outgoing; Tue, 8 Aug 2000 19:02:06 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjbjw05199
	for <mpls@mail-control.mail.uu.net>; Tue, 8 Aug 2000 19:02:01 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbjv27278
	for <mpls@uu.net>; Tue, 8 Aug 2000 14:58:28 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjbjv06024
	for <mpls@uu.net>; Tue, 8 Aug 2000 18:58:12 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA14724
	for mpls@uu.net; Tue, 8 Aug 2000 14:58:12 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjbjv28552
	for <mpls@mail-control.mail.uu.net>; Tue, 8 Aug 2000 18:56:35 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbjv26769
	for <mpls@uu.net>; Tue, 8 Aug 2000 14:55:19 -0400 (EDT)
Received: from ertpg14e1.nortelnetworks.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ertpg14e1.nortelnetworks.com [47.234.0.35])
	id QQjbjv05227
	for <mpls@uu.net>; Tue, 8 Aug 2000 18:55:19 GMT
Received: from zsc4c002.corpwest.baynetworks.com 
          by ertpg14e1.nortelnetworks.com; Tue, 8 Aug 2000 14:52:41 -0400
Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) 
          by zsc4c002.corpwest.baynetworks.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) 
          id QHJP7R4Y; Tue, 8 Aug 2000 11:52:39 -0700
Received: from americasm06.nt.com (cheevers.engeast.baynetworks.com [192.32.134.63]) 
          by zbl6c002.corpeast.baynetworks.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) 
          id QG9ZGM8K; Tue, 8 Aug 2000 14:51:49 -0400
Message-ID: <399056C6.2AD34A25@americasm06.nt.com>
Date: Tue, 08 Aug 2000 14:51:50 -0400
From: "Seshu Ganugapati" <sganugap@nortelnetworks.com>
Organization: Nortel Networks
X-Mailer: Mozilla 4.08 [en] (X11; U; SunOS 5.5.1 sun4m)
MIME-Version: 1.0
To: mpls@UU.NET
Subject: authenticate
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


auth 4c31c1a5 subscribe mpls seshug@nortelnetworks.com




From owner-mpls@UU.NET  Tue Aug  8 15:14:37 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09105
	for <mpls-archive@lists.ietf.org>; Tue, 8 Aug 2000 15:14:36 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbjw12493;
	Tue, 8 Aug 2000 19:14:24 GMT
Received: by mail-control.mail.uu.net 
	id QQjbjw11305
	for mpls-outgoing; Tue, 8 Aug 2000 19:13:26 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjbjw11300
	for <mpls@mail-control.mail.uu.net>; Tue, 8 Aug 2000 19:13:21 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjbjw06287
	for <mpls@uu.net>; Tue, 8 Aug 2000 15:11:04 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11])
	id QQjbjw02527
	for <mpls@uu.net>; Tue, 8 Aug 2000 19:10:34 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id MAA22065
	for <mpls@uu.net>; Tue, 8 Aug 2000 12:10:49 -0700 (PDT)
Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id PAA05945 for mpls@uu.net; Tue, 8 Aug 2000 15:10:32 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjbjn27746
	for <mpls@mail-control.mail.uu.net>; Tue, 8 Aug 2000 16:50:07 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbjn09543
	for <mpls@UU.NET>; Tue, 8 Aug 2000 12:49:24 -0400 (EDT)
Received: from inner.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: avarice.inner.net [199.33.248.2])
	id QQjbjn12553
	for <mpls@UU.NET>; Tue, 8 Aug 2000 16:49:23 GMT
Received: from mosquito ([216.52.8.30])
	by inner.net (8.7.6/8.9.3) with ESMTP id QAA07347;
	Tue, 8 Aug 2000 16:47:50 GMT
Message-Id: <4.2.0.58.20000808124151.0099a990@avarice.inner.net>
X-Sender: rja@avarice.inner.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Tue, 08 Aug 2000 12:43:30 -0400
To: ssnarayanan@lucent.com
From: RJ Atkinson <rja@inet.org>
Subject: Re: Use of the term "end-to-end"
Cc: Brian E Carpenter <brian@hursley.ibm.com>, neil.2.harrison@bt.com,
        ewgray@mindspring.com, loa.andersson@nortelnetworks.com,
        dallan@nortelnetworks.com, sbrim@cisco.com, oran@cisco.com,
        mpls@UU.NET, iesg@ietf.org, iab@ISI.EDU
In-Reply-To: <3990338E.71747B8F@hotair.hobl.lucent.com>
References: <B9571FDEBD3DD21181E500606DD5EE0507B162AA@mbddmknt01.hc.bt.com>
 <39901D3A.CF9754C9@hursley.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-mpls@UU.NET
Precedence: bulk

Shiva,

	You are confused.  The term "end-to-end" is very well
defined within the IETF and Internet community as several 
folks have noted with references.  Please cease and desist in 
trying to change its meaning.  Other kind folk have suggested
various more precise and more clear terms for the MPLS context,
which is sensible since MPLS is not end-to-end.

Thank you kindly,

Ran
rja@inet.org




From owner-mpls@UU.NET  Tue Aug  8 15:51:14 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01735
	for <mpls-archive@lists.ietf.org>; Tue, 8 Aug 2000 15:51:13 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbjz25862;
	Tue, 8 Aug 2000 19:51:06 GMT
Received: by mail-control.mail.uu.net 
	id QQjbjz14163
	for mpls-outgoing; Tue, 8 Aug 2000 19:50:21 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjbjz14149
	for <mpls@mail-control.mail.uu.net>; Tue, 8 Aug 2000 19:50:15 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjbjz13041
	for <mpls@UU.NET>; Tue, 8 Aug 2000 15:49:20 -0400 (EDT)
Received: from smtprch1.nortel.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtprch1.nortelnetworks.com [192.135.215.14])
	id QQjbjz00254
	for <mpls@UU.NET>; Tue, 8 Aug 2000 19:49:19 GMT
Received: from zrchb213.us.nortel.com (actually zrchb213) 
          by smtprch1.nortel.com; Tue, 8 Aug 2000 13:14:06 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <QFL2CBKG>; Tue, 8 Aug 2000 13:13:59 -0500
Message-ID: <6DDA62170439D31185750000F80826AC035F5440@zmerd004.ca.nortel.com>
From: "David Allan" <dallan@nortelnetworks.com>
To: Brian E Carpenter <brian@hursley.ibm.com>, neil.2.harrison@bt.com
Cc: ewgray@mindspring.com, "Loa Andersson" <loa.andersson@nortelnetworks.com>,
        sbrim@cisco.com, oran@cisco.com, mpls@UU.NET, iesg@ietf.org,
        iab@ISI.EDU
Subject: RE: Use of the term "end-to-end"
Date: Tue, 8 Aug 2000 13:13:57 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C00164.6B060D50"
Sender: owner-mpls@UU.NET
Precedence: bulk

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_01C00164.6B060D50
Content-Type: text/plain;
	charset="iso-8859-1"

	Neil:

	If we accept the notion that an LER is where "foo" gets adapted to
run over an LSP (ingress) or converted back to it's non LSP format (egress),
then LER to LER is fine (and directly analagous to your TTL function, when
we are viewing it in the context of an LSP, not a box function). To me it is
self evident that most LSRs would have both adaptation and native forwarding
capability and in LER we are defining a LSP specific function, not a
specific class of LSR. Only if the consensus is that the "non-official use"
of the term LER is already overloaded to only mean a specific box in a
network, do we need "more precise" terminology.

	The other contributors are correct in suggesting that e2e has a
particular "non-subjective" meaning in the IETF context. ;-)

	regards
	Dave

> neil.2.harrison@bt.com wrote:
> > 
> > All,
> > 
> > End-to-end is subjective since it depends on your perspective....think
> about
> > nested LSPs, we have to cater for these.  LER-to-LER is architecturally
> > restrictive being just one specific case of an LSP, and (as Eric points
> out)
> > related to 'current box names'.  I believe we need a generic term that
> > captures the essence of the LSP entity at whatever level it exists in a
> > label stacked hierarchy of LSPs.  If we borrow from functional modelling
> > terminology developed in G.805 by the ITU for SDH and ATM, I suspect
> that
> > 'trail termination points' (ie an LSP exists between them) is the
> closest
> > match to the function we are trying to describe. I attach the extracted
> > references from G.805 below for your information.
> > 3.1     trail termination sink: A "transport processing function" which
> > accepts the characteristic information of the layer network at its
> input,
> > removes the information related to "trail" monitoring and presents the
> > remaining information at its output.
> > 3.2     trail termination source: A "transport processing function"
> which
> > accepts adapted "characteristic information" from a client layer network
> at
> > its input, adds information to allow the "trail" to be monitored and
> > presents the characteristic information of the layer network at its
> output.
> > The trail termination source can operate without an input from a client
> > layer network.
> > 
> > Whilst these are not perfect matches we could start to use them I guess
> (or
> > invent our own).  Also note that as MPLS expands to cover other
> technologies
> > (eg optical networks) then we need a common architectural term for the
> LSP
> > object irrespective of the technology.
> > BTW....I understand the ITU are going to develop a functional model of
> > optical and IP/MPLS networks in due course.
> > 
> > So perhaps we could use LSP_TTP-LSP_TTP (or LTTP-LTTP, or indeed
> whatever
> > looks nice) to define this entity.....and to be honest I don't think its
> > name is that important, just so long as we agree on (functionally) what
> that
> > entity is.
> > 
> > The only thing that concerns me now is PHP......as I said in a mail
> several
> > weeks ago (wrt defect detection and consequent action, eg restoration) I
> > really don't like the idea that the LSP (sink) trail termination point
> is a
> > moveable feast.
> > 
> > Regards, Neil
> > 
> > > -----Original Message-----
> > > From: Eric Gray [SMTP:ewgray@mindspring.com]
> > > Sent: Monday, August 07, 2000 4:57 AM
> > > To:   Loa Andersson
> > > Cc:   David Allan; Scott Brim; David R. Oran; mpls; IESG; IAB
> > > Subject:      Re: Use of the term "end-to-end"
> > >
> > > Loa,
> > >
> > >     I distinctly remember your proposing the term and
> > > its more-or-less being rejected.  Never-the-less, it has
> > > come to be accepted as a real term.  Many slides and
> > > charts now contain some subset of this picture:
> > >
> > >   LER -- LSR -- ... -- LSR -- LER
> > >
> > > While it is still debatable that a box which is exclusively
> > > either an LER or an LSR will be a long-term survivor
> > > in the market place, it is useful to think of LSR verses
> > > LER functionality.
> > >
> > > Loa Andersson wrote:
> > >
> > > > This is fine with me, but the last time (back in the childhood of
> MPLS)
> > > > I tried to propose the term LER as part of the MPLS vocabulary it
> was
> > > > not considered necessary. SO either we add it or use something else.
> > > >
> > > > /Loa
> > > >
> > > > David Allan wrote:
> > > > >
> > > > > Agreed
> > > > >
> > > > >      -----Original Message-----
> > > > >      From:   Scott Brim [SMTP:sbrim@cisco.com]
> > > > >      Sent:   Thursday, August 03, 2000 11:37 AM
> > > > >      To:     David R. Oran
> > > > >      Cc:     mpls; IESG; IAB
> > > > >      Subject:        Re: Use of the term "end-to-end"
> > > > >
> > > > >      LER-to-LER
> > > > >
> > > > >      <snip>
> > > >
> > > > --
> > > >
> > > > Loa Andersson
> > > > Director Routing Architecture Lab, EMEA
> > > > St Eriksgatan 115A, PO Box 6701
> > > > 113 85 Stockholm, Sweden
> > > > phone: +46 8 50 88 36 34,   mobile + 46 70 522 78 34
> > > > e-mail: loa.andersson@nortelnetworks.com

------_=_NextPart_001_01C00164.6B060D50
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: Use of the term &quot;end-to-end&quot;</TITLE>
</HEAD>
<BODY>
<UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Neil:</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">If we accept the =
notion that an LER is where &quot;foo&quot; gets adapted to run over an =
LSP (ingress) or converted back to it's non LSP format (egress), then =
LER to LER is fine (and directly analagous to your TTL function, when =
we are viewing it in the context of an LSP, not a box function). To me =
it is self evident that most LSRs would have both adaptation and native =
forwarding capability and in LER we are defining a LSP specific =
function, not a specific class of LSR. Only if the consensus is that =
the &quot;non-official use&quot; of the term LER is already overloaded =
to only mean a specific box in a network, do we need &quot;more =
precise&quot; terminology.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">The other =
contributors are correct in suggesting that e2e has a particular =
&quot;non-subjective&quot; meaning in the IETF context. ;-)</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">regards</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Dave</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">neil.2.harrison@bt.com wrote:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; All,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; End-to-end is subjective since =
it depends on your perspective....think about</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; nested LSPs, we have to cater =
for these.&nbsp; LER-to-LER is architecturally</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; restrictive being just one =
specific case of an LSP, and (as Eric points out)</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; related to 'current box =
names'.&nbsp; I believe we need a generic term that</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; captures the essence of the LSP =
entity at whatever level it exists in a</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; label stacked hierarchy of =
LSPs.&nbsp; If we borrow from functional modelling</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; terminology developed in G.805 =
by the ITU for SDH and ATM, I suspect that</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; 'trail termination points' (ie =
an LSP exists between them) is the closest</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; match to the function we are =
trying to describe. I attach the extracted</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; references from G.805 below for =
your information.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; 3.1&nbsp;&nbsp;&nbsp;&nbsp; =
trail termination sink: A &quot;transport processing function&quot; =
which</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; accepts the characteristic =
information of the layer network at its input,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; removes the information related =
to &quot;trail&quot; monitoring and presents the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; remaining information at its =
output.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; 3.2&nbsp;&nbsp;&nbsp;&nbsp; =
trail termination source: A &quot;transport processing function&quot; =
which</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; accepts adapted =
&quot;characteristic information&quot; from a client layer network =
at</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; its input, adds information to =
allow the &quot;trail&quot; to be monitored and</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; presents the characteristic =
information of the layer network at its output.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; The trail termination source can =
operate without an input from a client</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; layer network.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Whilst these are not perfect =
matches we could start to use them I guess (or</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; invent our own).&nbsp; Also note =
that as MPLS expands to cover other technologies</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; (eg optical networks) then we =
need a common architectural term for the LSP</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; object irrespective of the =
technology.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; BTW....I understand the ITU are =
going to develop a functional model of</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; optical and IP/MPLS networks in =
due course.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; So perhaps we could use =
LSP_TTP-LSP_TTP (or LTTP-LTTP, or indeed whatever</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; looks nice) to define this =
entity.....and to be honest I don't think its</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; name is that important, just so =
long as we agree on (functionally) what that</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; entity is.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; The only thing that concerns me =
now is PHP......as I said in a mail several</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; weeks ago (wrt defect detection =
and consequent action, eg restoration) I</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; really don't like the idea that =
the LSP (sink) trail termination point is a</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; moveable feast.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Regards, Neil</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; -----Original =
Message-----</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; From: Eric Gray =
[SMTP:ewgray@mindspring.com]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; Sent: Monday, August 07, =
2000 4:57 AM</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; To:&nbsp;&nbsp; Loa =
Andersson</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; Cc:&nbsp;&nbsp; David =
Allan; Scott Brim; David R. Oran; mpls; IESG; IAB</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; =
Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Re: Use of the term =
&quot;end-to-end&quot;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; Loa,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; I =
distinctly remember your proposing the term and</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; its more-or-less being =
rejected.&nbsp; Never-the-less, it has</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; come to be accepted as a =
real term.&nbsp; Many slides and</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; charts now contain some =
subset of this picture:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt;&nbsp;&nbsp; LER -- LSR -- =
... -- LSR -- LER</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; While it is still debatable =
that a box which is exclusively</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; either an LER or an LSR =
will be a long-term survivor</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; in the market place, it is =
useful to think of LSR verses</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; LER functionality.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; Loa Andersson wrote:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; This is fine with me, =
but the last time (back in the childhood of MPLS)</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; I tried to propose the =
term LER as part of the MPLS vocabulary it was</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; not considered =
necessary. SO either we add it or use something else.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; /Loa</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; David Allan =
wrote:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; Agreed</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; From:&nbsp;&nbsp; Scott Brim =
[SMTP:sbrim@cisco.com]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Sent:&nbsp;&nbsp; Thursday, August =
03, 2000 11:37 AM</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; To:&nbsp;&nbsp;&nbsp;&nbsp; David R. =
Oran</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Cc:&nbsp;&nbsp;&nbsp;&nbsp; mpls; =
IESG; IAB</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Re: Use of the term =
&quot;end-to-end&quot;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; LER-to-LER</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;snip&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; --</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; Loa Andersson</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; Director Routing =
Architecture Lab, EMEA</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; St Eriksgatan 115A, PO =
Box 6701</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; 113 85 Stockholm, =
Sweden</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; phone: +46 8 50 88 36 =
34,&nbsp;&nbsp; mobile + 46 70 522 78 34</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; e-mail: =
loa.andersson@nortelnetworks.com</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C00164.6B060D50--


From owner-mpls@UU.NET  Tue Aug  8 16:07:26 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11735
	for <mpls-archive@lists.ietf.org>; Tue, 8 Aug 2000 16:07:25 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbka13901;
	Tue, 8 Aug 2000 20:07:21 GMT
Received: by mail-control.mail.uu.net 
	id QQjbjz14752
	for mpls-outgoing; Tue, 8 Aug 2000 19:59:57 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjbjz14747
	for <mpls@mail-control.mail.uu.net>; Tue, 8 Aug 2000 19:59:50 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbjz14797
	for <mpls@UU.NET>; Tue, 8 Aug 2000 15:58:55 -0400 (EDT)
Received: from ertpg14e1.nortelnetworks.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ertpg14e1.nortelnetworks.com [47.234.0.35])
	id QQjbjz29172
	for <mpls@UU.NET>; Tue, 8 Aug 2000 19:58:55 GMT
Received: from zsc4c002.corpwest.baynetworks.com 
          by ertpg14e1.nortelnetworks.com; Tue, 8 Aug 2000 15:56:34 -0400
Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) 
          by zsc4c002.corpwest.baynetworks.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) 
          id QHJP7XRB; Tue, 8 Aug 2000 12:56:28 -0700
Received: from americasm06.nt.com (cheevers.engeast.baynetworks.com [192.32.134.63]) 
          by zbl6c002.corpeast.baynetworks.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) 
          id QG9ZGNCP; Tue, 8 Aug 2000 15:55:39 -0400
Message-ID: <399065BA.ECDA2180@americasm06.nt.com>
Date: Tue, 08 Aug 2000 15:55:38 -0400
From: "Seshu Ganugapati" <sganugap@nortelnetworks.com>
Organization: Nortel Networks
X-Mailer: Mozilla 4.08 [en] (X11; U; SunOS 5.5.1 sun4m)
MIME-Version: 1.0
To: mpls@UU.NET
Subject: LER-to-LER
Content-Type: multipart/alternative;
              boundary="------------FC6C6152241ED10FCB218D05"
Sender: owner-mpls@UU.NET
Precedence: bulk


--------------FC6C6152241ED10FCB218D05
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

The term LER-to-LER to me sounds more appropriate
as we are going to have the over-all architecture,



---------
-------

IP
IP
       packetIn                 --->   LER     ----> LSR    ----> LER
---->       packet Out

---------
--------



where as Ip---> Ip can still be referred using end-to-end  without
overlaping usage of the
term end-to-end.

Regards
seshu.


--
Seshu S Ganugapati
IP networking Solutions,  Nortelnetworks
Email: seshug@nortelnetworks.com
Voice: ESN: 248-6534  External:(978)288-6534
"All network roads don't lead to Rome - they lead to IP"



--------------FC6C6152241ED10FCB218D05
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<BODY TEXT="#000000" BGCOLOR="#FFCCCC" LINK="#3333FF" VLINK="#FF0000" ALINK="#000088">
The term LER-to-LER to me sounds more appropriate
<BR>as we are going to have the over-all architecture,
<BR>&nbsp;
<P>&nbsp;&nbsp;&nbsp;&nbsp; ---------&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
-------
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
IP
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; packetIn&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
--->&nbsp;&nbsp; LER&nbsp;&nbsp;&nbsp;&nbsp; ----> LSR&nbsp;&nbsp;&nbsp;
----> LER&nbsp; ---->&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; packet Out
<BR>&nbsp;&nbsp;&nbsp; ---------&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
--------
<BR>&nbsp;
<P>&nbsp;
<BR>where as Ip---> Ip can still be referred using end-to-end&nbsp; without
overlaping usage of the
<BR>term end-to-end.
<P>Regards
<BR>seshu.
<BR>&nbsp;
<PRE>--&nbsp;
Seshu S Ganugapati
IP networking Solutions,&nbsp; Nortelnetworks
Email: seshug@nortelnetworks.com&nbsp;
Voice: ESN: 248-6534&nbsp; External:(978)288-6534
"All network roads don't lead to Rome - they lead to IP"</PRE>
&nbsp;
</BODY>
</HTML>

--------------FC6C6152241ED10FCB218D05--



From owner-mpls@UU.NET  Tue Aug  8 16:20:18 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19594
	for <mpls-archive@lists.ietf.org>; Tue, 8 Aug 2000 16:20:17 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbhg03490;
	Tue, 8 Aug 2000 02:01:46 GMT
Received: by mail-control.mail.uu.net 
	id QQjbhg23432
	for mpls-outgoing; Tue, 8 Aug 2000 02:00:29 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjbhg22985
	for <mpls@mail-control.mail.uu.net>; Tue, 8 Aug 2000 02:00:24 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbhf10260
	for <mpls@UU.NET>; Mon, 7 Aug 2000 21:57:12 -0400 (EDT)
Received: from IMRNET.MGT.NCU.EDU.TW by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imrnet.mgt.ncu.edu.tw [140.115.83.16])
	id QQjbhf10872
	for <mpls@UU.NET>; Tue, 8 Aug 2000 01:57:11 GMT
Received: (from gskuo@localhost)
	by IMRNET.MGT.NCU.EDU.TW (8.9.3/8.9.3) id JAA13440;
	Tue, 8 Aug 2000 09:47:53 +0800 (CST)
Date: Tue, 8 Aug 2000 09:47:53 +0800 (CST)
From: "G.S. Kuo" <gskuo@IMRNET.MGT.NCU.EDU.TW>
Message-Id: <200008080147.JAA13440@IMRNET.MGT.NCU.EDU.TW>
To: gja@dnrc.bell-labs.com
Subject: Re: Use of the term "end-to-end"
Cc: iesg@ietf.org, mpls@UU.NET
Sender: owner-mpls@UU.NET
Precedence: bulk

Grenville,

I support your point.

G.S.
-----------------------------------------------
Date: Mon, 07 Aug 2000 16:15:33 -0700
From: Grenville Armitage <gja@dnrc.bell-labs.com>
To: Scott Brim <sbrim@cisco.com>
CC: mpls@UU.NET, IESG <iesg@ietf.org>, IAB <iab@isi.edu>
Subject: Re: Use of the term "end-to-end"

LER-to-LER makes sense because it contains the notion
of "edge" (the 'E' in LER) as opposed to "end".  Which makes
me think the better phrase is just "edge to edge" since it really
isn't a new term per se, generalizes neatly to similar concepts
in Diffserv, and captures the non-end2end nature of what we're talking
about without constraining the mental model to start/end on an
MPLS-specific functional element.

cheers,
gja

Scott Brim wrote:
        [..]
> But (1) we can do the right thing and not use "end-to-end" in a way that
> further erodes its meaning. and (2) if it's a confusing term then we
> shouldn't use it anyway.  I like LER because it's a clearly defined
> functionality, within the context of MPLS, regardless of whether the box
> that is an LER is doing other things as well.


From owner-mpls@UU.NET  Tue Aug  8 17:12:06 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19374
	for <mpls-archive@lists.ietf.org>; Tue, 8 Aug 2000 17:12:05 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbke13447;
	Tue, 8 Aug 2000 21:11:56 GMT
Received: by mail-control.mail.uu.net 
	id QQjbke13402
	for mpls-outgoing; Tue, 8 Aug 2000 21:11:03 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjbke13353
	for <mpls@mail-control.mail.uu.net>; Tue, 8 Aug 2000 21:10:58 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjbke01873
	for <mpls@UU.NET>; Tue, 8 Aug 2000 17:09:55 -0400 (EDT)
Received: from icarian.ZAFFIRE.COM by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ATHM-64-232-xxx-132.home.net [64.232.69.132] (may be forged))
	id QQjbke11875
	for <mpls@UU.NET>; Tue, 8 Aug 2000 21:09:54 GMT
Received: by ICARIAN with Internet Mail Service (5.5.2650.21)
	id <QHM3ZBYM>; Tue, 8 Aug 2000 14:17:36 -0700
Message-ID: <4D3F9F2BEC58D4118FCE009027B0A6621360C1@ICARIAN>
From: Eric Gray <EGray@zaffire.com>
To: "'erosen@cisco.com'" <erosen@cisco.com>,
        Brian E Carpenter
	 <brian@hursley.ibm.com>
Cc: neil.2.harrison@bt.com, ewgray@mindspring.com,
        loa.andersson@nortelnetworks.com, dallan@nortelnetworks.com,
        sbrim@cisco.com, oran@cisco.com, iab@ISI.EDU,
        "'RJ Atkinson'"
	 <rja@inet.org>, mpls@UU.NET, iesg@ietf.org
Subject: RE: Use of the term "end-to-end" 
Date: Tue, 8 Aug 2000 14:17:35 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Eric (Rosen) brings up a very good point.  Many
of the long-term IETFers (e.g. - Brian and Ran)
are familar with A MEANING of the term end-to-end.
RFC 1958 is absolutely rife with implied meaning, 
but no actual definition.  I guess the meaning was 
too obvious at that time to need defining.

But the implied meaning is actually "end-system-
to-end-system" which - at that time - meant host
to host.  I guess that "end-to-end" was easier to
say.  Since the advent of IP-in-IP tunneling and 
similar technological approaches (e.g. - MPLS), 
this meaning has become obsolete (no implied 
insult to long-term IETFers).  The meaning of
end-system becomes a little fuzzy when you add
the possibility of hierarchy.

So I don't think that people need to get huffy
about "misusing" the term.

However, I am perfectly happy to use LER-to-LER
(I don't think introducing additional options
- i.e. LIP, LEP, LAP, LOP, etc. - is helpful).


> -----Original Message-----
> From: Eric Rosen [mailto:erosen@cisco.com]
> Sent: Tuesday, August 08, 2000 9:49 AM
> To: Brian E Carpenter
> Cc: neil.2.harrison@bt.com; ewgray@mindspring.com;
> loa.andersson@nortelnetworks.com; dallan@nortelnetworks.com;
> sbrim@cisco.com; oran@cisco.com; mpls@UU.NET; iesg@ietf.org; 
> iab@ISI.EDU
> Subject: Re: Use of the term "end-to-end" 
> 
> 
> (I don't know why I want to add more to this silly thread, but ...)
> 
> Could someone  quote the passage in  RFC 1958 that  defines 
> "end-to-end"?  I
> can't seem to locate it.  
> 
> 


From owner-mpls@UU.NET  Tue Aug  8 19:38:31 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01811
	for <mpls-archive@lists.ietf.org>; Tue, 8 Aug 2000 19:38:31 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbko23489;
	Tue, 8 Aug 2000 23:38:27 GMT
Received: by mail-control.mail.uu.net 
	id QQjbko20254
	for mpls-outgoing; Tue, 8 Aug 2000 23:37:40 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjbko20229
	for <mpls@mail-control.mail.uu.net>; Tue, 8 Aug 2000 23:37:33 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbko14752
	for <mpls@UU.NET>; Tue, 8 Aug 2000 19:35:51 -0400 (EDT)
From: neil.2.harrison@bt.com
Received: from marvin.axion.bt.co.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: marvin.axion.bt.co.uk [132.146.16.82])
	id QQjbko11826
	for <mpls@UU.NET>; Tue, 8 Aug 2000 23:35:36 GMT
Received: from cclmsent02.lon.bt.com by marvin (local) with ESMTP;
          Wed, 9 Aug 2000 00:35:09 +0100
Received: by cclmsent02.lon.bt.com with Internet Mail Service (5.5.2651.88) 
          id <P207PVCD>; Wed, 9 Aug 2000 00:34:56 +0100
Message-ID: <B9571FDEBD3DD21181E500606DD5EE0507B162B3@mbddmknt01.hc.bt.com>
To: brian@hursley.ibm.com
Cc: ewgray@mindspring.com, loa.andersson@nortelnetworks.com,
        dallan@nortelnetworks.com, sbrim@cisco.com, oran@cisco.com,
        mpls@UU.NET, iesg@ietf.org, iab@ISI.EDU
Subject: RE: Use of the term "end-to-end"
Date: Wed, 9 Aug 2000 00:34:03 +0100 
X-Mailer: Internet Mail Service (5.5.2651.88)
MIME-version: 1.0
Content-type: text/plain; charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Brian,

This is going to be the last one from me on this topic as it is not worth
the BW.

I know the end-end tenet for old-school IP (ie host-host), and I agree with
its sentiment in that perspective..... but you are missing the architectural
point I am making.  But when one is dealing with LSPs which start/terminate
at some other 'end-to-end' points this is quite different.....and when they
are nested, clearly their start/stop points are *subjective* to the
perspective of whoever is operating them at level N.  Please try to think
more openly......if it helps consider an SDH VC4 or a WDM lamba or even an
ATM VP....these trails have their own 'end-to-end' meaning which is not
wrong from *their* perspective.  And here we are dealing with LSPs which
quite clearly fall into such a classification - how anyone could say
otherwise would defy belief.

To be more rigorous however, an LSP starts at the point at which the label
and other overhead (specific to that LSP) at level N, and it terminates at
the point at which the label and other overhead is removed at level N.  And
from that particular LSPs perspective that is end-to-end.

The-end:  Neil   

> -----Original Message-----
> From:	Brian E Carpenter [SMTP:brian@hursley.ibm.com]
> Sent:	Tuesday, August 08, 2000 3:46 PM
> To:	neil.2.harrison@bt.com
> Cc:	ewgray@mindspring.com; loa.andersson@nortelnetworks.com;
> dallan@nortelnetworks.com; sbrim@cisco.com; oran@cisco.com; mpls@UU.NET;
> iesg@ietf.org; iab@ISI.EDU
> Subject:	Re: Use of the term "end-to-end"
> 
> No, end-to-end is very explicit in the Internet and not at all
> subjective. Please see RFC 1958.
> 
>    Brian
> 
> neil.2.harrison@bt.com wrote:
> > 
> > All,
> > 
> > End-to-end is subjective since it depends on your perspective....think
> about
> > nested LSPs, we have to cater for these.  LER-to-LER is architecturally
> > restrictive being just one specific case of an LSP, and (as Eric points
> out)
> > related to 'current box names'.  I believe we need a generic term that
> > captures the essence of the LSP entity at whatever level it exists in a
> > label stacked hierarchy of LSPs.  If we borrow from functional modelling
> > terminology developed in G.805 by the ITU for SDH and ATM, I suspect
> that
> > 'trail termination points' (ie an LSP exists between them) is the
> closest
> > match to the function we are trying to describe. I attach the extracted
> > references from G.805 below for your information.
> > 3.1     trail termination sink: A "transport processing function" which
> > accepts the characteristic information of the layer network at its
> input,
> > removes the information related to "trail" monitoring and presents the
> > remaining information at its output.
> > 3.2     trail termination source: A "transport processing function"
> which
> > accepts adapted "characteristic information" from a client layer network
> at
> > its input, adds information to allow the "trail" to be monitored and
> > presents the characteristic information of the layer network at its
> output.
> > The trail termination source can operate without an input from a client
> > layer network.
> > 
> > Whilst these are not perfect matches we could start to use them I guess
> (or
> > invent our own).  Also note that as MPLS expands to cover other
> technologies
> > (eg optical networks) then we need a common architectural term for the
> LSP
> > object irrespective of the technology.
> > BTW....I understand the ITU are going to develop a functional model of
> > optical and IP/MPLS networks in due course.
> > 
> > So perhaps we could use LSP_TTP-LSP_TTP (or LTTP-LTTP, or indeed
> whatever
> > looks nice) to define this entity.....and to be honest I don't think its
> > name is that important, just so long as we agree on (functionally) what
> that
> > entity is.
> > 
> > The only thing that concerns me now is PHP......as I said in a mail
> several
> > weeks ago (wrt defect detection and consequent action, eg restoration) I
> > really don't like the idea that the LSP (sink) trail termination point
> is a
> > moveable feast.
> > 
> > Regards, Neil
> > 
> > > > e-mail: loa.andersson@nortelnetworks.com


From owner-mpls@UU.NET  Tue Aug  8 22:04:23 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14498
	for <mpls-archive@lists.ietf.org>; Tue, 8 Aug 2000 22:04:23 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbky18966;
	Wed, 9 Aug 2000 02:04:20 GMT
Received: by mail-control.mail.uu.net 
	id QQjbky03942
	for mpls-outgoing; Wed, 9 Aug 2000 02:03:38 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjbky03630
	for <mpls@mail-control.mail.uu.net>; Wed, 9 Aug 2000 02:03:19 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbky06932
	for <mpls@uu.net>; Tue, 8 Aug 2000 22:01:13 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjbky25976
	for <mpls@uu.net>; Wed, 9 Aug 2000 02:00:42 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id WAA01791
	for mpls@uu.net; Tue, 8 Aug 2000 22:00:41 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjbky28352
	for <mpls@mail-control.mail.uu.net>; Wed, 9 Aug 2000 02:00:02 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbkx29403
	for <mpls@UU.NET>; Tue, 8 Aug 2000 21:58:11 -0400 (EDT)
Received: from mailgate.sbell.com.cn by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.sbell.com.cn [202.96.203.173])
	id QQjbkx24563
	for <mpls@UU.NET>; Wed, 9 Aug 2000 01:57:39 GMT
Received: from sdc.sbell.com.cn (sdc.sbell.com.cn [138.203.222.11])
	by mailgate.sbell.com.cn (8.9.2/8.9.2) with ESMTP id JAA16424;
	Wed, 9 Aug 2000 09:50:48 +0800 (CST)
Received: from bbx015.sbell.com.cn (bbx015 [138.203.222.185])
	by sdc.sbell.com.cn (8.9.1/8.9.1) with ESMTP id JAA06713;
	Wed, 9 Aug 2000 09:57:06 +0800 (CST)
Received: from sh.bel.alcatel.be (localhost [127.0.0.1])
	by bbx015.sbell.com.cn (8.9.1/8.9.1) with ESMTP id SAA16235;
	Tue, 8 Aug 2000 18:52:52 -0700 (PDT)
Message-ID: <3990B973.D1765B2D@sh.bel.alcatel.be>
Date: Wed, 09 Aug 2000 09:52:52 +0800
From: Gu Yuan <guy@sh.bel.alcatel.be>
X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Lou Berger <lberger@labn.net>
CC: mpls@UU.NET, swallow@cisco.com
Subject: Re: Fwd: RSVP-LSP-TUNNEL
References: <4.3.2.7.2.20000807182340.00d33ef0@mail.labn.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Lou Berger wrote:

> FYI -
>
> >Reply-To: <iana@iana.org>
> >From: "IANA" <iana@ISI.EDU>
> >To: <swallow@cisco.com>, <lberger@labn.net>
> >Cc: <braden@ISI.EDU>
> >Subject: RSVP-LSP-TUNNEL
> >Date: Mon, 7 Aug 2000 15:02:32 -0700
> >X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
> >Importance: Normal
> >
> >George and Lou,
> >
> >We have updated the RSVP-parameters file.  We apologize for long
> >delay in completing this.  This is to confirm that we have assigned
> >all the values requested to the RSVP protocol parameters file.  Please
> >check the following file for these assignments:
> >
> ><http://www.isi.edu/in-notes/iana/assignments/rsvp-parameters>
> >
> >Thank you,
> >
> >Michelle Schipper
> >IANA
> >
> >Requested Assignments below (**changes)
> >----------------------------------------------------------------------------
> >Object and C-Type Assignments:
> >
> >LABEL Object  (this is already assigned, but should change from Davie
> >                to the RFC number which gets assigned.)
> >    LABEL class = 16
> >
> >Label Request Object
> >    LABEL_REQUEST Class = 19
> >    Label Request without Label Range            C_Type = 1
> >    Label Request with ATM Label Range           C_Type = 2
> >    Label Request with Frame Relay Label Range   C_Type = 3
> >
> >Explicit Route Object
> >     EXPLICIT_ROUTE Class = 20
> >     Type 1 Explicit Route                       C_Type = 1
> >
> >   Subobjects of the Type 1 EXPLICIT_ROUTE object
> >     0   Reserved
> >     1   IPv4 prefix
> >     2   IPv6 prefix
> >    32   Autonomous system number
> >
> >Record Route Object
> >     ROUTE_RECORD Class = 21
> >     Type 1 Record Route                          C_Type = 1
> >
> >   Subobjects of the Type 1 RECORD_ROUTE object
> >     0   Reserved
> >     1   IPv4 address
> >     2   IPv6 address
> >
> >Session Object
> >    LSP_TUNNEL_IPv4   C-Type = 7
> >    LSP_TUNNEL_IPv6   C-Type = 8
> >
> >Sender Template Object
> >    LSP_TUNNEL_IPv4   C-Type = 7
> >    LSP_TUNNEL_IPv6   C-Type = 8
> >
> >Filter Specification Object
> >    LSP_TUNNEL_IPv4   C-Type = 7
> >    LSP_TUNNEL_IPv6   C-Type = 8
> >
> >SESSION_ATTRIBUTE object
> >    Session Attribute Class = 207
> >    LSP_TUNNEL       C-Type = 7
> >
> >Sender Tspec Object
> >     Class-of-Service  C-Type = 3
> >
> >Flowspec Object
> >     Class-of-Service  C-Type = 3
> >
> >HELLO Object
> >     HELLO Class =  22
> >     HELLO REQUEST   C_Type = 1
> >     HELLO ACK       C_Type = 2
> >
> >*Message Assignment
> >*Hello Message
> >    Msg Type 14  **Assigned Value 20
> >
> >Error Code Assignments
> >
> >"Routing Problem" error code = 24
> >"Notify" error code = 25
> >
> >The following defines error values for the Routing Problem Error Code:
> >       Value Error:
> >       1     Bad EXPLICIT_ROUTE object
> >       2     Bad strict node
> >       3     Bad loose node
> >       4     Bad initial subobject
> >       5     No route available toward destination
> >       6     RRO syntax error detected
> >       7     RRO indicated routing loops
> >       8     MPLS being negotiated, but a non-RSVP-capable router
> >             stands in the path
> >       9     MPLS label allocation failure
> >       10    Unsupported L3PID
> >
> >For the Notify Error Code, the 16 bits of the Error Value field are:
> >       ss00 cccc cccc cccc
> >The high order bits are as defined under Error Code 1. RFC2205
> >When ss = 00, the following subcode is defined:
> >        1    RRO too large for MTU
> >        2    RRO notification

Is there any DIFFSERV (draft-ietf-mpls-diff_ext) object definition?

Regards!
Yuan Gu




From owner-mpls@UU.NET  Tue Aug  8 22:26:54 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25326
	for <mpls-archive@lists.ietf.org>; Tue, 8 Aug 2000 22:26:54 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbkz02215;
	Wed, 9 Aug 2000 02:26:41 GMT
Received: by mail-control.mail.uu.net 
	id QQjbkz12559
	for mpls-outgoing; Wed, 9 Aug 2000 02:26:13 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjbkz12487
	for <mpls@mail-control.mail.uu.net>; Wed, 9 Aug 2000 02:26:02 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbkz01974
	for <mpls@uu.net>; Tue, 8 Aug 2000 22:20:07 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjbkz01780
	for <mpls@uu.net>; Wed, 9 Aug 2000 02:19:36 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id WAA03184
	for mpls@uu.net; Tue, 8 Aug 2000 22:19:36 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjbkz11748
	for <mpls@mail-control.mail.uu.net>; Wed, 9 Aug 2000 02:19:07 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjbkz08463
	for <mpls@UU.NET>; Tue, 8 Aug 2000 22:17:20 -0400 (EDT)
Received: from mailgate.sbell.com.cn by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.sbell.com.cn [202.96.203.173])
	id QQjbkz26788
	for <mpls@UU.NET>; Wed, 9 Aug 2000 02:17:18 GMT
Received: from sdc.sbell.com.cn (sdc.sbell.com.cn [138.203.222.11])
	by mailgate.sbell.com.cn (8.9.2/8.9.2) with ESMTP id JAA16424;
	Wed, 9 Aug 2000 09:50:48 +0800 (CST)
Received: from bbx015.sbell.com.cn (bbx015 [138.203.222.185])
	by sdc.sbell.com.cn (8.9.1/8.9.1) with ESMTP id JAA06713;
	Wed, 9 Aug 2000 09:57:06 +0800 (CST)
Received: from sh.bel.alcatel.be (localhost [127.0.0.1])
	by bbx015.sbell.com.cn (8.9.1/8.9.1) with ESMTP id SAA16235;
	Tue, 8 Aug 2000 18:52:52 -0700 (PDT)
Message-ID: <3990B973.D1765B2D@sh.bel.alcatel.be>
Date: Wed, 09 Aug 2000 09:52:52 +0800
From: Gu Yuan <guy@sh.bel.alcatel.be>
X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Lou Berger <lberger@labn.net>
CC: mpls@UU.NET, swallow@cisco.com
Subject: Re: Fwd: RSVP-LSP-TUNNEL
References: <4.3.2.7.2.20000807182340.00d33ef0@mail.labn.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Lou Berger wrote:

> FYI -
>
> >Reply-To: <iana@iana.org>
> >From: "IANA" <iana@ISI.EDU>
> >To: <swallow@cisco.com>, <lberger@labn.net>
> >Cc: <braden@ISI.EDU>
> >Subject: RSVP-LSP-TUNNEL
> >Date: Mon, 7 Aug 2000 15:02:32 -0700
> >X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
> >Importance: Normal
> >
> >George and Lou,
> >
> >We have updated the RSVP-parameters file.  We apologize for long
> >delay in completing this.  This is to confirm that we have assigned
> >all the values requested to the RSVP protocol parameters file.  Please
> >check the following file for these assignments:
> >
> ><http://www.isi.edu/in-notes/iana/assignments/rsvp-parameters>
> >
> >Thank you,
> >
> >Michelle Schipper
> >IANA
> >
> >Requested Assignments below (**changes)
> >----------------------------------------------------------------------------
> >Object and C-Type Assignments:
> >
> >LABEL Object  (this is already assigned, but should change from Davie
> >                to the RFC number which gets assigned.)
> >    LABEL class = 16
> >
> >Label Request Object
> >    LABEL_REQUEST Class = 19
> >    Label Request without Label Range            C_Type = 1
> >    Label Request with ATM Label Range           C_Type = 2
> >    Label Request with Frame Relay Label Range   C_Type = 3
> >
> >Explicit Route Object
> >     EXPLICIT_ROUTE Class = 20
> >     Type 1 Explicit Route                       C_Type = 1
> >
> >   Subobjects of the Type 1 EXPLICIT_ROUTE object
> >     0   Reserved
> >     1   IPv4 prefix
> >     2   IPv6 prefix
> >    32   Autonomous system number
> >
> >Record Route Object
> >     ROUTE_RECORD Class = 21
> >     Type 1 Record Route                          C_Type = 1
> >
> >   Subobjects of the Type 1 RECORD_ROUTE object
> >     0   Reserved
> >     1   IPv4 address
> >     2   IPv6 address
> >
> >Session Object
> >    LSP_TUNNEL_IPv4   C-Type = 7
> >    LSP_TUNNEL_IPv6   C-Type = 8
> >
> >Sender Template Object
> >    LSP_TUNNEL_IPv4   C-Type = 7
> >    LSP_TUNNEL_IPv6   C-Type = 8
> >
> >Filter Specification Object
> >    LSP_TUNNEL_IPv4   C-Type = 7
> >    LSP_TUNNEL_IPv6   C-Type = 8
> >
> >SESSION_ATTRIBUTE object
> >    Session Attribute Class = 207
> >    LSP_TUNNEL       C-Type = 7
> >
> >Sender Tspec Object
> >     Class-of-Service  C-Type = 3
> >
> >Flowspec Object
> >     Class-of-Service  C-Type = 3
> >
> >HELLO Object
> >     HELLO Class =  22
> >     HELLO REQUEST   C_Type = 1
> >     HELLO ACK       C_Type = 2
> >
> >*Message Assignment
> >*Hello Message
> >    Msg Type 14  **Assigned Value 20
> >
> >Error Code Assignments
> >
> >"Routing Problem" error code = 24
> >"Notify" error code = 25
> >
> >The following defines error values for the Routing Problem Error Code:
> >       Value Error:
> >       1     Bad EXPLICIT_ROUTE object
> >       2     Bad strict node
> >       3     Bad loose node
> >       4     Bad initial subobject
> >       5     No route available toward destination
> >       6     RRO syntax error detected
> >       7     RRO indicated routing loops
> >       8     MPLS being negotiated, but a non-RSVP-capable router
> >             stands in the path
> >       9     MPLS label allocation failure
> >       10    Unsupported L3PID
> >
> >For the Notify Error Code, the 16 bits of the Error Value field are:
> >       ss00 cccc cccc cccc
> >The high order bits are as defined under Error Code 1. RFC2205
> >When ss = 00, the following subcode is defined:
> >        1    RRO too large for MTU
> >        2    RRO notification

Is there any DIFFSERV (draft-ietf-mpls-diff_ext) object definition?

Regards!
Yuan Gu




From owner-mpls@UU.NET  Wed Aug  9 10:37:48 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04116
	for <mpls-archive@lists.ietf.org>; Wed, 9 Aug 2000 10:37:48 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbmw10921;
	Wed, 9 Aug 2000 14:37:30 GMT
Received: by mail-control.mail.uu.net 
	id QQjbmw18863
	for mpls-outgoing; Wed, 9 Aug 2000 14:34:52 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjbmw18835
	for <mpls@mail-control.mail.uu.net>; Wed, 9 Aug 2000 14:34:31 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbmw27327
	for <mpls@UU.NET>; Wed, 9 Aug 2000 10:32:59 -0400 (EDT)
Received: from mailhost.avici.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.246.215.9])
	id QQjbmw03605
	for <mpls@UU.NET>; Wed, 9 Aug 2000 14:32:59 GMT
Received: from avici.com (swdev23.avici.com [10.1.2.229])
          by mailhost.avici.com (8.8.5/8.8.4) with ESMTP
	  id KAA13322; Wed, 9 Aug 2000 10:32:55 -0400 (EDT)
Message-Id: <200008091432.KAA13322@mailhost.avici.com>
X-Mailer: exmh version 2.1.1 10/15/1999
From: Markus Jork <mjork@avici.com>
To: Lou Berger <lberger@labn.net>
cc: mpls@UU.NET, swallow@cisco.com
Subject: Re: Fwd: RSVP-LSP-TUNNEL 
In-reply-to: Your message of "Mon, 07 Aug 2000 18:24:39 EDT."
             <4.3.2.7.2.20000807182340.00d33ef0@mail.labn.net> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 09 Aug 2000 10:32:54 -0400
Sender: owner-mpls@UU.NET
Precedence: bulk

Lou,

the IANA assignments seem to be based on draft-ietf-mpls-rsvp-lsp-tunnel-05:

> >The following defines error values for the Routing Problem Error
> Code:
>       Value Error:
>       1     Bad EXPLICIT_ROUTE object
>       2     Bad strict node
>       3     Bad loose node
>       4     Bad initial subobject
>       5     No route available toward destination
>       6     RRO syntax error detected
>       7     RRO indicated routing loops
>       8     MPLS being negotiated, but a non-RSVP-capable router
>             stands in the path
>       9     MPLS label allocation failure
>       10    Unsupported L3PID 

But draft-ietf-mpls-rsvp-lsp-tunnel-06 redefines error value 6:

>       6     Unacceptable label value

How will this be resolved?

Markus




From owner-mpls@UU.NET  Wed Aug  9 11:10:51 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08178
	for <mpls-archive@lists.ietf.org>; Wed, 9 Aug 2000 11:10:51 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbmy13201;
	Wed, 9 Aug 2000 15:10:16 GMT
Received: by mail-control.mail.uu.net 
	id QQjbmy02844
	for mpls-outgoing; Wed, 9 Aug 2000 15:07:53 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjbmy02835
	for <mpls@mail-control.mail.uu.net>; Wed, 9 Aug 2000 15:07:48 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjbmw23379
	for <mpls@UU.NET>; Wed, 9 Aug 2000 10:44:02 -0400 (EDT)
Received: from griffin.host4u.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: griffin.host4u.net [209.150.128.163])
	id QQjbmw15803
	for <mpls@UU.NET>; Wed, 9 Aug 2000 14:44:02 GMT
Received: from toy.labn.net (jgateadsl.cais.net [205.252.5.196])
	by griffin.host4u.net (8.8.5/8.8.5) with ESMTP id JAA27223;
	Wed, 9 Aug 2000 09:43:55 -0500
Message-Id: <4.3.2.7.2.20000809104306.00c23c20@mail.labn.net>
X-Sender: lberger@mail.labn.net
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 09 Aug 2000 10:43:57 -0400
To: Markus Jork <mjork@avici.com>
From: Lou Berger <lberger@labn.net>
Subject: Re: Fwd: RSVP-LSP-TUNNEL 
Cc: Lou Berger <lberger@labn.net>, mpls@UU.NET, swallow@cisco.com
In-Reply-To: <200008091432.KAA13322@mailhost.avici.com>
References: <Your message of "Mon, 07 Aug 2000 18:24:39 EDT." <4.3.2.7.2.20000807182340.00d33ef0@mail.labn.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

Good catch.  I'll ask IANA to fix the description.

Thanks,
Lou

At 10:32 AM 8/9/00 -0400, Markus Jork wrote:
>Lou,
>
>the IANA assignments seem to be based on draft-ietf-mpls-rsvp-lsp-tunnel-05:
>
> > >The following defines error values for the Routing Problem Error
> > Code:
> >       Value Error:
> >       1     Bad EXPLICIT_ROUTE object
> >       2     Bad strict node
> >       3     Bad loose node
> >       4     Bad initial subobject
> >       5     No route available toward destination
> >       6     RRO syntax error detected
> >       7     RRO indicated routing loops
> >       8     MPLS being negotiated, but a non-RSVP-capable router
> >             stands in the path
> >       9     MPLS label allocation failure
> >       10    Unsupported L3PID
>
>But draft-ietf-mpls-rsvp-lsp-tunnel-06 redefines error value 6:
>
> >       6     Unacceptable label value
>
>How will this be resolved?
>
>Markus



From owner-mpls@UU.NET  Wed Aug  9 11:24:25 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08622
	for <mpls-archive@lists.ietf.org>; Wed, 9 Aug 2000 11:24:24 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbmz08680;
	Wed, 9 Aug 2000 15:23:44 GMT
Received: by mail-control.mail.uu.net 
	id QQjbmz04006
	for mpls-outgoing; Wed, 9 Aug 2000 15:23:19 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjbmz04000
	for <mpls@mail-control.mail.uu.net>; Wed, 9 Aug 2000 15:23:14 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbmy04351
	for <mpls@UU.NET>; Wed, 9 Aug 2000 11:04:40 -0400 (EDT)
Received: from griffin.host4u.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: griffin.host4u.net [209.150.128.163])
	id QQjbmy04065
	for <mpls@UU.NET>; Wed, 9 Aug 2000 15:04:39 GMT
Received: from toy.labn.net (jgateadsl.cais.net [205.252.5.196])
	by griffin.host4u.net (8.8.5/8.8.5) with ESMTP id KAA02051;
	Wed, 9 Aug 2000 10:04:31 -0500
Message-Id: <4.3.2.7.2.20000809110350.00bbc6b0@mail.labn.net>
X-Sender: lberger@mail.labn.net
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 09 Aug 2000 11:04:38 -0400
To: Markus Jork <mjork@avici.com>
From: Lou Berger <lberger@labn.net>
Subject: Re: Fwd: RSVP-LSP-TUNNEL 
Cc: Lou Berger <lberger@labn.net>, mpls@UU.NET, swallow@cisco.com
In-Reply-To: <200008091432.KAA13322@mailhost.avici.com>
References: <Your message of "Mon, 07 Aug 2000 18:24:39 EDT." <4.3.2.7.2.20000807182340.00d33ef0@mail.labn.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

It's been fixed.

See: http://www.isi.edu/in-notes/iana/assignments/rsvp-parameters

Thanks again for catching this.

Lou

At 10:32 AM 8/9/00 -0400, Markus Jork wrote:
>Lou,
>
>the IANA assignments seem to be based on draft-ietf-mpls-rsvp-lsp-tunnel-05:
>
> > >The following defines error values for the Routing Problem Error
> > Code:
> >       Value Error:
> >       1     Bad EXPLICIT_ROUTE object
> >       2     Bad strict node
> >       3     Bad loose node
> >       4     Bad initial subobject
> >       5     No route available toward destination
> >       6     RRO syntax error detected
> >       7     RRO indicated routing loops
> >       8     MPLS being negotiated, but a non-RSVP-capable router
> >             stands in the path
> >       9     MPLS label allocation failure
> >       10    Unsupported L3PID
>
>But draft-ietf-mpls-rsvp-lsp-tunnel-06 redefines error value 6:
>
> >       6     Unacceptable label value
>
>How will this be resolved?
>
>Markus



From owner-mpls@UU.NET  Wed Aug  9 13:06:32 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13888
	for <mpls-archive@lists.ietf.org>; Wed, 9 Aug 2000 13:06:32 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbng11003;
	Wed, 9 Aug 2000 17:05:58 GMT
Received: by mail-control.mail.uu.net 
	id QQjbng04272
	for mpls-outgoing; Wed, 9 Aug 2000 17:05:28 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjbng04167
	for <mpls@mail-control.mail.uu.net>; Wed, 9 Aug 2000 17:05:21 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbng27662
	for <mpls@UU.NET>; Wed, 9 Aug 2000 13:05:04 -0400 (EDT)
Received: from mail.packetcom.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: larry.packetcom.com [208.48.7.75] (may be forged))
	id QQjbng21579
	for <mpls@UU.NET>; Wed, 9 Aug 2000 17:04:48 GMT
Received: by MAIL with Internet Mail Service (5.5.2650.21)
	id <QPYTZXKP>; Wed, 9 Aug 2000 10:08:07 -0700
Message-ID: <2FF612B13481D311B40A009027B0C83886AB4A@MAIL>
From: Riad Hartani <riad@caspiannetworks.com>
To: mpls@UU.NET
Subject: RE: I-D ACTION:draft-worster-mpls-in-ip-02.txt
Date: Wed, 9 Aug 2000 10:08:07 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

A couple of questions regarding the MPLS-in-IP draft below:

1) IP-in-IP encapsulation clearly describes how to set/handle the outer IP
header fields, such as TOS, Id/Flag/Fragment fields, TTL and others. In this
type of encapsulation, setting these fields is directly related to how they
are set within the inner IP header (eg: TOS is simply copied from inner IP
header). 

What are the procedures if the encapsulated packet is now an MPLS packet
rather than an IP packet ? Clear procedures (even if they are trivial) would
make the draft more clear (specially if the MPLS packet/label is QoS aware).

2) In section 4, I suspect that security consideration inherent to IP
encapsulation schemes will also apply in this case. So, additional
precautions are needed when compared to the LSR/LER case.

3) Reading the abstract, one may think that extending a Voice_over_IP over
MPLS tunnel to a non MPLS-core by adding an IP encapsulation is one of the
motivations for this work. Well, I fail to see why. The amount of overhead
given the small voice packet size would be too large using these successive
encapsulation schemes. Is this really one of the motivations ?

Thanks,

Riad



-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
Sent: Wednesday, August 09, 2000 7:28 AM
Subject: I-D ACTION:draft-worster-mpls-in-ip-02.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories.


	Title		: MPLS Label Stack Encapsulation in IP
	Author(s)	: T. Worster, Y. Katsube, A. Malis, R. Wilder
	Filename	: draft-worster-mpls-in-ip-02.txt
	Pages		: 6
	Date		: 08-Aug-00
	
Several useful applications of MPLS tunnels based on LSPs with
second level labels between non adjacent LSRs have been
identified: IP-VPNs and VoIP over MPLS are just two examples. This
tunnelling technique can easily be extended to non-MPLS core
networks.
This Internet-Draft explains the motivation for encapsulating MPLS
messages in IP and provides the protocol specification of the
encapsulation.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-worster-mpls-in-ip-02.txt

 


From owner-mpls@UU.NET  Wed Aug  9 16:15:39 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18985
	for <mpls-archive@lists.ietf.org>; Wed, 9 Aug 2000 16:15:39 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbnq07291;
	Wed, 9 Aug 2000 19:31:28 GMT
Received: by mail-control.mail.uu.net 
	id QQjbnq10251
	for mpls-outgoing; Wed, 9 Aug 2000 19:30:48 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjbnq10234
	for <mpls@mail-control.mail.uu.net>; Wed, 9 Aug 2000 19:30:35 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbnq05631
	for <mpls@uu.net>; Wed, 9 Aug 2000 15:30:28 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjbnq06635
	for <mpls@uu.net>; Wed, 9 Aug 2000 19:30:27 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA05600
	for mpls@uu.net; Wed, 9 Aug 2000 15:30:27 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjbnp10145
	for <mpls@mail-control.mail.uu.net>; Wed, 9 Aug 2000 19:29:36 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbnp05375
	for <mpls@uu.net>; Wed, 9 Aug 2000 15:29:15 -0400 (EDT)
Received: from alpo.casc.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: alpo.casc.com [152.148.10.6])
	id QQjbnp05914
	for <mpls@uu.net>; Wed, 9 Aug 2000 19:29:00 GMT
Received: from lucent.com (snowman [152.148.10.28])
	by alpo.casc.com (8.9.1a/8.9.1) with ESMTP id PAA13060
	for <mpls@uu.net>; Wed, 9 Aug 2000 15:28:59 -0400 (EDT)
Message-ID: <3991B0FB.8C65F3E0@lucent.com>
Date: Wed, 09 Aug 2000 15:28:59 -0400
From: Sridhar Komandur <komandur@lucent.com>
Organization: IP Switching, Lucent Technologies, Westford, MA
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.5.1 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: status of drafts ...
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


Hi   George/Vijay,

Could you please post the status of various MPLS drafts  ?

thanks,
- Sridhar




From owner-mpls@UU.NET  Wed Aug  9 17:00:08 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20236
	for <mpls-archive@lists.ietf.org>; Wed, 9 Aug 2000 17:00:07 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbnv04659;
	Wed, 9 Aug 2000 20:59:50 GMT
Received: by mail-control.mail.uu.net 
	id QQjbnv01134
	for mpls-outgoing; Wed, 9 Aug 2000 20:59:30 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjbnv01073
	for <mpls@mail-control.mail.uu.net>; Wed, 9 Aug 2000 20:59:17 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjbnv22190
	for <mpls@uu.net>; Wed, 9 Aug 2000 16:59:04 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjbnv03604
	for <mpls@uu.net>; Wed, 9 Aug 2000 20:59:03 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA19339
	for mpls@uu.net; Wed, 9 Aug 2000 16:59:03 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjbnv00932
	for <mpls@mail-control.mail.uu.net>; Wed, 9 Aug 2000 20:58:34 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjbnv22056
	for <mpls@uu.net>; Wed, 9 Aug 2000 16:58:29 -0400 (EDT)
Received: from ihemail2.firewall.lucent.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ihemail2.lucent.com [192.11.222.163])
	id QQjbnv02719
	for <mpls@uu.net>; Wed, 9 Aug 2000 20:58:29 GMT
Received: from ihemail2.firewall.lucent.com (localhost [127.0.0.1])
	by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id QAA03159
	for <mpls@uu.net>; Wed, 9 Aug 2000 16:58:28 -0400 (EDT)
Received: from hotair.hobl.lucent.com (h199-118-135-2.lucent.com [199.118.135.2])
	by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id QAA03151
	for <mpls@uu.net>; Wed, 9 Aug 2000 16:58:28 -0400 (EDT)
Received: from hotair.hobl.lucent.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2)
	id QAA26717; Wed, 9 Aug 2000 16:58:23 -0400
Message-ID: <3991C648.749127BB@hotair.hobl.lucent.com>
Date: Wed, 09 Aug 2000 16:59:52 -0400
From: Ramesh Bhandari <bhandari1@lucent.com>
X-Mailer: Mozilla 4.73 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: (no subject)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

auth 70e272ac subscribe mpls bhandari1@lucent.com




From owner-mpls@UU.NET  Wed Aug  9 23:55:01 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27847
	for <mpls-archive@lists.ietf.org>; Wed, 9 Aug 2000 23:55:01 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbox04216;
	Thu, 10 Aug 2000 03:54:43 GMT
Received: by mail-control.mail.uu.net 
	id QQjbox18432
	for mpls-outgoing; Thu, 10 Aug 2000 03:54:18 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjbox18427
	for <mpls@mail-control.mail.uu.net>; Thu, 10 Aug 2000 03:54:13 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbox02596
	for <mpls@uu.net>; Wed, 9 Aug 2000 23:53:49 -0400 (EDT)
Received: from mail01.gmu.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail01.gmu.edu [129.174.0.6])
	id QQjbox03879
	for <mpls@uu.net>; Thu, 10 Aug 2000 03:53:48 GMT
Received: from lchang2 ([129.174.102.177]) by mail01.gmu.edu
          (Netscape Messaging Server 4.1) with ESMTP id FZ25HN00.SFB for
          <mpls@uu.net>; Wed, 9 Aug 2000 23:53:47 -0400 
Message-ID: <003501c0027f$fdcc4a20$970dae81@lchang2.gmu.edu>
From: "Lichung Chang" <lchang4@gmu.edu>
To: <mpls@UU.NET>
Subject: LDP Specification
Date: Thu, 10 Aug 2000 00:03:47 -0400
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 4.72.3612.1700
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi,

    In http://search.ietf.org/internet-drafts/draft-ietf-mpls-ldp-09.txt
section 3.5.1.2.2. Unknown or Malformed TLV  shows that:

> If the TLV type is >= 0x8000 (high order bit 1) the TLV is
> silently dropped.  Section "Unknown TLV in Known Message Type"
> elaborates on this behavior.

    Where can I find the section "Unknown TLV in Known Message Type"?
Thanks in advance for your clarification.


Lichung



From owner-mpls@UU.NET  Thu Aug 10 06:35:09 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13647
	for <mpls-archive@lists.ietf.org>; Thu, 10 Aug 2000 06:35:08 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbpy19229;
	Thu, 10 Aug 2000 10:34:42 GMT
Received: by mail-control.mail.uu.net 
	id QQjbpy28758
	for mpls-outgoing; Thu, 10 Aug 2000 10:34:19 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjbpy28753
	for <mpls@mail-control.mail.uu.net>; Thu, 10 Aug 2000 10:34:13 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjbpy02973
	for <mpls@uu.net>; Thu, 10 Aug 2000 06:34:04 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjbpy18761
	for <mpls@uu.net>; Thu, 10 Aug 2000 10:34:03 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA10771
	for mpls@uu.net; Thu, 10 Aug 2000 06:34:03 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjbpy28740
	for <mpls@mail-control.mail.uu.net>; Thu, 10 Aug 2000 10:33:32 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbpy12774
	for <mpls@UU.NET>; Thu, 10 Aug 2000 06:33:10 -0400 (EDT)
Received: from qhars002.nortel.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: qhars002.NortelNetworks.com [192.100.101.19])
	id QQjbpy01482
	for <mpls@UU.NET>; Thu, 10 Aug 2000 10:33:10 GMT
Received: from zhard00m.europe.nortel.com (actually zhard00m) 
          by qhars002.nortel.com; Thu, 10 Aug 2000 11:30:13 +0100
Received: by zhard00m.europe.nortel.com 
          with Internet Mail Service (5.5.2652.35) id <QPRH7Z51>;
          Thu, 10 Aug 2000 11:30:12 +0100
Message-ID: <973BB7458112D31197FC0000F808D55AB27D74@zmdrd000.europe.nortel.com>
From: "Eduardo Trobiani" <trobiani@nortelnetworks.com>
To: mpls@UU.NET
Subject: subscribe
Date: Thu, 10 Aug 2000 11:30:06 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C002B5.F344C380"
Sender: owner-mpls@UU.NET
Precedence: bulk

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_01C002B5.F344C380
Content-Type: text/plain;
	charset="iso-8859-1"

subscribe trobiani@nortelnetworks.com


------_=_NextPart_001_01C002B5.F344C380
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>subscribe</TITLE>
</HEAD>
<BODY>

<P ALIGN=LEFT><FONT COLOR="#000000" SIZE=2 FACE="Arial">subscribe trobiani@nortelnetworks.com</FONT></P>

</BODY>
</HTML>
------_=_NextPart_001_01C002B5.F344C380--



From owner-mpls@UU.NET  Thu Aug 10 06:59:27 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14527
	for <mpls-archive@lists.ietf.org>; Thu, 10 Aug 2000 06:59:27 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbpz04674;
	Thu, 10 Aug 2000 10:59:08 GMT
Received: by mail-control.mail.uu.net 
	id QQjbpz29909
	for mpls-outgoing; Thu, 10 Aug 2000 10:58:36 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjbpz29904
	for <mpls@mail-control.mail.uu.net>; Thu, 10 Aug 2000 10:58:34 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjbpz05448
	for <mpls@uu.net>; Thu, 10 Aug 2000 06:58:23 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjbpz04025
	for <mpls@uu.net>; Thu, 10 Aug 2000 10:58:23 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA12331
	for mpls@uu.net; Thu, 10 Aug 2000 06:58:22 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjbpz29890
	for <mpls@mail-control.mail.uu.net>; Thu, 10 Aug 2000 10:58:09 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjbpz05406
	for <mpls@UU.NET>; Thu, 10 Aug 2000 06:57:58 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88])
	id QQjbpz03628
	for <mpls@UU.NET>; Thu, 10 Aug 2000 10:57:43 GMT
Received: from rhthomas-sun2.cisco.com (rhthomas-sun2.cisco.com [161.44.134.47])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id DAA10172;
	Thu, 10 Aug 2000 03:58:00 -0700 (PDT)
Received: from localhost (rhthomas@localhost) by rhthomas-sun2.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id GAA20361; Thu, 10 Aug 2000 06:57:42 -0400 (EDT)
Message-Id: <200008101057.GAA20361@rhthomas-sun2.cisco.com>
X-Authentication-Warning: rhthomas-sun2.cisco.com: rhthomas owned process doing -bs
To: "Lichung Chang" <lchang4@gmu.edu>
cc: mpls@UU.NET
Subject: Re: LDP Specification 
In-reply-to: Your message of "Thu, 10 Aug 2000 00:03:47 EDT."
             <003501c0027f$fdcc4a20$970dae81@lchang2.gmu.edu> 
Date: Thu, 10 Aug 2000 06:57:41 -0400
From: Bob Thomas <rhthomas@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

Lichung,

>     In http://search.ietf.org/internet-drafts/draft-ietf-mpls-ldp-09.txt
> section 3.5.1.2.2. Unknown or Malformed TLV  shows that:
> 
> > If the TLV type is >= 0x8000 (high order bit 1) the TLV is
> > silently dropped.  Section "Unknown TLV in Known Message Type"
> > elaborates on this behavior.
> 
>     Where can I find the section "Unknown TLV in Known Message Type"?
> Thanks in advance for your clarification.

There is no such section.  This error goes back at least as far
as draft-ietf-mpls-ldp-02.txt.

The behavior in question is best described in Section 3.3
(Type-Length-Value Encoding).

Thanks for pointing this out.


Bob






From owner-mpls@UU.NET  Thu Aug 10 12:04:28 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01668
	for <mpls-archive@lists.ietf.org>; Thu, 10 Aug 2000 12:04:28 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbqu16987;
	Thu, 10 Aug 2000 16:04:00 GMT
Received: by mail-control.mail.uu.net 
	id QQjbqu29379
	for mpls-outgoing; Thu, 10 Aug 2000 16:03:40 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjbqu29368
	for <mpls@mail-control.mail.uu.net>; Thu, 10 Aug 2000 16:03:37 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjbqu01558
	for <mpls@uu.net>; Thu, 10 Aug 2000 12:03:18 -0400 (EDT)
Received: from mailrelay.laurelnetworks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: laurelnetworks.com [206.67.234.84])
	id QQjbqu27570
	for <mpls@uu.net>; Thu, 10 Aug 2000 16:03:18 GMT
Received: from localhost.laurelnetworks.com (IDENT:root@jleu-laptop.laurelnetworks.com [192.168.0.110])
	by mailrelay.laurelnetworks.com (8.9.3/8.9.3) with ESMTP id MAA23428
	for <mpls@uu.net>; Thu, 10 Aug 2000 12:03:17 -0400
Received: (from jleu@localhost)
	by localhost.laurelnetworks.com (8.9.3/8.9.3) id MAA05746
	for mpls@uu.net; Thu, 10 Aug 2000 12:03:17 -0400
Date: Thu, 10 Aug 2000 12:03:17 -0400
From: "James R. Leu" <jleu@laurelnetworks.com>
To: mpls@UU.NET
Subject: LDP-09 - Receive Label Mapping
Message-ID: <20000810120317.A4647@laurelnetworks.com>
Reply-To: jleu@laurelnetworks.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
Organization: Laurel Networks
Sender: owner-mpls@UU.NET
Precedence: bulk

Forgive me if this has already been discussed, just point me to the thread in
the archive.

I have a question about the loop from LMp.17 to LMp.31
Here is my interpretation of what should happen:

When processing a incoming label map message the LSR needs to figure out
what other peers this mapping needs to be propagated to.  While processing
the list of all peers:

-if the LSR has previously sent a mapping, and the attributes of the new
 mapping are different then the attributes of the old mapping then send an
 updated mapping (LMp.22-LMp.27).
-if a peer is operating in DU then the LSR should propagate the mapping
 (LMp.20,LMp.21)
-if a peer is operating in DOD AND the LSR has a record of an outstanding label
 request from that peer, propagate the mapping and delete the record of the
 outstanding request (LMp.29-DOD).

If this is a reasonable interpretation then what is LMp.29-DU for?
Didn't the LSR already do that work in LMp.20,LMp.21?

Jim
-- 
James R. Leu
Software Engineer
Laurel Networks, Inc
jleu@laurelnetworks.com


From owner-mpls@UU.NET  Thu Aug 10 13:51:34 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06671
	for <mpls-archive@lists.ietf.org>; Thu, 10 Aug 2000 13:51:33 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbrb24461;
	Thu, 10 Aug 2000 17:50:36 GMT
Received: by mail-control.mail.uu.net 
	id QQjbrb17804
	for mpls-outgoing; Thu, 10 Aug 2000 17:50:07 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjbrb17798
	for <mpls@mail-control.mail.uu.net>; Thu, 10 Aug 2000 17:50:04 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjbrb15543
	for <mpls@uu.net>; Thu, 10 Aug 2000 13:49:50 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjbrb23494
	for <mpls@uu.net>; Thu, 10 Aug 2000 17:49:34 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA29612
	for mpls@uu.net; Thu, 10 Aug 2000 13:49:34 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjbrb17771
	for <mpls@mail-control.mail.uu.net>; Thu, 10 Aug 2000 17:49:10 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbrb17823
	for <mpls@UU.NET>; Thu, 10 Aug 2000 13:47:10 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11])
	id QQjbrb05966
	for <mpls@UU.NET>; Thu, 10 Aug 2000 17:47:09 GMT
Received: from rhthomas-sun2.cisco.com (rhthomas-sun2.cisco.com [161.44.134.47])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id KAA23671;
	Thu, 10 Aug 2000 10:47:25 -0700 (PDT)
Received: from localhost (rhthomas@localhost) by rhthomas-sun2.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id NAA22855; Thu, 10 Aug 2000 13:47:08 -0400 (EDT)
Message-Id: <200008101747.NAA22855@rhthomas-sun2.cisco.com>
X-Authentication-Warning: rhthomas-sun2.cisco.com: rhthomas owned process doing -bs
To: jleu@laurelnetworks.com
cc: mpls@UU.NET
Subject: Re: LDP-09 - Receive Label Mapping 
In-reply-to: Your message of "Thu, 10 Aug 2000 12:03:17 EDT."
             <20000810120317.A4647@laurelnetworks.com> 
Date: Thu, 10 Aug 2000 13:47:07 -0400
From: Bob Thomas <rhthomas@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

Jim,

> Forgive me if this has already been discussed, just point me to the thread in
> the archive.
> 
> I have a question about the loop from LMp.17 to LMp.31
> Here is my interpretation of what should happen:
> 
> When processing a incoming label map message the LSR needs to figure out
> what other peers this mapping needs to be propagated to.  While processing
> the list of all peers:
> 
> -if the LSR has previously sent a mapping, and the attributes of the new
>  mapping are different then the attributes of the old mapping then send an
>  updated mapping (LMp.22-LMp.27).
> -if a peer is operating in DU then the LSR should propagate the mapping
>  (LMp.20,LMp.21)
> -if a peer is operating in DOD AND the LSR has a record of an outstanding label
>  request from that peer, propagate the mapping and delete the record of the
>  outstanding request (LMp.29-DOD).
> 
> If this is a reasonable interpretation then what is LMp.29-DU for?
> Didn't the LSR already do that work in LMp.20,LMp.21?

LMp.20+LMp.21 handles (only) the situation where a label mapping
has not previously been sent to the upstream peer AND the mode is
DU Ordered.

LMp.29-DU handles the situation where there are outstanding label
requests from the peer (which won't be the case if LMp.20+LMp,21
is executed since in the unlikely event that the peer had
requested a label in DU Ordered mode LMp.20+LMp.21 would have satisfied
the request).  In addition, LMp.29-DU handles the situation where
DU Independent is being used, which LMp.20+LMp.21 does not.

This procedure is complex because the number of combinations of modes
that must be handled (DU/DoD advertisment, liberal/conservative retention,
ordered/independent control).  There are no doubt ways to re-arrange
it to achieve the desired effect.


Bob





From owner-mpls@UU.NET  Thu Aug 10 15:03:06 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10840
	for <mpls-archive@lists.ietf.org>; Thu, 10 Aug 2000 15:03:06 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbrg21652;
	Thu, 10 Aug 2000 19:02:42 GMT
Received: by mail-control.mail.uu.net 
	id QQjbrg09343
	for mpls-outgoing; Thu, 10 Aug 2000 19:02:09 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjbrg09334
	for <mpls@mail-control.mail.uu.net>; Thu, 10 Aug 2000 19:01:53 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbrg05314
	for <mpls@UU.NET>; Thu, 10 Aug 2000 15:01:46 -0400 (EDT)
Received: from mailrelay.laurelnetworks.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: laurelnetworks.com [206.67.234.84])
	id QQjbrg20739
	for <mpls@UU.NET>; Thu, 10 Aug 2000 19:01:16 GMT
Received: from localhost.laurelnetworks.com (IDENT:root@jleu-laptop.laurelnetworks.com [192.168.0.110])
	by mailrelay.laurelnetworks.com (8.9.3/8.9.3) with ESMTP id PAA01690;
	Thu, 10 Aug 2000 15:01:15 -0400
Received: (from jleu@localhost)
	by localhost.laurelnetworks.com (8.9.3/8.9.3) id PAA08050;
	Thu, 10 Aug 2000 15:01:15 -0400
Date: Thu, 10 Aug 2000 15:01:14 -0400
From: "James R. Leu" <jleu@laurelnetworks.com>
To: Bob Thomas <rhthomas@cisco.com>
Cc: mpls@UU.NET
Subject: Re: LDP-09 - Receive Label Mapping
Message-ID: <20000810150114.B4647@laurelnetworks.com>
Reply-To: jleu@laurelnetworks.com
References: <20000810120317.A4647@laurelnetworks.com> <200008101747.NAA22855@rhthomas-sun2.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <200008101747.NAA22855@rhthomas-sun2.cisco.com>; from rhthomas@cisco.com on Thu, Aug 10, 2000 at 01:47:07PM -0400
Organization: Laurel Networks
Sender: owner-mpls@UU.NET
Precedence: bulk

Bob,

Thanks for the clarification.  I have one additional question.

On Thu, Aug 10, 2000 at 01:47:07PM -0400, Bob Thomas wrote:
<snip>
> LMp.29-DU handles the situation where there are outstanding label
> requests from the peer (which won't be the case if LMp.20+LMp,21

Shouldn't the record of these requests be deleted then in LMp.29-DU?
LMp.29-DoD has the line "4.  Delete record of pending request."

> This procedure is complex because the number of combinations of modes
> that must be handled (DU/DoD advertisement, liberal/conservative retention,
> ordered/independent control).  There are no doubt ways to re-arrange
> it to achieve the desired effect.

Jim
-- 
James R. Leu
Software Engineer
Laurel Networks, Inc
jleu@laurelnetworks.com


From owner-mpls@UU.NET  Thu Aug 10 15:36:19 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11949
	for <mpls-archive@lists.ietf.org>; Thu, 10 Aug 2000 15:36:19 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbri16193;
	Thu, 10 Aug 2000 19:34:43 GMT
Received: by mail-control.mail.uu.net 
	id QQjbri16613
	for mpls-outgoing; Thu, 10 Aug 2000 19:34:10 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjbri16601
	for <mpls@mail-control.mail.uu.net>; Thu, 10 Aug 2000 19:34:05 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbri15480
	for <mpls@uu.net>; Thu, 10 Aug 2000 15:32:52 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjbri16714
	for <mpls@uu.net>; Thu, 10 Aug 2000 19:32:36 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA15848
	for mpls@uu.net; Thu, 10 Aug 2000 15:32:36 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjbri16557
	for <mpls@mail-control.mail.uu.net>; Thu, 10 Aug 2000 19:32:00 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjbrh14428
	for <mpls@UU.NET>; Thu, 10 Aug 2000 15:29:40 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11])
	id QQjbrh10115
	for <mpls@UU.NET>; Thu, 10 Aug 2000 19:29:23 GMT
Received: from rhthomas-sun2.cisco.com (rhthomas-sun2.cisco.com [161.44.134.47])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id MAA24667;
	Thu, 10 Aug 2000 12:29:38 -0700 (PDT)
Received: from localhost (rhthomas@localhost) by rhthomas-sun2.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id PAA23618; Thu, 10 Aug 2000 15:29:22 -0400 (EDT)
Message-Id: <200008101929.PAA23618@rhthomas-sun2.cisco.com>
X-Authentication-Warning: rhthomas-sun2.cisco.com: rhthomas owned process doing -bs
To: jleu@laurelnetworks.com
cc: mpls@UU.NET
Subject: Re: LDP-09 - Receive Label Mapping 
In-reply-to: Your message of "Thu, 10 Aug 2000 15:01:14 EDT."
             <20000810150114.B4647@laurelnetworks.com> 
Date: Thu, 10 Aug 2000 15:29:14 -0400
From: Bob Thomas <rhthomas@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

Jim,

> Thanks for the clarification.  I have one additional question.
> 
> On Thu, Aug 10, 2000 at 01:47:07PM -0400, Bob Thomas wrote:
> <snip>
> > LMp.29-DU handles the situation where there are outstanding label
> > requests from the peer (which won't be the case if LMp.20+LMp,21
> 
> Shouldn't the record of these requests be deleted then in LMp.29-DU?
> LMp.29-DoD has the line "4.  Delete record of pending request."

Yes.

A difficulty in generating these procedures (in addition to trying to
get them right) was keeping them short enough so that they could be
read/understood yet detailed enough to cover the important actions.

Doing this involved numerous judgements as to what could be omitted.
In this case (and probably others), we were inconsistent.


Bob




> > This procedure is complex because the number of combinations of modes
> > that must be handled (DU/DoD advertisement, liberal/conservative retention,
> > ordered/independent control).  There are no doubt ways to re-arrange
> > it to achieve the desired effect.




From owner-mpls@UU.NET  Thu Aug 10 15:45:50 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12115
	for <mpls-archive@lists.ietf.org>; Thu, 10 Aug 2000 15:45:50 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbrj24259;
	Thu, 10 Aug 2000 19:45:15 GMT
Received: by mail-control.mail.uu.net 
	id QQjbri17080
	for mpls-outgoing; Thu, 10 Aug 2000 19:44:39 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjbri17072
	for <mpls@mail-control.mail.uu.net>; Thu, 10 Aug 2000 19:44:36 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbri17601
	for <mpls@uu.net>; Thu, 10 Aug 2000 15:44:04 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjbri23501
	for <mpls@uu.net>; Thu, 10 Aug 2000 19:44:03 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA17784
	for mpls@uu.net; Thu, 10 Aug 2000 15:44:03 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjbri17041
	for <mpls@mail-control.mail.uu.net>; Thu, 10 Aug 2000 19:43:50 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbri15470
	for <mpls@UU.NET>; Thu, 10 Aug 2000 15:43:31 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjbri23204
	for <mpls@UU.NET>; Thu, 10 Aug 2000 19:43:31 GMT
Received: from lir.cisco.com (lir-hme0.cisco.com [171.69.204.20])
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA17713;
	Thu, 10 Aug 2000 15:43:29 -0400 (EDT)
Received: from localhost (swallow@localhost) by lir.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id PAA22309; Thu, 10 Aug 2000 15:43:29 -0400 (EDT)
Message-Id: <200008101943.PAA22309@lir.cisco.com>
X-Authentication-Warning: lir.cisco.com: swallow owned process doing -bs
To: "Francis Reichmeyer (IPHighway MA)" <FranR@iphighway.com>
cc: mpls@UU.NET, swallow@cisco.com
Subject: Re: draft-ietf-mpls-rsvp-lsp-tunnel-06.txt 
In-reply-to: Your message of "Thu, 13 Jul 2000 22:12:39 EDT."
             <6399122981E1D211AB490090271E0AA38B1DD8@BMAILNJ> 
Date: Thu, 10 Aug 2000 15:43:29 -0400
From: George Swallow <swallow@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

Fran -

> > I added some discussion in section 2.2 on policy processing on Path
> > messages.  I didn't want to be too pendantic since this is a matter of
> > local policy and not part of the protocol.  If other folks think this
> > needs further explaining I can add some more.
> 
> What's there should be fine. You might want to explicitly call out the
> fact that it IS a matter of (local) policy. Especially since the 
> POLICY_DATA gets mentioned, and that object is opaque to the RSVP module
> on the LSR. 

In response to your comment I've reworded the first sentence the last
paragraph on page 10 (in section 2.2) to:

 Routers along the path may use the setup and hold priorities along
 with SENDER_TSPEC and any POLICY_DATA objects contained in Path
 messages as input to policy control.

And in section 2.5, the fourth paragraph to:

 A similar situation can arise when one wants to increase the bandwidth
 of a TE tunnel.  The new reservation will be for the full amount
 needed, but the actual allocation needed is only the delta between the
 new and old bandwidth.  If policy is being applied to PATH messages by
 intermediate nodes, then a PATH message requesting too much bandwidth
 will be rejected.  In this situation simply increasing the bandwidth
 request without changing the SENDER_TEMPLATE, could result in a tunnel
 being torn down, depending upon local policy. 

> Where the TSPEC, setup and hold priorities could actually be
> used by the LSR, the POLICY_DATA can really only be processed by a
> policy entity.

Of course the policy entity could be just another module in the LSR.

...George

==================================================================
George Swallow       Cisco Systems                   (978) 244-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824



From owner-mpls@UU.NET  Thu Aug 10 16:28:34 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13178
	for <mpls-archive@lists.ietf.org>; Thu, 10 Aug 2000 16:28:34 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbrl17020;
	Thu, 10 Aug 2000 20:28:10 GMT
Received: by mail-control.mail.uu.net 
	id QQjbrl01854
	for mpls-outgoing; Thu, 10 Aug 2000 20:27:40 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjbrl01849
	for <mpls@mail-control.mail.uu.net>; Thu, 10 Aug 2000 20:27:29 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbrl26120
	for <mpls@uu.net>; Thu, 10 Aug 2000 16:27:15 -0400 (EDT)
Received: from web5405.mail.yahoo.com by wodc7mr1.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: web5405.mail.yahoo.com [216.115.106.143])
	id QQjbrl16171
	for <mpls@uu.net>; Thu, 10 Aug 2000 20:27:00 GMT
Message-ID: <20000810202659.25661.qmail@web5405.mail.yahoo.com>
Received: from [132.177.119.129] by web5405.mail.yahoo.com; Thu, 10 Aug 2000 13:26:59 PDT
Date: Thu, 10 Aug 2000 13:26:59 -0700 (PDT)
From: John Sparr <johnrdb@yahoo.com>
Subject: resource affinity
To: mpls@UU.NET
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk


Hi, 

One question about resource affinity from RSVP-TE
06.txt.

In section 4.8.4, it says when a node is choosing
links in order to extend a loose node of an ERO, the
node "must" validate the resource classes of those
links against the resource affinities. 

But for the Session Attribute, there are two C-Types
defined. One is with resource affinity and one is
without resource affinity. Since there is two format
for SAO, why the draft says the node MUST validate the
resource classes? We maybe select the object without
resource affinity.


Thanks in advance
John

__________________________________________________
Do You Yahoo!?
Kick off your party with Yahoo! Invites.
http://invites.yahoo.com/


From owner-mpls@UU.NET  Thu Aug 10 16:52:32 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13682
	for <mpls-archive@lists.ietf.org>; Thu, 10 Aug 2000 16:52:32 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbrn25081;
	Thu, 10 Aug 2000 20:51:06 GMT
Received: by mail-control.mail.uu.net 
	id QQjbrn04995
	for mpls-outgoing; Thu, 10 Aug 2000 20:50:44 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjbrn04895
	for <mpls@mail-control.mail.uu.net>; Thu, 10 Aug 2000 20:50:42 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjbrn29304
	for <mpls@UU.NET>; Thu, 10 Aug 2000 16:50:35 -0400 (EDT)
Received: from icarian.ZAFFIRE.COM by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ATHM-64-232-xxx-132.home.net [64.232.69.132] (may be forged))
	id QQjbrn24384
	for <mpls@UU.NET>; Thu, 10 Aug 2000 20:50:30 GMT
Received: by ICARIAN with Internet Mail Service (5.5.2650.21)
	id <QHM3ZQKB>; Thu, 10 Aug 2000 13:58:12 -0700
Message-ID: <4D3F9F2BEC58D4118FCE009027B0A6621360D7@ICARIAN>
From: Eric Gray <EGray@zaffire.com>
To: "'Bob Thomas'" <rhthomas@cisco.com>, jleu@laurelnetworks.com
Cc: mpls@UU.NET
Subject: RE: LDP-09 - Receive Label Mapping 
Date: Thu, 10 Aug 2000 13:58:04 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Bob/Jim,

	I have to disagree with both of you.  Sorry.

	This needs a closer look.  When we had discussed
this in trying to cover the non-merge upstream peer case,
I had proposed the wording pretty much as it is.  Naturally,
I think it should stay that way.  :-)

	The reason for this is that step LMp.29(DU)-3 says 
to go to step LMp.30 if there are no further outstanding
Label Requests.  In that case, you have no need to delete
further Label Requests.

	If there are further Label Requests, you "fall thru"
to step LMp.29(DoD) and process any that apply.  This will
be necessary, for instance, when the local peer is merging,
the upstream peer is not and the local peer has waited for
a Label Mapping from downstream before sending Mappings to
its upstream peers for the LSP that it will merge.  If the
LSR procedure is followed in this way, the outstanding Label
Requests will be deleted as they are responded to.

	If you add a step LMp.29(DU)-4 to delete outstanding
Label Requests, you will have sent only one Label Mapping
for this peer - regardless of how many Labels were asked
for.

	For completeness, it would have made sense to delete 
the one Label Request that is being processed, except that 
you are in LMp.29(DU) - which (by default) means you may
not be processing an Label Requests.

	To clarify one potential point of confusion, in the
non-merge LSP case, it is quite possible to have multiple
outstanding Label Requests - even when operating in DU
mode.

> -----Original Message-----
> From: Bob Thomas [mailto:rhthomas@cisco.com]
> Sent: Thursday, August 10, 2000 12:29 PM
> To: jleu@laurelnetworks.com
> Cc: mpls@UU.NET
> Subject: Re: LDP-09 - Receive Label Mapping 
> 
> 
> Jim,
> 
> > Thanks for the clarification.  I have one additional question.
> > 
> > On Thu, Aug 10, 2000 at 01:47:07PM -0400, Bob Thomas wrote:
> > <snip>
> > > LMp.29-DU handles the situation where there are outstanding label
> > > requests from the peer (which won't be the case if LMp.20+LMp,21
> > 
> > Shouldn't the record of these requests be deleted then in LMp.29-DU?
> > LMp.29-DoD has the line "4.  Delete record of pending request."
> 
> Yes.
> 
> A difficulty in generating these procedures (in addition to trying to
> get them right) was keeping them short enough so that they could be
> read/understood yet detailed enough to cover the important actions.
> 
> Doing this involved numerous judgements as to what could be omitted.
> In this case (and probably others), we were inconsistent.
> 
> 
> Bob
> 
> 
> 
> 
> > > This procedure is complex because the number of 
> combinations of modes
> > > that must be handled (DU/DoD advertisement, 
> liberal/conservative retention,
> > > ordered/independent control).  There are no doubt ways to 
> re-arrange
> > > it to achieve the desired effect.
> 
> 


From owner-mpls@UU.NET  Thu Aug 10 17:07:51 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14002
	for <mpls-archive@lists.ietf.org>; Thu, 10 Aug 2000 17:07:50 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbro10514;
	Thu, 10 Aug 2000 21:07:26 GMT
Received: by mail-control.mail.uu.net 
	id QQjbro26743
	for mpls-outgoing; Thu, 10 Aug 2000 21:06:53 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjbro26737
	for <mpls@mail-control.mail.uu.net>; Thu, 10 Aug 2000 21:06:47 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjbro02585
	for <mpls@UU.NET>; Thu, 10 Aug 2000 17:06:32 -0400 (EDT)
Received: from icarian.ZAFFIRE.COM by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ATHM-64-232-xxx-132.home.net [64.232.69.132] (may be forged))
	id QQjbro09326
	for <mpls@UU.NET>; Thu, 10 Aug 2000 21:06:17 GMT
Received: by ICARIAN with Internet Mail Service (5.5.2650.21)
	id <QHM3ZQ75>; Thu, 10 Aug 2000 14:14:02 -0700
Message-ID: <4D3F9F2BEC58D4118FCE009027B0A6621360D8@ICARIAN>
From: Eric Gray <EGray@zaffire.com>
To: "'Bob Thomas'" <rhthomas@cisco.com>, jleu@laurelnetworks.com
Cc: mpls@UU.NET
Subject: RE: LDP-09 - Receive Label Mapping 
Date: Thu, 10 Aug 2000 14:13:59 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Bob/Jim,

	Actually, in re-reading this, the thing that 
first bothered me about Jim's comment came to the
front again.  In LMp.29(DU), you are _not_ handling
an outstanding Label Request.  When you fall thru 
to LMp.29(DoD), you would process all pending Label 
Requests that can be satisfied by merging onto the
Label Mapping that was received.

	In the DU mode, it is possible that this might
result in sending one more Label Mapping than was 
asked for.  But this is dealt with by the upstream
peer which will Release extraneous Label Mappings it
receives.  If the upstream peer is behaving itself
in supporting the DU, non-merge, case - this will not
occur.

	Hence it would no make sense to delete pending
Label Requests in step LMp.29(DU).  Which is intuitive
when you think about it. 

> -----Original Message-----
> From: Eric Gray [mailto:EGray@zaffire.com]
> Sent: Thursday, August 10, 2000 1:58 PM
> To: 'Bob Thomas'; jleu@laurelnetworks.com
> Cc: mpls@UU.NET
> Subject: RE: LDP-09 - Receive Label Mapping 
> 
> 
> Bob/Jim,
> 
> 	I have to disagree with both of you.  Sorry.
> 
> 	This needs a closer look.  When we had discussed
> this in trying to cover the non-merge upstream peer case,
> I had proposed the wording pretty much as it is.  Naturally,
> I think it should stay that way.  :-)
> 
> 	The reason for this is that step LMp.29(DU)-3 says 
> to go to step LMp.30 if there are no further outstanding
> Label Requests.  In that case, you have no need to delete
> further Label Requests.
> 
> 	If there are further Label Requests, you "fall thru"
> to step LMp.29(DoD) and process any that apply.  This will
> be necessary, for instance, when the local peer is merging,
> the upstream peer is not and the local peer has waited for
> a Label Mapping from downstream before sending Mappings to
> its upstream peers for the LSP that it will merge.  If the
> LSR procedure is followed in this way, the outstanding Label
> Requests will be deleted as they are responded to.
> 
> 	If you add a step LMp.29(DU)-4 to delete outstanding
> Label Requests, you will have sent only one Label Mapping
> for this peer - regardless of how many Labels were asked
> for.
> 
> 	For completeness, it would have made sense to delete 
> the one Label Request that is being processed, except that 
> you are in LMp.29(DU) - which (by default) means you may
> not be processing an Label Requests.
> 
> 	To clarify one potential point of confusion, in the
> non-merge LSP case, it is quite possible to have multiple
> outstanding Label Requests - even when operating in DU
> mode.
> 
> > -----Original Message-----
> > From: Bob Thomas [mailto:rhthomas@cisco.com]
> > Sent: Thursday, August 10, 2000 12:29 PM
> > To: jleu@laurelnetworks.com
> > Cc: mpls@UU.NET
> > Subject: Re: LDP-09 - Receive Label Mapping 
> > 
> > 
> > Jim,
> > 
> > > Thanks for the clarification.  I have one additional question.
> > > 
> > > On Thu, Aug 10, 2000 at 01:47:07PM -0400, Bob Thomas wrote:
> > > <snip>
> > > > LMp.29-DU handles the situation where there are 
> outstanding label
> > > > requests from the peer (which won't be the case if LMp.20+LMp,21
> > > 
> > > Shouldn't the record of these requests be deleted then in 
> LMp.29-DU?
> > > LMp.29-DoD has the line "4.  Delete record of pending request."
> > 
> > Yes.
> > 
> > A difficulty in generating these procedures (in addition to 
> trying to
> > get them right) was keeping them short enough so that they could be
> > read/understood yet detailed enough to cover the important actions.
> > 
> > Doing this involved numerous judgements as to what could be omitted.
> > In this case (and probably others), we were inconsistent.
> > 
> > 
> > Bob
> > 
> > 
> > 
> > 
> > > > This procedure is complex because the number of 
> > combinations of modes
> > > > that must be handled (DU/DoD advertisement, 
> > liberal/conservative retention,
> > > > ordered/independent control).  There are no doubt ways to 
> > re-arrange
> > > > it to achieve the desired effect.
> > 
> > 
> 


From owner-mpls@UU.NET  Thu Aug 10 21:48:42 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19345
	for <mpls-archive@lists.ietf.org>; Thu, 10 Aug 2000 21:48:42 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbsh10633;
	Fri, 11 Aug 2000 01:48:24 GMT
Received: by mail-control.mail.uu.net 
	id QQjbsh09700
	for mpls-outgoing; Fri, 11 Aug 2000 01:47:54 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjbsh09693
	for <mpls@mail-control.mail.uu.net>; Fri, 11 Aug 2000 01:47:43 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbsh14688
	for <mpls@uu.net>; Thu, 10 Aug 2000 21:47:34 -0400 (EDT)
Received: from web2006.mail.yahoo.com by wodc7mr1.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: web2006.mail.yahoo.com [128.11.68.206])
	id QQjbsh10146
	for <mpls@uu.net>; Fri, 11 Aug 2000 01:47:18 GMT
Received: (qmail 21651 invoked by uid 60001); 11 Aug 2000 01:47:18 -0000
Message-ID: <20000811014718.21650.qmail@web2006.mail.yahoo.com>
Received: from [216.7.143.226] by web2006.mail.yahoo.com; Thu, 10 Aug 2000 18:47:18 PDT
Date: Thu, 10 Aug 2000 18:47:18 -0700 (PDT)
From: Man Trinh <mtrinh1@yahoo.com>
Subject: MPLS label authentication
To: mpls@UU.NET
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

I am kind of new to the MPLS protocol.  If I ask a
question that is already discussed, please point me
to the thread in the archive.

My question is how do I know that the label that I
am getting is the correct label.  What if it is 
corrupted when I receive it?

Thanks,
-Man


__________________________________________________
Do You Yahoo!?
Kick off your party with Yahoo! Invites.
http://invites.yahoo.com/


From owner-mpls@UU.NET  Thu Aug 10 21:56:39 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19466
	for <mpls-archive@lists.ietf.org>; Thu, 10 Aug 2000 21:56:39 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbsh26759;
	Fri, 11 Aug 2000 01:56:24 GMT
Received: by mail-control.mail.uu.net 
	id QQjbsh10013
	for mpls-outgoing; Fri, 11 Aug 2000 01:55:53 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjbsh10006
	for <mpls@mail-control.mail.uu.net>; Fri, 11 Aug 2000 01:55:42 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbsh15713
	for <mpls@UU.NET>; Thu, 10 Aug 2000 21:55:39 -0400 (EDT)
Received: from force10networks.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtp.force10networks.com [206.54.51.114])
	id QQjbsh13606
	for <mpls@UU.NET>; Fri, 11 Aug 2000 01:55:38 GMT
Received: by tonga.ncorenetworks.com with Internet Mail Service (5.5.2650.21)
	id <QVA2NG1Z>; Thu, 10 Aug 2000 18:55:37 -0700
Message-ID: <fa20a09fb4cbdac50893623d7c71e94839935d6f@force10networks.com>
From: Nageswara Soma <nsoma@force10networks.com>
To: "'Man Trinh'" <mtrinh1@yahoo.com>
Cc: mpls@UU.NET
Subject: RE: MPLS label authentication
Date: Thu, 10 Aug 2000 18:55:36 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

LDP uses reliable TCP for label exchange.

> -----Original Message-----
> From: Man Trinh [mailto:mtrinh1@yahoo.com]
> Sent: Thursday, August 10, 2000 6:47 PM
> To: mpls@UU.NET
> Subject: MPLS label authentication
> 
> 
> Hi,
> 
> I am kind of new to the MPLS protocol.  If I ask a
> question that is already discussed, please point me
> to the thread in the archive.
> 
> My question is how do I know that the label that I
> am getting is the correct label.  What if it is 
> corrupted when I receive it?
> 
> Thanks,
> -Man
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Kick off your party with Yahoo! Invites.
> http://invites.yahoo.com/
> 


From owner-mpls@UU.NET  Thu Aug 10 23:26:23 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21788
	for <mpls-archive@lists.ietf.org>; Thu, 10 Aug 2000 23:26:23 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbsn06708;
	Fri, 11 Aug 2000 03:26:05 GMT
Received: by mail-control.mail.uu.net 
	id QQjbsn07972
	for mpls-outgoing; Fri, 11 Aug 2000 03:25:49 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjbsn07964
	for <mpls@mail-control.mail.uu.net>; Fri, 11 Aug 2000 03:25:35 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjbsn28309
	for <mpls@uu.net>; Thu, 10 Aug 2000 23:25:28 -0400 (EDT)
Received: from web2004.mail.yahoo.com by wodc7mr2.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: web2004.mail.yahoo.com [128.11.68.204])
	id QQjbsn05936
	for <mpls@uu.net>; Fri, 11 Aug 2000 03:25:12 GMT
Received: (qmail 21025 invoked by uid 60001); 11 Aug 2000 03:25:12 -0000
Message-ID: <20000811032512.21024.qmail@web2004.mail.yahoo.com>
Received: from [216.7.143.226] by web2004.mail.yahoo.com; Thu, 10 Aug 2000 20:25:12 PDT
Date: Thu, 10 Aug 2000 20:25:12 -0700 (PDT)
From: Man Trinh <mtrinh1@yahoo.com>
Subject: RE: MPLS label authentication
To: Nageswara Soma <nsoma@force10networks.com>
Cc: mpls@UU.NET
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

I am talking about the label I am getting when I
do label exchange.  I am talking about the shim
label in the data packet.  For example, the IP
Header has the checksum for protection against
corrupted header.  Is there anything I can do to
protect against a corrupted MPLS label.

-Man


--- Nageswara Soma <nsoma@force10networks.com> wrote:
> LDP uses reliable TCP for label exchange.
> 
> > -----Original Message-----
> > From: Man Trinh [mailto:mtrinh1@yahoo.com]
> > Sent: Thursday, August 10, 2000 6:47 PM
> > To: mpls@UU.NET
> > Subject: MPLS label authentication
> > 
> > 
> > Hi,
> > 
> > I am kind of new to the MPLS protocol.  If I ask a
> > question that is already discussed, please point
> me
> > to the thread in the archive.
> > 
> > My question is how do I know that the label that I
> > am getting is the correct label.  What if it is 
> > corrupted when I receive it?
> > 
> > Thanks,
> > -Man
> > 
> > 
> > __________________________________________________
> > Do You Yahoo!?
> > Kick off your party with Yahoo! Invites.
> > http://invites.yahoo.com/
> > 


__________________________________________________
Do You Yahoo!?
Kick off your party with Yahoo! Invites.
http://invites.yahoo.com/


From owner-mpls@UU.NET  Thu Aug 10 23:29:50 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21840
	for <mpls-archive@lists.ietf.org>; Thu, 10 Aug 2000 23:29:50 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbsn09824;
	Fri, 11 Aug 2000 03:29:40 GMT
Received: by mail-control.mail.uu.net 
	id QQjbsn08247
	for mpls-outgoing; Fri, 11 Aug 2000 03:29:23 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjbsn08241
	for <mpls@mail-control.mail.uu.net>; Fri, 11 Aug 2000 03:29:10 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbsn28797
	for <mpls@UU.NET>; Thu, 10 Aug 2000 23:29:01 -0400 (EDT)
Received: from icarian.ZAFFIRE.COM by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ATHM-64-232-xxx-132.home.net [64.232.69.132] (may be forged))
	id QQjbsn17179
	for <mpls@UU.NET>; Fri, 11 Aug 2000 03:28:46 GMT
Received: by ICARIAN with Internet Mail Service (5.5.2650.21)
	id <QHM3ZS7P>; Thu, 10 Aug 2000 20:36:32 -0700
Message-ID: <4D3F9F2BEC58D4118FCE009027B0A6621360E3@ICARIAN>
From: Eric Gray <EGray@zaffire.com>
To: "'Man Trinh'" <mtrinh1@yahoo.com>,
        Nageswara Soma
	 <nsoma@force10networks.com>
Cc: mpls@UU.NET
Subject: RE: MPLS label authentication
Date: Thu, 10 Aug 2000 20:36:22 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Man,

	The MPLS Shim header is part of the L2 frame's data.

> -----Original Message-----
> From: Man Trinh [mailto:mtrinh1@yahoo.com]
> Sent: Thursday, August 10, 2000 8:25 PM
> To: Nageswara Soma
> Cc: mpls@UU.NET
> Subject: RE: MPLS label authentication
> 
> 
> Hi,
> 
> I am talking about the label I am getting when I
> do label exchange.  I am talking about the shim
> label in the data packet.  For example, the IP
> Header has the checksum for protection against
> corrupted header.  Is there anything I can do to
> protect against a corrupted MPLS label.
> 
> -Man
> 
> 
> --- Nageswara Soma <nsoma@force10networks.com> wrote:
> > LDP uses reliable TCP for label exchange.
> > 
> > > -----Original Message-----
> > > From: Man Trinh [mailto:mtrinh1@yahoo.com]
> > > Sent: Thursday, August 10, 2000 6:47 PM
> > > To: mpls@UU.NET
> > > Subject: MPLS label authentication
> > > 
> > > 
> > > Hi,
> > > 
> > > I am kind of new to the MPLS protocol.  If I ask a
> > > question that is already discussed, please point
> > me
> > > to the thread in the archive.
> > > 
> > > My question is how do I know that the label that I
> > > am getting is the correct label.  What if it is 
> > > corrupted when I receive it?
> > > 
> > > Thanks,
> > > -Man
> > > 
> > > 
> > > __________________________________________________
> > > Do You Yahoo!?
> > > Kick off your party with Yahoo! Invites.
> > > http://invites.yahoo.com/
> > > 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Kick off your party with Yahoo! Invites.
> http://invites.yahoo.com/
> 


From owner-mpls@UU.NET  Fri Aug 11 06:42:15 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08449
	for <mpls-archive@lists.ietf.org>; Fri, 11 Aug 2000 06:42:14 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbtq01902;
	Fri, 11 Aug 2000 10:41:38 GMT
Received: by mail-control.mail.uu.net 
	id QQjbtq21266
	for mpls-outgoing; Fri, 11 Aug 2000 10:41:16 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjbtq21218
	for <mpls@mail-control.mail.uu.net>; Fri, 11 Aug 2000 10:41:03 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjbtq27071
	for <mpls@UU.NET>; Fri, 11 Aug 2000 06:40:47 -0400 (EDT)
Received: from diamant.int-evry.fr by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: diamant.int-evry.fr [157.159.10.12])
	id QQjbtq00656
	for <mpls@UU.NET>; Fri, 11 Aug 2000 10:40:46 GMT
Received: from mci.int-evry.fr (molure.int-evry.fr [157.159.15.11])
	by diamant.int-evry.fr (Postfix) with ESMTP id 6AC3317A53
	for <mpls@UU.NET>; Fri, 11 Aug 2000 12:38:47 +0200 (MET DST)
Received: from int-evry.fr (anaconda.int-evry.fr [157.159.15.5])
	by mci.int-evry.fr (Postfix) with ESMTP id 583D41D363
	for <mpls@UU.NET>; Fri, 11 Aug 2000 12:39:38 +0200 (MET DST)
From: Carl CREANGE <Carl.Creange@int-evry.fr>
MIME-Version: 1.0
To: mpls@UU.NET
X-Originating-IP: [140.94.76.190]
User-Agent: IMHO/0.97.1 (Webmail for Roxen)
Date: Fri, 11 Aug 2000 11:16:54 +0100
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Subject: French eng. student having questions
Message-Id: <20000811103938.583D41D363@mci.int-evry.fr>
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit

Hi !                                                                            
                                                                                
As a French Engineering student leading my end-of-studies project on MPLS, I    
have read several relevant internet draft, RFCs and some white papers.          
Consequently, I need some explanatory statements to understand MPLS concepts as 
well as possible. If you have some time to answer few questions, I will be very 
grateful to you.                                                                
I am aware that some of theses questions may appear naive to you, however any   
help is very welcome.                                                           
                                                                                
1/ referring to draft-ietf-mpls-arch06.txt.                                     
I have understood the label stacking (3.9) and tunnels (3.27) concepts, but     
maybe you could give me an example of application and illustrate "Sometimes a   
router Ru takes explicit action to cause a particular packet to be delivered to 
another router Rd, even though Ru and Rd are not consecutive routers on the     
Hop-by-hop path for that packet" (3.27)                                         
                                                                                
2/ referring to draft-ietf-mpls-diff-ext05.txt and also to Avici Systems White  
paper : "Traffic Engineering with MPLS" published on 03/16/00                   
Label inferred LSP (L-LSP) can be potentially excessively resource consuming    
since each LSR needs a mapping of each of the 64 possible DCSP values with a    
label.                                                                          
Even Avici WP says: "This method requires than an association of specific       
DiffServ codepoints to LSPs be pre-established prior to traffic flow" :         
Does it mean that, for each ELSR pair (say ELSR A and B ), 64 different LSPs are
pre-established, and consequently at least 64 labels are reserved on each LSR on
the path between A and B?                                                       
                                                                                
3/ I would like to know where to find MPLS CoS definitions.                     
                                                                                
4/ Concerning the Forward Equivalent Class (FEC) concept, that I do not feel    
tangible.                                                                       
Is it right to say that a FEC is mapped on an LSP at an ingress LSR?            
Has a FEC a local or global significance?                                       
                                                                                
Two "more open" questions:                                                      
                                                                                
5/ Despite draft-ietf-mpls-diff-ext05.txt, I have some difficulties to see the  
developments achieved to tackle "QoS management through adjacent networks"      
What could you say about the two following scenari (and others we can easily    
imagine)?                                                                       
                                                                                
 	A/                                                                            
                                                                                
   ------------------        -----------------         ------------------       
  |                   |	|                 |       |                   |         
  |  non MPLS  |	|   MPLS     |       |   non MPLS |                            
  |  network      |-----|   Network  |-------|   network      |                 
  |  Inserv         |	|   DiffServ   |       |   Inteserv      |                
  |                   |	|                 |       |                    |        
   -------------------       -----------------         ------------------       
	B/                                                                             
                                                                                
   ------------                 ------------               ----------------     
  |                   |	   |                 |       |                   |      
  |  non MPLS  |	   |   MPLS     |       |   non MPLS |                         
  |  network      |--------|   Network  |-------|   network      |              
  |  DiffServ      |	   |   Int serv   |       |   Diffserv       |             
  |                   |	   |                |       |                    |      
   -------------------          ----------------         --------------------   
                                                                                
6/ MPLS over satellite.                                                         
Has it be ever considered?                                                      
Briefly, may high bandwidth-delay-factor links hamper MPLS working properly.    
What issues and adaptation do you see when evocating MPLS over satellite?       
                                                                                
I really thank you for your reading and your help.                              
                                                                                
Sincerely,                                                                      
                                                                                
Carl Creange.                                                                   
                                                                                
Institut National des Télécommunications - FRANCE                               
                                                                                


From owner-mpls@UU.NET  Fri Aug 11 07:03:44 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09106
	for <mpls-archive@lists.ietf.org>; Fri, 11 Aug 2000 07:03:44 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbts11779;
	Fri, 11 Aug 2000 11:03:06 GMT
Received: by mail-control.mail.uu.net 
	id QQjbts01568
	for mpls-outgoing; Fri, 11 Aug 2000 11:02:42 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjbts01262
	for <mpls@mail-control.mail.uu.net>; Fri, 11 Aug 2000 11:02:40 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjbts29884
	for <mpls@uu.net>; Fri, 11 Aug 2000 07:02:39 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjbts16446
	for <mpls@uu.net>; Fri, 11 Aug 2000 11:02:38 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id HAA21341
	for mpls@uu.net; Fri, 11 Aug 2000 07:02:37 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjbts28785
	for <mpls@mail-control.mail.uu.net>; Fri, 11 Aug 2000 11:02:13 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbts29820
	for <mpls@uu.net>; Fri, 11 Aug 2000 07:02:02 -0400 (EDT)
Received: from ietf.org by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: odin.ietf.org [132.151.1.176])
	id QQjbts11309
	for <mpls@uu.net>; Fri, 11 Aug 2000 11:01:46 GMT
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08842;
	Fri, 11 Aug 2000 07:01:45 -0400 (EDT)
Message-Id: <200008111101.HAA08842@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;
Cc: mpls@UU.NET
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mpls-label-encaps-08.txt
Date: Fri, 11 Aug 2000 07:01:45 -0400
Sender: owner-mpls@UU.NET
Precedence: bulk

--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		: MPLS Label Stack Encoding
	Author(s)	: E. Rosen, Y. Rekhter, D. Tappan,
                          G. Fedorkow, D. Farinacci, T. Li, A. Conta
	Filename	: draft-ietf-mpls-label-encaps-08.txt
	Pages		: 22
	Date		: 10-Aug-00
	
'Multi-Protocol Label Switching (MPLS)' [1,2] requires a set of
procedures for augmenting network layer packets with 'label stacks',
thereby turning them into 'labeled packets'.  Routers which support
MPLS are known as 'Label Switching Routers', or 'LSRs'.  In order to
transmit a labeled packet on a particular data link, an LSR must
support an encoding technique which, given a label stack and a
network layer packet, produces a labeled packet.  This document
specifies the encoding to be used by an LSR in order to transmit
labeled packets on PPP data links, on LAN data links, and possibly on
other data links as well.  On some data links, the label at the top
of the stack may be encoded in a different manner, but the techniques
described here MUST be used to encode the remainder of the label
stack.  This document also specifies rules and procedures for
processing the various fields of the label stack encoding.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-label-encaps-08.txt

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-label-encaps-08.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-label-encaps-08.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:	<20000810140154.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mpls-label-encaps-08.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mpls-label-encaps-08.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000810140154.I-D@ietf.org>

--OtherAccess--

--NextPart--





From owner-mpls@UU.NET  Fri Aug 11 07:04:11 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09124
	for <mpls-archive@lists.ietf.org>; Fri, 11 Aug 2000 07:04:11 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbts17463;
	Fri, 11 Aug 2000 11:03:44 GMT
Received: by mail-control.mail.uu.net 
	id QQjbts03252
	for mpls-outgoing; Fri, 11 Aug 2000 11:03:22 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjbts03209
	for <mpls@mail-control.mail.uu.net>; Fri, 11 Aug 2000 11:03:08 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjbts28331
	for <mpls@uu.net>; Fri, 11 Aug 2000 07:02:58 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjbts16738
	for <mpls@uu.net>; Fri, 11 Aug 2000 11:02:58 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id HAA21371
	for mpls@uu.net; Fri, 11 Aug 2000 07:02:57 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjbts29947
	for <mpls@mail-control.mail.uu.net>; Fri, 11 Aug 2000 11:02:28 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbts29863
	for <mpls@uu.net>; Fri, 11 Aug 2000 07:02:21 -0400 (EDT)
Received: from ietf.org by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: odin.ietf.org [132.151.1.176])
	id QQjbts11334
	for <mpls@uu.net>; Fri, 11 Aug 2000 11:01:51 GMT
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08856;
	Fri, 11 Aug 2000 07:01:50 -0400 (EDT)
Message-Id: <200008111101.HAA08856@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;
Cc: mpls@UU.NET
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mpls-arch-07.txt
Date: Fri, 11 Aug 2000 07:01:50 -0400
Sender: owner-mpls@UU.NET
Precedence: bulk

--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 Architecture
	Author(s)	: E. Rosen, A. Viswanathan, R. Callon
	Filename	: draft-ietf-mpls-arch-07.txt
	Pages		: 62
	Date		: 10-Aug-00
	
This internet draft specifies the architecture for Multiprotocol
Label Switching (MPLS).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-arch-07.txt

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-arch-07.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mpls-arch-07.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20000810140203.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mpls-arch-07.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mpls-arch-07.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000810140203.I-D@ietf.org>

--OtherAccess--

--NextPart--





From owner-mpls@UU.NET  Fri Aug 11 09:43:10 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15515
	for <mpls-archive@lists.ietf.org>; Fri, 11 Aug 2000 09:43:09 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbuc13846;
	Fri, 11 Aug 2000 13:42:47 GMT
Received: by mail-control.mail.uu.net 
	id QQjbuc05749
	for mpls-outgoing; Fri, 11 Aug 2000 13:42:12 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjbuc05737
	for <mpls@mail-control.mail.uu.net>; Fri, 11 Aug 2000 13:41:54 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjbuc29693
	for <mpls@uu.net>; Fri, 11 Aug 2000 09:41:33 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88])
	id QQjbuc06016
	for <mpls@uu.net>; Fri, 11 Aug 2000 13:41:32 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id GAA02493
	for <mpls@uu.net>; Fri, 11 Aug 2000 06:41:48 -0700 (PDT)
Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA16366 for mpls@uu.net; Fri, 11 Aug 2000 09:41:31 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjbtd06119
	for <mpls@mail-control.mail.uu.net>; Fri, 11 Aug 2000 07:18:50 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbtd29644
	for <mpls@UU.NET>; Fri, 11 Aug 2000 03:18:34 -0400 (EDT)
Received: from blaze.hcltech.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [204.160.253.201])
	id QQjbtd13997
	for <mpls@UU.NET>; Fri, 11 Aug 2000 07:18:31 GMT
Received: from netlab.hcltech.com ([192.168.201.35])
	by blaze.hcltech.com (8.9.3/8.8.7) with ESMTP id MAA17167;
	Fri, 11 Aug 2000 12:49:41 +0530
Message-ID: <3993A7C6.BFFD0C3@netlab.hcltech.com>
Date: Fri, 11 Aug 2000 12:44:14 +0530
From: naidu <naidu@netlab.hcltech.com>
Organization: HCL Networking Systems Lab
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mpls@netlab.hcltech.com
CC: "'Man Trinh'" <mtrinh1@yahoo.com>, mpls@UU.NET
Subject: Re: [mpls] Re: MPLS label authentication
References: <fa20a09fb4cbdac50893623d7c71e94839935d6f@force10networks.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi,

Nageswara Soma wrote:
> 
> LDP uses reliable TCP for label exchange.

I think the question is about Label in data path.
IP header checksum calculation won't consider MPLS Label.
So label can be corrupted and have to rely on Data Link CRC.

Regards
Naidu
HCL Networking Products Division
 
> > Hi,
> >
> > I am kind of new to the MPLS protocol.  If I ask a
> > question that is already discussed, please point me
> > to the thread in the archive.
> >
> > My question is how do I know that the label that I
> > am getting is the correct label.  What if it is
> > corrupted when I receive it?
> >
> > Thanks,
> > -Man



From owner-mpls@UU.NET  Fri Aug 11 09:54:48 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16111
	for <mpls-archive@lists.ietf.org>; Fri, 11 Aug 2000 09:54:48 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbud18761;
	Fri, 11 Aug 2000 13:54:20 GMT
Received: by mail-control.mail.uu.net 
	id QQjbud06636
	for mpls-outgoing; Fri, 11 Aug 2000 13:53:52 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjbud06631
	for <mpls@mail-control.mail.uu.net>; Fri, 11 Aug 2000 13:53:43 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbud29266
	for <mpls@uu.net>; Fri, 11 Aug 2000 09:53:20 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjbud00725
	for <mpls@uu.net>; Fri, 11 Aug 2000 13:53:19 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA06084
	for mpls@uu.net; Fri, 11 Aug 2000 09:53:19 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjbud06591
	for <mpls@mail-control.mail.uu.net>; Fri, 11 Aug 2000 13:52:52 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbud01953
	for <mpls@UU.NET>; Fri, 11 Aug 2000 09:52:37 -0400 (EDT)
Received: from picard.noroff.no by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [212.20.204.3])
	id QQjbud29215
	for <mpls@UU.NET>; Fri, 11 Aug 2000 13:52:22 GMT
Received: by picard.noroff.no (Postfix, from userid 815)
	id 1D17322002; Fri, 11 Aug 2000 16:36:41 +0200 (CEST)
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177])
	by picard.noroff.no (Postfix) with ESMTP id 7DC9CB3802
	for <magg@NOROFF.NO>; Fri, 11 Aug 2000 16:36:38 +0200 (CEST)
Received: (from adm@localhost)
	by loki.ietf.org (8.9.1b+Sun/8.9.1) id IAA11128
	for ietf-123-outbound.09@ietf.org; Fri, 11 Aug 2000 08:55:02 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])
	by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA10083
	for <all-ietf@loki.ietf.org>; Fri, 11 Aug 2000 07:01:45 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08842;
	Fri, 11 Aug 2000 07:01:45 -0400 (EDT)
Message-Id: <200008111101.HAA08842@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;
Cc: mpls@UU.NET
From: Internet-Drafts@ietf.org
Reply-To: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mpls-label-encaps-08.txt
Date: Fri, 11 Aug 2000 07:01:45 -0400
X-AntiVirus: scanned for viruses by Amavis 0.2.1-pre2
Sender: owner-mpls@UU.NET
Precedence: bulk

--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		: MPLS Label Stack Encoding
	Author(s)	: E. Rosen, Y. Rekhter, D. Tappan,
                          G. Fedorkow, D. Farinacci, T. Li, A. Conta
	Filename	: draft-ietf-mpls-label-encaps-08.txt
	Pages		: 22
	Date		: 10-Aug-00
	
'Multi-Protocol Label Switching (MPLS)' [1,2] requires a set of
procedures for augmenting network layer packets with 'label stacks',
thereby turning them into 'labeled packets'.  Routers which support
MPLS are known as 'Label Switching Routers', or 'LSRs'.  In order to
transmit a labeled packet on a particular data link, an LSR must
support an encoding technique which, given a label stack and a
network layer packet, produces a labeled packet.  This document
specifies the encoding to be used by an LSR in order to transmit
labeled packets on PPP data links, on LAN data links, and possibly on
other data links as well.  On some data links, the label at the top
of the stack may be encoded in a different manner, but the techniques
described here MUST be used to encode the remainder of the label
stack.  This document also specifies rules and procedures for
processing the various fields of the label stack encoding.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-label-encaps-08.txt

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-label-encaps-08.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-label-encaps-08.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:	<20000810140154.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mpls-label-encaps-08.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mpls-label-encaps-08.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000810140154.I-D@ietf.org>

--OtherAccess--

--NextPart--





From owner-mpls@UU.NET  Fri Aug 11 09:57:34 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16338
	for <mpls-archive@lists.ietf.org>; Fri, 11 Aug 2000 09:57:34 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbud22484;
	Fri, 11 Aug 2000 13:57:21 GMT
Received: by mail-control.mail.uu.net 
	id QQjbud06867
	for mpls-outgoing; Fri, 11 Aug 2000 13:56:52 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjbud06851
	for <mpls@mail-control.mail.uu.net>; Fri, 11 Aug 2000 13:56:48 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbud02758
	for <mpls@uu.net>; Fri, 11 Aug 2000 09:56:39 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjbud05958
	for <mpls@uu.net>; Fri, 11 Aug 2000 13:56:39 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA07211
	for mpls@uu.net; Fri, 11 Aug 2000 09:56:35 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjbud06745
	for <mpls@mail-control.mail.uu.net>; Fri, 11 Aug 2000 13:56:03 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbud02615
	for <mpls@UU.NET>; Fri, 11 Aug 2000 09:55:54 -0400 (EDT)
Received: from picard.noroff.no by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [212.20.204.3])
	id QQjbud04786
	for <mpls@UU.NET>; Fri, 11 Aug 2000 13:55:53 GMT
Received: by picard.noroff.no (Postfix, from userid 815)
	id 5452122002; Fri, 11 Aug 2000 16:40:12 +0200 (CEST)
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177])
	by picard.noroff.no (Postfix) with ESMTP id 26407B3802
	for <magg@NOROFF.NO>; Fri, 11 Aug 2000 16:40:10 +0200 (CEST)
Received: (from adm@localhost)
	by loki.ietf.org (8.9.1b+Sun/8.9.1) id JAA11234
	for ietf-123-outbound.09@ietf.org; Fri, 11 Aug 2000 09:05:01 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])
	by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA10090
	for <all-ietf@loki.ietf.org>; Fri, 11 Aug 2000 07:01:49 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08856;
	Fri, 11 Aug 2000 07:01:50 -0400 (EDT)
Message-Id: <200008111101.HAA08856@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;
Cc: mpls@UU.NET
From: Internet-Drafts@ietf.org
Reply-To: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mpls-arch-07.txt
Date: Fri, 11 Aug 2000 07:01:50 -0400
X-AntiVirus: scanned for viruses by Amavis 0.2.1-pre2
Sender: owner-mpls@UU.NET
Precedence: bulk

--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 Architecture
	Author(s)	: E. Rosen, A. Viswanathan, R. Callon
	Filename	: draft-ietf-mpls-arch-07.txt
	Pages		: 62
	Date		: 10-Aug-00
	
This internet draft specifies the architecture for Multiprotocol
Label Switching (MPLS).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-arch-07.txt

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-arch-07.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mpls-arch-07.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20000810140203.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mpls-arch-07.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mpls-arch-07.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000810140203.I-D@ietf.org>

--OtherAccess--

--NextPart--





From owner-mpls@UU.NET  Fri Aug 11 10:28:38 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19178
	for <mpls-archive@lists.ietf.org>; Fri, 11 Aug 2000 10:28:37 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbuf20845;
	Fri, 11 Aug 2000 14:28:24 GMT
Received: by mail-control.mail.uu.net 
	id QQjbuf21108
	for mpls-outgoing; Fri, 11 Aug 2000 14:28:07 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjbuf21100
	for <mpls@mail-control.mail.uu.net>; Fri, 11 Aug 2000 14:28:03 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjbuf06342
	for <mpls@uu.net>; Fri, 11 Aug 2000 10:27:49 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88])
	id QQjbuf25302
	for <mpls@uu.net>; Fri, 11 Aug 2000 14:27:33 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id HAA00380;
	Fri, 11 Aug 2000 07:27:50 -0700 (PDT)
Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id KAA16481; Fri, 11 Aug 2000 10:27:32 -0400 (EDT)
Message-Id: <200008111427.KAA16481@erosen-sun.cisco.com>
X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs
To: mpls@UU.NET
Subject: latest arch and encaps i-ds
Reply-to: erosen@cisco.com
User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1
 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1)
 MULE/4.0 (HANANOEN)
MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune")
Content-Type: text/plain; charset=US-ASCII
Date: Fri, 11 Aug 2000 10:27:32 -0400
From: Eric Rosen <erosen@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

Before anyone asks, arch-07 and  encaps-08 are identical to their respective
predecessors,  except that,  (a) by  request of  the AD,  references  to the
framework document  have been removed,  (b) authors' affiliations  have been
updated. 

I am  assured by the AD that  these documents, which passed  final last call
about a year ago, will be published as RFCs soon. 




From owner-mpls@UU.NET  Fri Aug 11 10:49:19 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20613
	for <mpls-archive@lists.ietf.org>; Fri, 11 Aug 2000 10:49:18 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbuh19415;
	Fri, 11 Aug 2000 14:49:01 GMT
Received: by mail-control.mail.uu.net 
	id QQjbuh23244
	for mpls-outgoing; Fri, 11 Aug 2000 14:48:27 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjbuh23199
	for <mpls@mail-control.mail.uu.net>; Fri, 11 Aug 2000 14:48:19 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbuh13671
	for <mpls@uu.net>; Fri, 11 Aug 2000 10:48:11 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjbuh20626
	for <mpls@uu.net>; Fri, 11 Aug 2000 14:48:10 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA15423
	for mpls@uu.net; Fri, 11 Aug 2000 10:48:10 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjbuh23044
	for <mpls@mail-control.mail.uu.net>; Fri, 11 Aug 2000 14:47:33 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbuh10568
	for <mpls@uu.net>; Fri, 11 Aug 2000 10:47:22 -0400 (EDT)
Received: from ietf.org by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: odin.ietf.org [132.151.1.176])
	id QQjbuh18635
	for <mpls@uu.net>; Fri, 11 Aug 2000 14:46:52 GMT
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20448;
	Fri, 11 Aug 2000 10:46:49 -0400 (EDT)
Message-Id: <200008111446.KAA20448@ietf.org>
To: IETF-Announce:;
Cc: mpls@UU.NET
From: The IESG <iesg-secretary@ietf.org>
SUBJECT: Last Call: ICMP Extensions for MultiProtocol Label Switching
	 to Proposed Standard
Reply-to: iesg@ietf.org
Date: Fri, 11 Aug 2000 10:46:49 -0400
Sender: owner-mpls@UU.NET
Precedence: bulk


The IESG has received a request from the Multiprotocol Label Switching
Working Group to consider ICMP Extensions for MultiProtocol Label
Switching <draft-ietf-mpls-icmp-02.txt> as a Proposed Standard.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg@ietf.org or ietf@ietf.org mailing lists by August 25, 2000.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-mpls-icmp-02.txt





From owner-mpls@UU.NET  Fri Aug 11 11:22:32 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22279
	for <mpls-archive@lists.ietf.org>; Fri, 11 Aug 2000 11:22:31 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbuj24565;
	Fri, 11 Aug 2000 15:22:17 GMT
Received: by mail-control.mail.uu.net 
	id QQjbuj07578
	for mpls-outgoing; Fri, 11 Aug 2000 15:21:46 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjbuj07518
	for <mpls@mail-control.mail.uu.net>; Fri, 11 Aug 2000 15:21:28 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbuj20785
	for <mpls@UU.NET>; Fri, 11 Aug 2000 11:21:21 -0400 (EDT)
Received: from ennovatenetworks.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ennovatenetworks.com [208.227.99.254])
	id QQjbuj13360
	for <mpls@UU.NET>; Fri, 11 Aug 2000 15:21:06 GMT
Received: from tworster ([208.227.99.12])
	by ennovatenetworks.com (8.8.7/8.8.7) with SMTP id LAA00870;
	Fri, 11 Aug 2000 11:20:46 -0400 (EDT)
	(envelope-from tom@ennovatenetworks.com)
From: "tom worster" <tom@ennovatenetworks.com>
To: "'Riad Hartani'" <riad@caspiannetworks.com>
Cc: <mpls@UU.NET>
Subject: RE: I-D ACTION:draft-worster-mpls-in-ip-02.txt
Date: Fri, 11 Aug 2000 11:21:35 -0400
Message-ID: <001401c003a7$d6f9a2c0$6640a8c0@thefsb.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <2FF612B13481D311B40A009027B0C83886AB4A@MAIL>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Riad
Hartani
> 
> A couple of questions regarding the MPLS-in-IP draft below:
> 
> 1) IP-in-IP encapsulation clearly describes how to set/handle 
> the outer IP
> header fields, such as TOS, Id/Flag/Fragment fields, TTL and 
> others. In this
> type of encapsulation, setting these fields is directly 
> related to how they
> are set within the inner IP header (eg: TOS is simply copied 
> from inner IP
> header). 
> 
> What are the procedures if the encapsulated packet is now an 
> MPLS packet
> rather than an IP packet ? Clear procedures (even if they are 
> trivial) would
> make the draft more clear (specially if the MPLS packet/label 
> is QoS aware).

that's an interesting question. i think it's hard to provide 
a specification like ip-in-ip since the correct handling of
the encapsulating ip header depends on whet you have inside
the mpls message. there might be a different behaviour, for 
example, when encapsulating an ipv4 packet from a vpn and
when carrying a compressed rtp packet. by not specifying such 
things we leave it open to the needs of the application. in
the case of ip-in-ip the procedures _can_ be specified since
the encapsulated packet is known to be ip. do you have any
specific examples?

as far as qos goes, we mentioned in the usage considerations
that diff-serv or rsvp/int-serv may be used. here again, if, 
how, and when to use these depends on the application. for
example, if the mpls-in-ip tunnel terminates directly on 
media gateways then one may have explicit qos requirements 
in terms of the voip application. in this case i don't see
that the mpls-in-ip spec should mention the qos mapping down
to network layer beyond that such a mapping may be used 
(which is what we already have).


> 2) In section 4, I suspect that security consideration inherent to IP
> encapsulation schemes will also apply in this case. So, additional
> precautions are needed when compared to the LSR/LER case.

this is true. perhaps i didn't mention it because it seemed
obvious to me.


> 3) Reading the abstract, one may think that extending a 
> Voice_over_IP over
> MPLS tunnel to a non MPLS-core by adding an IP encapsulation 
> is one of the
> motivations for this work. Well, I fail to see why. The 
> amount of overhead
> given the small voice packet size would be too large using 
> these successive
> encapsulation schemes. Is this really one of the motivations ?

yes. the compression of voip headers using mpls means that voip/
mpls/ip can be more efficient than voip. see for example thomas
theimer's draft. 

c u
tom


______________________________________________________________________
tom worster, ennovate networks, 60 codman hill rd, boxborough ma 01719
tel: +1 978 206 0490   fax: +1 978 263 1090   tom@ennovatenetworks.com




From owner-mpls@UU.NET  Fri Aug 11 11:51:47 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23351
	for <mpls-archive@lists.ietf.org>; Fri, 11 Aug 2000 11:51:47 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbul17187;
	Fri, 11 Aug 2000 15:51:16 GMT
Received: by mail-control.mail.uu.net 
	id QQjbul11097
	for mpls-outgoing; Fri, 11 Aug 2000 15:50:47 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjbul11092
	for <mpls@mail-control.mail.uu.net>; Fri, 11 Aug 2000 15:50:41 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbul27038
	for <mpls@uu.net>; Fri, 11 Aug 2000 11:50:34 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjbul16675
	for <mpls@uu.net>; Fri, 11 Aug 2000 15:50:33 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA24795
	for mpls@uu.net; Fri, 11 Aug 2000 11:50:32 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjbul11008
	for <mpls@mail-control.mail.uu.net>; Fri, 11 Aug 2000 15:49:53 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjbul23104
	for <mpls@UU.NET>; Fri, 11 Aug 2000 11:49:37 -0400 (EDT)
Received: from picard.noroff.no by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [212.20.204.3])
	id QQjbul23860
	for <mpls@UU.NET>; Fri, 11 Aug 2000 15:49:36 GMT
Received: by picard.noroff.no (Postfix, from userid 815)
	id 07FE222002; Fri, 11 Aug 2000 18:33:56 +0200 (CEST)
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177])
	by picard.noroff.no (Postfix) with ESMTP id 0D6AAB3802
	for <magg@NOROFF.NO>; Fri, 11 Aug 2000 18:33:53 +0200 (CEST)
Received: (from adm@localhost)
	by loki.ietf.org (8.9.1b+Sun/8.9.1) id KAA12639
	for ietf-123-outbound.09@ietf.org; Fri, 11 Aug 2000 10:55:01 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])
	by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id KAA12541
	for <all-ietf@loki.ietf.org>; Fri, 11 Aug 2000 10:46:50 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20448;
	Fri, 11 Aug 2000 10:46:49 -0400 (EDT)
Message-Id: <200008111446.KAA20448@ietf.org>
To: IETF-Announce:;
Cc: mpls@UU.NET
From: The IESG <iesg-secretary@ietf.org>
SUBJECT: Last Call: ICMP Extensions for MultiProtocol Label Switching
	 to Proposed Standard
Reply-To: iesg@ietf.org
Date: Fri, 11 Aug 2000 10:46:49 -0400
X-AntiVirus: scanned for viruses by Amavis 0.2.1-pre2
Sender: owner-mpls@UU.NET
Precedence: bulk


The IESG has received a request from the Multiprotocol Label Switching
Working Group to consider ICMP Extensions for MultiProtocol Label
Switching <draft-ietf-mpls-icmp-02.txt> as a Proposed Standard.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg@ietf.org or ietf@ietf.org mailing lists by August 25, 2000.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-mpls-icmp-02.txt





From owner-mpls@UU.NET  Fri Aug 11 12:21:41 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24346
	for <mpls-archive@lists.ietf.org>; Fri, 11 Aug 2000 12:21:40 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbun24013;
	Fri, 11 Aug 2000 16:21:24 GMT
Received: by mail-control.mail.uu.net 
	id QQjbun25730
	for mpls-outgoing; Fri, 11 Aug 2000 16:21:00 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjbun25710
	for <mpls@mail-control.mail.uu.net>; Fri, 11 Aug 2000 16:20:48 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbun29155
	for <mpls@uu.net>; Fri, 11 Aug 2000 12:20:34 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88])
	id QQjbun03123
	for <mpls@uu.net>; Fri, 11 Aug 2000 16:20:34 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id JAA22563
	for <mpls@uu.net>; Fri, 11 Aug 2000 09:20:50 -0700 (PDT)
Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id MAA16845 for mpls@uu.net; Fri, 11 Aug 2000 12:20:32 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjbum24451
	for <mpls@mail-control.mail.uu.net>; Fri, 11 Aug 2000 16:10:25 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbum27245
	for <mpls@UU.NET>; Fri, 11 Aug 2000 12:10:15 -0400 (EDT)
Received: from rambo.globespan.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: p1.globespan.net [209.191.59.250])
	id QQjbum27412
	for <mpls@UU.NET>; Fri, 11 Aug 2000 16:10:14 GMT
Received: by rambo with Internet Mail Service (5.5.2650.21)
	id <QDYNXTTP>; Fri, 11 Aug 2000 12:09:56 -0400
Received: from globespan.net (ROHIT [192.168.25.21]) by rambo.globespan.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id QDYNXTTN; Fri, 11 Aug 2000 12:09:53 -0400
From: Rohit Chhapolia <rchhapolia@globespan.net>
To: John Sparr <johnrdb@yahoo.com>
Cc: mpls@UU.NET
Message-ID: <39942550.32A73C5@globespan.net>
Date: Fri, 11 Aug 2000 12:09:52 -0400
Organization: Globespan, Inc.
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
Subject: Re: what will ingress node do?
References: <20000803191731.22064.qmail@web5401.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

John Sparr wrote:
> 
> Sorry,  this question is from RSVP-TE draft(06).
> 
> Hi,
> 
> If a LSP setup failed because ingress node received a
> PathErr message, When the ingress node received a
> PathErr (like "Routing Problem"), what will the
> ingress node do? send a path teardown request message?

This is one possibility.

> or what?

Or it may send Path message with changed characteristics
that should cause this LSP being routed through another
path.

> 
> Thanks in advance
> John
> 
> __________________________________________________
> Do You Yahoo!?
> Kick off your party with Yahoo! Invites.
> http://invites.yahoo.com/

-- 
Rohit Chhapolia
Globespan, Inc.
voice: 732-345-6237
mailto:rohit@globespan.net
http://www.globespan.net



From owner-mpls@UU.NET  Fri Aug 11 13:47:39 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27904
	for <mpls-archive@lists.ietf.org>; Fri, 11 Aug 2000 13:47:38 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbut21242;
	Fri, 11 Aug 2000 17:47:22 GMT
Received: by mail-control.mail.uu.net 
	id QQjbut16941
	for mpls-outgoing; Fri, 11 Aug 2000 17:47:01 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjbut16924
	for <mpls@mail-control.mail.uu.net>; Fri, 11 Aug 2000 17:46:49 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbut20372
	for <mpls@uu.net>; Fri, 11 Aug 2000 13:46:45 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjbut20625
	for <mpls@uu.net>; Fri, 11 Aug 2000 17:46:29 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA11487
	for mpls@uu.net; Fri, 11 Aug 2000 13:46:29 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjbut16745
	for <mpls@mail-control.mail.uu.net>; Fri, 11 Aug 2000 17:45:51 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbut16132
	for <mpls@UU.NET>; Fri, 11 Aug 2000 13:45:39 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjbut20167
	for <mpls@UU.NET>; Fri, 11 Aug 2000 17:45:38 GMT
Received: from lir.cisco.com (lir-hme0.cisco.com [171.69.204.20])
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id NAA11351;
	Fri, 11 Aug 2000 13:45:37 -0400 (EDT)
Received: from localhost (swallow@localhost) by lir.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id NAA16209; Fri, 11 Aug 2000 13:45:37 -0400 (EDT)
Message-Id: <200008111745.NAA16209@lir.cisco.com>
X-Authentication-Warning: lir.cisco.com: swallow owned process doing -bs
To: "Sanford, Bill" <bills@netplane.com>
cc: "'mpls@uu.net'" <mpls@UU.NET>, swallow@cisco.com
Subject: Re: EXPLICIT_ROUTE object too big for PATH or RESV message 
In-reply-to: Your message of "Wed, 26 Jul 2000 09:19:15 EDT."
             <87009604743AD411B1F600508BA0F959040B57@xover.hjinc.com> 
Date: Fri, 11 Aug 2000 13:45:37 -0400
From: George Swallow <swallow@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

Bill 

This seems like a pretty remote case.  

First the ERO never is carried on a RESV message.  I point this out
because the RESV message was the primary worry on RRO.  An RESV
message not only can carry an RRO, but could carry *many* RROs.  So
the possibility of exceeding the Max of 64K was not entirely remote.
(Remember that fragmentation of RSVP messages is legal.)

The ERO is carried only in the PATH message.  It is difficult to
imagine a PATH message growing beyond 64K.  Perhaps with the help of
an RRO one could squint hard and imagine it.  But in that case you can
process the ERO first and chuck the RRO.

So I don't think that an error code is necessary.

...George

==================================================================
George Swallow       Cisco Systems                   (978) 244-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824



From owner-mpls@UU.NET  Fri Aug 11 14:08:41 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28637
	for <mpls-archive@lists.ietf.org>; Fri, 11 Aug 2000 14:08:40 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbuu04571;
	Fri, 11 Aug 2000 18:08:24 GMT
Received: by mail-control.mail.uu.net 
	id QQjbuu00502
	for mpls-outgoing; Fri, 11 Aug 2000 18:08:01 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjbuu00489
	for <mpls@mail-control.mail.uu.net>; Fri, 11 Aug 2000 18:07:54 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbuu24550
	for <mpls@uu.net>; Fri, 11 Aug 2000 14:07:26 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjbuu03837
	for <mpls@uu.net>; Fri, 11 Aug 2000 18:07:26 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA14991
	for mpls@uu.net; Fri, 11 Aug 2000 14:07:25 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjbuu00346
	for <mpls@mail-control.mail.uu.net>; Fri, 11 Aug 2000 18:07:07 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbuu20141
	for <mpls@uu.net>; Fri, 11 Aug 2000 14:06:51 -0400 (EDT)
Received: from funnel.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQjbuu03467
	for <mpls@uu.net>; Fri, 11 Aug 2000 18:06:49 GMT
Received: from lir.cisco.com (lir-hme1.cisco.com [171.69.209.57]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA24020; Fri, 11 Aug 2000 14:06:49 -0400 (EDT)
Received: from localhost (swallow@localhost) by lir.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id OAA05537; Fri, 11 Aug 2000 14:06:48 -0400 (EDT)
Message-Id: <200008111806.OAA05537@lir.cisco.com>
X-Authentication-Warning: lir.cisco.com: swallow owned process doing -bs
To: Adrian Farrel <AF@datcon.co.uk>
cc: swallow@cisco.com, mpls@UU.NET, swallow@cisco.com
Subject: Re: Comments on draft-ietf-mpls-rsvp-lsp-tunnel-06 
In-reply-to: Your message of "Wed, 26 Jul 2000 20:46:34 BST."
             <6DEA508A9A0ED31192E80000F6CC176E2C9C99@monk.datcon.co.uk> 
Date: Fri, 11 Aug 2000 14:06:48 -0400
From: George Swallow <swallow@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

> Questions
> =========
> 
> 4.4.1.3 Recorded Label Subobject
>     I can see how this is useful information for NM.  Is the label
>     completely useful without knowing the label space from which the 
>     label comes?  This would be exposed as an interface index or a 
>     magic value for the global label space.  This could easily be added 
>     to the subobject to give...
> 
>        0                   1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |     Type      |     Length    |    Flags      |   C-Type      |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |       Interface Identifier                                    |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |       Contents of Label Object                                |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>     with the following text
> 
>       Interface Identifier
> 
>          The interface index that identifies the label space from which
>          this label comes.  A value of zero (0) indicates that the label 
>          comes from the global label space.

The generalized label object will carry a link ID.  So if this is
needed that we can simply use that format.
(see draft-ashwood-generalized-mpls-signaling-00.txt)

> 4.4.2 RRO Applicability
>     The text inherited from the previous draft says that an RRO can
>     be converted to an ERO "with minor changes".  This has now been
>     broken by the addition of the Label subobject.
>     It would be unfortunate (but perhaps necessary?) to require that
>     the RRO is parsed when pinning a session path.  The alternative
>     would appear to be to allow the Label object to be present but
>     ignored in the ERO.

There are two outs here. The head end can refresh the path with the
bit off which will cause a fresh recording without the label
information.

The other out is as you suggest.  I think it's much cleaner for the
node which is formating the ERO to worry about this, so I would oppose
including the label having the ERO processing skip over the subobject.

> 4.5 Processing RRO
>     The text here describes adding the Label Record subobject whenever
>     the SESSION_ATTRIBUTE indicate Label_Recording.  Of course, this 
>     is typically only possible on the reverse path.  Thus the RRO on 
>     he forward path need not include the LR subobject.

If no one objects, I'll limit the Label Record to the RESV message.

> 4.5 Processing RRO
>     Can we allow for nodes that don't support adding Label Record
>     subobjects?  Or is this covered in "SHOULD"?

Yes.

> Editorial
> =========
> 
> 2.6 Step 2. If DF bit not set step a)
>     Would it be clearer (and no less accurate :-) to replace "the value
>     of the parameter" with "M"?

Done.

> 3.2 Expanding <FF flow descriptor list> leads to (optionally) two
>     instances of <FLOWSPEC> for a single <FILTER_SPEC> and <LABEL>.
>     I'm assuming you didn't want this (or is there a cunning use?)
>     and that the correct correlation to adding <FLOWSPEC> to the
>     <FF flow descriptor list> is to remove it from the
>     <FF flow descriptor>.

See archive.

> 4.8.1 Session Attributes - Flags (ditto 4.8.2)
>     Is it wise to re-use the "Merging Permitted" flag for "Label 
>     recording desired"?  won't this cause interop issues with old
>     implementations?

As far as I know nothing in the field is using the "merging permitted"
bit, so I reused the value.

> Typos
> =====

Thanks.

...George

==================================================================
George Swallow       Cisco Systems                   (978) 244-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824



From owner-mpls@UU.NET  Fri Aug 11 14:36:12 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29556
	for <mpls-archive@lists.ietf.org>; Fri, 11 Aug 2000 14:36:12 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbuw06271;
	Fri, 11 Aug 2000 18:35:55 GMT
Received: by mail-control.mail.uu.net 
	id QQjbuw02908
	for mpls-outgoing; Fri, 11 Aug 2000 18:35:33 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjbuw02903
	for <mpls@mail-control.mail.uu.net>; Fri, 11 Aug 2000 18:35:31 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjbuw00486
	for <mpls@uu.net>; Fri, 11 Aug 2000 14:35:12 -0400 (EDT)
Received: from force10networks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtp.force10networks.com [206.54.51.114])
	id QQjbuw05401
	for <mpls@uu.net>; Fri, 11 Aug 2000 18:35:11 GMT
Received: by tonga.ncorenetworks.com with Internet Mail Service (5.5.2650.21)
	id <QVA2NGXK>; Fri, 11 Aug 2000 11:35:10 -0700
Message-ID: <3d6729f95a25e96d43f03f88eb6de67a399447b5@force10networks.com>
From: Nageswara Soma <nsoma@force10networks.com>
To: "'Man Trinh'" <mtrinh1@yahoo.com>
Cc: mpls@UU.NET
Subject: RE: MPLS label authentication
Date: Fri, 11 Aug 2000 11:35:09 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Man,
Sorry for misinterpreting your question.
Eric Gray got the exact answer.

> -----Original Message-----
> From: Man Trinh [mailto:mtrinh1@yahoo.com]
> Sent: Thursday, August 10, 2000 8:25 PM
> To: Nageswara Soma
> Cc: mpls@uu.net
> Subject: RE: MPLS label authentication
> 
> 
> Hi,
> 
> I am talking about the label I am getting when I
> do label exchange.  I am talking about the shim
> label in the data packet.  For example, the IP
> Header has the checksum for protection against
> corrupted header.  Is there anything I can do to
> protect against a corrupted MPLS label.
> 
> -Man
> 
> 
> --- Nageswara Soma <nsoma@force10networks.com> wrote:
> > LDP uses reliable TCP for label exchange.
> > 
> > > -----Original Message-----
> > > From: Man Trinh [mailto:mtrinh1@yahoo.com]
> > > Sent: Thursday, August 10, 2000 6:47 PM
> > > To: mpls@UU.NET
> > > Subject: MPLS label authentication
> > > 
> > > 
> > > Hi,
> > > 
> > > I am kind of new to the MPLS protocol.  If I ask a
> > > question that is already discussed, please point
> > me
> > > to the thread in the archive.
> > > 
> > > My question is how do I know that the label that I
> > > am getting is the correct label.  What if it is 
> > > corrupted when I receive it?
> > > 
> > > Thanks,
> > > -Man
> > > 
> > > 
> > > __________________________________________________
> > > Do You Yahoo!?
> > > Kick off your party with Yahoo! Invites.
> > > http://invites.yahoo.com/
> > > 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Kick off your party with Yahoo! Invites.
> http://invites.yahoo.com/
> 


From owner-mpls@UU.NET  Fri Aug 11 15:54:26 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01765
	for <mpls-archive@lists.ietf.org>; Fri, 11 Aug 2000 15:54:25 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjbvb13522;
	Fri, 11 Aug 2000 19:54:10 GMT
Received: by mail-control.mail.uu.net 
	id QQjbvb20329
	for mpls-outgoing; Fri, 11 Aug 2000 19:53:50 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjbvb20322
	for <mpls@mail-control.mail.uu.net>; Fri, 11 Aug 2000 19:53:48 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbvb21140
	for <mpls@UU.NET>; Fri, 11 Aug 2000 15:53:36 -0400 (EDT)
Received: from sol.extremenetworks.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sol.extremenetworks.com [216.52.8.2])
	id QQjbvb12957
	for <mpls@UU.NET>; Fri, 11 Aug 2000 19:53:20 GMT
Received: by SOL with Internet Mail Service (5.5.2650.21)
	id <QVZ8SADN>; Fri, 11 Aug 2000 12:53:11 -0700
Message-ID: <808F64DDB492D3119D3C00508B5D8D732FFE1D@SOL>
From: Olen Stokes <ostokes@extremenetworks.com>
To: "'mpls@UU.NET'" <mpls@UU.NET>
Subject: Label Distribution and Mapping
Date: Fri, 11 Aug 2000 12:53:08 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk


I would like to make certain that I am understanding the rules 
presented in Section 2.1 of the LDP Spec for mapping a FEC 
to a LSP.  Please consider the following network:

LER1 ----- LSR ---- LER2 ----

LER2 is the egress router for several routes.  The network is 
operating in downstream unsolicited mode. 

Are the following statements correct?

a) if LER2 wants a LSP that is used only for traffic destined to 
itself, it distributes a label mapping with a Host Address FEC 
for its address.

b) if LER2 wants a LSP that is used only for traffic to a 
particular route X for which it is the egress router, it distributes 
a label mapping with an Address Prefix FEC for route X.

c) if LER2 wants a single LSP that is used by all of the traffic 
for which it is the egress router, it distributes a label mapping 
with an Address Prefix FEC for its own address with a mask 
of 32 bits.

Thanks for any help that anyone can provide.

Cheers,
Olen









From owner-mpls@UU.NET  Mon Aug 14 06:43:16 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02948
	for <mpls-archive@lists.ietf.org>; Mon, 14 Aug 2000 06:43:16 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjces19039;
	Mon, 14 Aug 2000 10:42:41 GMT
Received: by mail-control.mail.uu.net 
	id QQjces18499
	for mpls-outgoing; Mon, 14 Aug 2000 10:42:20 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjces18494
	for <mpls@mail-control.mail.uu.net>; Mon, 14 Aug 2000 10:42:09 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjces25869
	for <mpls@uu.net>; Mon, 14 Aug 2000 06:42:08 -0400 (EDT)
Received: from rout-LRC-01.lrc.deene.ufu.br by wodc7mr2.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: rout-LRC-01.lrc.deene.ufu.br [200.19.152.13])
	id QQjces18070
	for <mpls@uu.net>; Mon, 14 Aug 2000 10:41:49 GMT
Received: from lrc.deene.ufu.br (200.19.148.192) by rout-LRC-01.lrc.deene.ufu.br
 (EMWAC SMTPRS 0.80) with SMTP id <B0000048112@rout-LRC-01.lrc.deene.ufu.br>;
 Mon, 14 Aug 2000 07:44:14 -0300
Message-ID: <3997CE06.F31F2CEF@lrc.deene.ufu.br>
Date: Mon, 14 Aug 2000 07:46:30 -0300
From: Daniela Cunha <daniela@lrc.deene.ufu.br>
X-Mailer: Mozilla 4.72 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: (no subject)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi,
Is anybody here using the MNS simulator or has already used??
I need some help and they really don't answer my questions (about
granularity, cut-through and disconnect timer).

If so, and if you have a little time to help me, please contact me out
of this list.

Thank you
Daniela



From owner-mpls@UU.NET  Mon Aug 14 08:42:42 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05568
	for <mpls-archive@lists.ietf.org>; Mon, 14 Aug 2000 08:42:41 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcfa25528;
	Mon, 14 Aug 2000 12:42:17 GMT
Received: by mail-control.mail.uu.net 
	id QQjcfa17995
	for mpls-outgoing; Mon, 14 Aug 2000 12:41:40 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjcfa17990
	for <mpls@mail-control.mail.uu.net>; Mon, 14 Aug 2000 12:41:39 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjcfa09421
	for <mpls@uu.net>; Mon, 14 Aug 2000 08:41:33 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjcfa26711
	for <mpls@uu.net>; Mon, 14 Aug 2000 12:41:31 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id IAA22411
	for mpls@uu.net; Mon, 14 Aug 2000 08:41:30 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjcfa17865
	for <mpls@mail-control.mail.uu.net>; Mon, 14 Aug 2000 12:40:40 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjcfa09301
	for <mpls@UU.NET>; Mon, 14 Aug 2000 08:40:38 -0400 (EDT)
Received: from hawk.CrescentNetworks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.177.194.54])
	id QQjcfa25720
	for <mpls@UU.NET>; Mon, 14 Aug 2000 12:40:07 GMT
Received: from crescentnetworks.com (langille.in.crescentnets.com [192.168.29.105])
	by hawk.CrescentNetworks.com (8.9.3/8.9.3) with ESMTP id IAA26013;
	Mon, 14 Aug 2000 08:26:57 -0400 (EDT)
Message-ID: <3997E6F9.7A75759@crescentnetworks.com>
Date: Mon, 14 Aug 2000 08:32:57 -0400
From: Paul Langille <langille@CrescentNetworks.com>
Organization: Crescent Networks
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Thomas D. Nadeau" <tnadeau@cisco.com>
CC: arun Viswanathan <arun@force10networks.com>,
        cheenu Srinivasan <csrinivasan@tachion.com>, mpls@UU.NET
Subject: A few comments on draft-ietf-mpls-te-mib-04.txt
References: <4.3.2.7.2.20000706151449.05443db0@bucket.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


Hi Tom. Here are a few comments on the draft-ietf-mpls-te-mib-04.txt.

Content:

o Page 26: The description for the mplsTunnelResourceMaxRate object states that "0
indicates best-effort treatment." This violates the syntax of MplsBitRate.
MplsBitRate is defined in the LSR MIB and it has a "SYNTAX  Integer32
(1..2147483647)". The simple solution would be to change the range to include "0"
but the LSR MIB gone to last call. (Heavy sigh.)

o Should some text be added to indicate that the "mplsTunnelIndex" should be used
as the Tunnel ID?

Editorial:

o Section 6.2: The last sentence in this section is "Tunnel that do not share
resource...this table." "Tunnel" should be "Tunnels".

o Page 21: The description for mplsTunnelHopTable has the following sentence: "Each
row in this table is indexed primarily by the same index, mplsTunnelIndex, as the
row of the corresponding tunnel in mplsTunnelTable." The index to this table has
changed so this statement is no longer true.

o Page 24: In the description for mplsTunnelHopLspId, (in the second sentence)
"tuunel" should be replaced with "tunnel"

o Many pages. The references to <draft-ietf-mpls-lsr-mib-04.txt> need to be
updated.

o Starting at Page 26: The objects: mplsTunnelResourceMaxRate,
mplsTunnelResourceMeanRate, and mplsTunnelResourceMaxBurstSize all need to have
their descriptions updated to reflect the name changes of the LSR MIB. One example
is the sentence "This object is copied to an instance of mplsTSpecMaxRate in
mplsTSpecTable the index of which is copied into the corresponding
mplsInSegmentTSpecIndex." In this sentence "mplsTSpecMaxRate" should be changed to
"mplsTrafficParamMaxRate" etc. (I believe these names were changed in the LSR MIB
when going from version 02 to 03.)

--
Paul Langille                e-mail: langille@crescentnetworks.com
Crescent Networks            phone: (978) 244-9002 x244
201 Riverneck Road           fax: (978) 244-9211
Chelmsford, MA 01824





From owner-mpls@UU.NET  Mon Aug 14 09:20:33 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06967
	for <mpls-archive@lists.ietf.org>; Mon, 14 Aug 2000 09:20:32 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcfd20559;
	Mon, 14 Aug 2000 13:20:03 GMT
Received: by mail-control.mail.uu.net 
	id QQjcfd01855
	for mpls-outgoing; Mon, 14 Aug 2000 13:19:43 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjcfd01850
	for <mpls@mail-control.mail.uu.net>; Mon, 14 Aug 2000 13:19:38 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjcfd15662
	for <mpls@uu.net>; Mon, 14 Aug 2000 09:19:24 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjcfd26064
	for <mpls@uu.net>; Mon, 14 Aug 2000 13:19:23 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA26233
	for mpls@uu.net; Mon, 14 Aug 2000 09:19:22 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjcfd01833
	for <mpls@mail-control.mail.uu.net>; Mon, 14 Aug 2000 13:18:47 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjcfd17162
	for <mpls@UU.NET>; Mon, 14 Aug 2000 09:18:28 -0400 (EDT)
Received: from funnel.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQjcfd18006
	for <mpls@UU.NET>; Mon, 14 Aug 2000 13:18:27 GMT
Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.131.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA06252; Mon, 14 Aug 2000 09:18:27 -0400 (EDT)
Received: from tnadeau-pc02.cisco.com ([161.44.204.102])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AAI01827;
	Mon, 14 Aug 2000 09:18:24 -0400 (EDT)
Message-Id: <4.3.2.7.2.20000814091159.052c7b80@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 14 Aug 2000 09:12:40 -0400
To: Paul Langille <langille@crescentnetworks.com>
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Subject: Re: A few comments on draft-ietf-mpls-te-mib-04.txt
Cc: arun Viswanathan <arun@force10networks.com>,
        cheenu Srinivasan <csrinivasan@tachion.com>, mpls@UU.NET
In-Reply-To: <3997E6F9.7A75759@crescentnetworks.com>
References: <4.3.2.7.2.20000706151449.05443db0@bucket.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk


         Hi Paul,

         Thanks for the comments. We will get to looking at them shortly
and will reply to them then.

         Regards,

         --Tom


>Hi Tom. Here are a few comments on the draft-ietf-mpls-te-mib-04.txt.
>
>Content:
>
>o Page 26: The description for the mplsTunnelResourceMaxRate object states 
>that "0
>indicates best-effort treatment." This violates the syntax of MplsBitRate.
>MplsBitRate is defined in the LSR MIB and it has a "SYNTAX  Integer32
>(1..2147483647)". The simple solution would be to change the range to 
>include "0"
>but the LSR MIB gone to last call. (Heavy sigh.)
>
>o Should some text be added to indicate that the "mplsTunnelIndex" should 
>be used
>as the Tunnel ID?
>
>Editorial:
>
>o Section 6.2: The last sentence in this section is "Tunnel that do not share
>resource...this table." "Tunnel" should be "Tunnels".
>
>o Page 21: The description for mplsTunnelHopTable has the following 
>sentence: "Each
>row in this table is indexed primarily by the same index, mplsTunnelIndex, 
>as the
>row of the corresponding tunnel in mplsTunnelTable." The index to this 
>table has
>changed so this statement is no longer true.
>
>o Page 24: In the description for mplsTunnelHopLspId, (in the second sentence)
>"tuunel" should be replaced with "tunnel"
>
>o Many pages. The references to <draft-ietf-mpls-lsr-mib-04.txt> need to be
>updated.
>
>o Starting at Page 26: The objects: mplsTunnelResourceMaxRate,
>mplsTunnelResourceMeanRate, and mplsTunnelResourceMaxBurstSize all need to 
>have
>their descriptions updated to reflect the name changes of the LSR MIB. One 
>example
>is the sentence "This object is copied to an instance of mplsTSpecMaxRate in
>mplsTSpecTable the index of which is copied into the corresponding
>mplsInSegmentTSpecIndex." In this sentence "mplsTSpecMaxRate" should be 
>changed to
>"mplsTrafficParamMaxRate" etc. (I believe these names were changed in the 
>LSR MIB
>when going from version 02 to 03.)
>
>--
>Paul Langille                e-mail: langille@crescentnetworks.com
>Crescent Networks            phone: (978) 244-9002 x244
>201 Riverneck Road           fax: (978) 244-9211
>Chelmsford, MA 01824




From owner-mpls@UU.NET  Mon Aug 14 09:40:24 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07732
	for <mpls-archive@lists.ietf.org>; Mon, 14 Aug 2000 09:40:24 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcfe13091;
	Mon, 14 Aug 2000 13:40:04 GMT
Received: by mail-control.mail.uu.net 
	id QQjcfe03275
	for mpls-outgoing; Mon, 14 Aug 2000 13:39:43 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjcfe03268
	for <mpls@mail-control.mail.uu.net>; Mon, 14 Aug 2000 13:39:39 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjcfe20703
	for <mpls@uu.net>; Mon, 14 Aug 2000 09:39:22 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88])
	id QQjcfe12221
	for <mpls@uu.net>; Mon, 14 Aug 2000 13:39:06 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id GAA09361
	for <mpls@uu.net>; Mon, 14 Aug 2000 06:39:23 -0700 (PDT)
Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA26506 for mpls@uu.net; Mon, 14 Aug 2000 09:39:05 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjbuz17656
	for <mpls@mail-control.mail.uu.net>; Fri, 11 Aug 2000 19:21:50 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjbuz14712
	for <mpls@UU.NET>; Fri, 11 Aug 2000 15:21:45 -0400 (EDT)
Received: from thumper.research.telcordia.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: thumper.research.telcordia.com [128.96.41.1])
	id QQjbuz23842
	for <mpls@UU.NET>; Fri, 11 Aug 2000 19:21:27 GMT
Received: from tari.research.telcordia.com (tari [207.3.232.66])
	by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e7BJLBR11964;
	Fri, 11 Aug 2000 15:21:13 -0400 (EDT)
Received: from localhost ([207.122.4.194])
	by tari.research.telcordia.com (8.8.8/8.8.8) with SMTP id PAA18395;
	Fri, 11 Aug 2000 15:20:43 -0400 (EDT)
To: santoshg@daewoo.dti.daewoo.co.kr
Cc: mpls@UU.NET
Subject: Re: LDP - Path Vector TLV
In-Reply-To: <006d01c0005e$a9f05680$100d85a5@dti.daewoo.co.kr>
References: <006d01c0005e$a9f05680$100d85a5@dti.daewoo.co.kr>
X-Mailer: Mew version 1.94.1 on XEmacs 21.1 (Capitol Reef)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000811152121L.yohba@tari.toshiba.com>
Date: Fri, 11 Aug 2000 15:21:21 -0400
From: Yoshihiro Ohba <yohba@tari.toshiba.com>
X-Dispatcher: imput version 991025(IM133)
Lines: 41
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Santosh,

From: "Santosh Gupta" <santoshg@daewoo.dti.daewoo.co.kr>
Subject: LDP - Path Vector TLV
Date: Mon, 7 Aug 2000 16:30:10 +0530

> Hello
>     I have some doubts regarding Path Vector TLV in LDP. Could someone help me.
>   1.. Why do we need to have Path Vector TLV in Label Map Message? If we follow Downstream On demand Ordered Control Mode of Label Distribution then what could be the need for Path Vector TLV in Label Map Message. The same path was followed in Request Message. 

It is diffucult to explain all things briefly, but Path Vector TLV in
Label Mapping Message is needed for detecting loop without propagating
Label Request messages downstream beyond label merging node.

>   2.. The only use that I can think of Path Vector TLV in Label Map Message is when Egress LER didnt receive any Path Vector TLV/ Hop Count TLV so it sends back Label Map message so as to make sure that no loop is formed. 

No.  Propagating a Label Mapping Path Vector is independent from
whether the egress node received Label Request Path Vector.  In
addition, an egress node needs not include a Label Mapping Path
Vector.

>   3.. There are 2 ways in which an LSR could know it's HopCount. Either it receives a Label Request Message which carries it's previous Hop's "HopCount" or if it is 0 then the Label Map message ( which comes from DownStream peer ) will contain the "HopCount" once this LSP is formed till the Egress point. So is the LSR supposed to maintain 2 "HopCount" values for different directions? 

A node should maintain 2 hop count values for different directions.
Label Request Hop Count is used for detecting Label Request Message
looping especially for non-label-merging LSP.  Label Mapping Hop Count
is used for both detecting LSP loop and calculating TTL contained in
shim headers.

>   4.. How can each LSR know the no. of Hops in the LSP? Is it to be made from no. of entries in PathVector TLV when in Label Map message or their is some other means?

It depends on the case.  For example, if some nodes on the LSP are
configured to perform loop detection and others are not, Label Mapping
Path Vector does not provide exact information on the number of hops
in the LSP.  

Yoshihiro Ohba

> thanx in advance.
> 
> santosh



From owner-mpls@UU.NET  Tue Aug 15 11:23:05 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16828
	for <mpls-archive@lists.ietf.org>; Tue, 15 Aug 2000 11:23:05 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcjd04509;
	Tue, 15 Aug 2000 15:22:49 GMT
Received: by mail-control.mail.uu.net 
	id QQjcjd18282
	for mpls-outgoing; Tue, 15 Aug 2000 15:22:14 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjcjd18263
	for <mpls@mail-control.mail.uu.net>; Tue, 15 Aug 2000 15:22:06 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjcjd26997
	for <mpls@uu.net>; Tue, 15 Aug 2000 11:22:04 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjcjd09423
	for <mpls@uu.net>; Tue, 15 Aug 2000 15:21:49 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA17452
	for mpls@uu.net; Tue, 15 Aug 2000 11:21:48 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjcil00319
	for <mpls@mail-control.mail.uu.net>; Tue, 15 Aug 2000 10:52:36 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjcil16817
	for <mpls@uu.net>; Tue, 15 Aug 2000 06:52:21 -0400 (EDT)
Received: from ietf.org by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: odin.ietf.org [132.151.1.176])
	id QQjcil27377
	for <mpls@uu.net>; Tue, 15 Aug 2000 10:52:20 GMT
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10502;
	Tue, 15 Aug 2000 06:52:19 -0400 (EDT)
Message-Id: <200008151052.GAA10502@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;
Cc: mpls@UU.NET
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mpls-diff-ext-07.txt
Date: Tue, 15 Aug 2000 06:52:19 -0400
Sender: owner-mpls@UU.NET
Precedence: bulk

--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		: MPLS Support of Differentiated Services
	Author(s)	: F. Le Faucheur, L. Wu, B. Davie, S. Davari, 
                          P. Vaananen, R. Krishnan, P. Cheval, J. Heinanen
	Filename	: draft-ietf-mpls-diff-ext-07.txt
	Pages		: 53
	Date		: 14-Aug-00
	
This document defines a flexible solution for support of
Differentiated Services (Diff-Serv) over Multi-Protocol Label
Switching (MPLS) networks.
This solution allows the MPLS network administrator to select how
Diff-Serv Behavior Aggregates (BAs) are mapped onto Label Switched
Paths (LSPs) so that he/she can best match the Diff-Serv, Traffic
Engineering and protection objectives within his/her particular
network. For instance, this solution allows the network
administrator to decide whether different sets of BAs are to be
mapped onto the same LSP or mapped onto separate LSPs.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-diff-ext-07.txt

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-diff-ext-07.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mpls-diff-ext-07.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20000814114550.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mpls-diff-ext-07.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mpls-diff-ext-07.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000814114550.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-mpls@UU.NET  Tue Aug 15 11:24:00 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16859
	for <mpls-archive@lists.ietf.org>; Tue, 15 Aug 2000 11:23:59 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcjd10915;
	Tue, 15 Aug 2000 15:23:37 GMT
Received: by mail-control.mail.uu.net 
	id QQjcjd18514
	for mpls-outgoing; Tue, 15 Aug 2000 15:23:16 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjcjd18500
	for <mpls@mail-control.mail.uu.net>; Tue, 15 Aug 2000 15:23:07 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjcjd27171
	for <mpls@uu.net>; Tue, 15 Aug 2000 11:22:55 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjcjd10131
	for <mpls@uu.net>; Tue, 15 Aug 2000 15:22:39 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA17609
	for mpls@uu.net; Tue, 15 Aug 2000 11:22:39 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjcis00025
	for <mpls@mail-control.mail.uu.net>; Tue, 15 Aug 2000 12:38:52 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjcis28458
	for <mpls@UU.NET>; Tue, 15 Aug 2000 08:38:43 -0400 (EDT)
Received: from picard.noroff.no by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [212.20.204.3])
	id QQjcis01637
	for <mpls@UU.NET>; Tue, 15 Aug 2000 12:38:20 GMT
Received: by picard.noroff.no (Postfix, from userid 815)
	id 81E742201F; Tue, 15 Aug 2000 15:23:04 +0200 (CEST)
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177])
	by picard.noroff.no (Postfix) with ESMTP id D02F3B3802
	for <magg@NOROFF.NO>; Tue, 15 Aug 2000 15:23:01 +0200 (CEST)
Received: (from adm@localhost)
	by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA22745
	for ietf-123-outbound.09@ietf.org; Tue, 15 Aug 2000 07:45:02 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])
	by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA22414
	for <all-ietf@loki.ietf.org>; Tue, 15 Aug 2000 06:52:20 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10502;
	Tue, 15 Aug 2000 06:52:19 -0400 (EDT)
Message-Id: <200008151052.GAA10502@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;
Cc: mpls@UU.NET
From: Internet-Drafts@ietf.org
Reply-To: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mpls-diff-ext-07.txt
Date: Tue, 15 Aug 2000 06:52:19 -0400
X-AntiVirus: scanned for viruses by Amavis 0.2.1-pre2
Sender: owner-mpls@UU.NET
Precedence: bulk

--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		: MPLS Support of Differentiated Services
	Author(s)	: F. Le Faucheur, L. Wu, B. Davie, S. Davari, 
                          P. Vaananen, R. Krishnan, P. Cheval, J. Heinanen
	Filename	: draft-ietf-mpls-diff-ext-07.txt
	Pages		: 53
	Date		: 14-Aug-00
	
This document defines a flexible solution for support of
Differentiated Services (Diff-Serv) over Multi-Protocol Label
Switching (MPLS) networks.
This solution allows the MPLS network administrator to select how
Diff-Serv Behavior Aggregates (BAs) are mapped onto Label Switched
Paths (LSPs) so that he/she can best match the Diff-Serv, Traffic
Engineering and protection objectives within his/her particular
network. For instance, this solution allows the network
administrator to decide whether different sets of BAs are to be
mapped onto the same LSP or mapped onto separate LSPs.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-diff-ext-07.txt

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-diff-ext-07.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mpls-diff-ext-07.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20000814114550.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mpls-diff-ext-07.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mpls-diff-ext-07.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000814114550.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-mpls@UU.NET  Wed Aug 16 06:51:58 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21646
	for <mpls-archive@lists.ietf.org>; Wed, 16 Aug 2000 06:51:57 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcmd06851;
	Wed, 16 Aug 2000 10:51:31 GMT
Received: by mail-control.mail.uu.net 
	id QQjcmd21837
	for mpls-outgoing; Wed, 16 Aug 2000 10:51:12 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjcmd21750
	for <mpls@mail-control.mail.uu.net>; Wed, 16 Aug 2000 10:50:56 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjcmd17224
	for <mpls@uu.net>; Wed, 16 Aug 2000 06:50:35 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjcmd06144
	for <mpls@uu.net>; Wed, 16 Aug 2000 10:50:34 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA01588
	for mpls@uu.net; Wed, 16 Aug 2000 06:50:34 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjcmd21715
	for <mpls@mail-control.mail.uu.net>; Wed, 16 Aug 2000 10:49:58 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjcmd17048;
	Wed, 16 Aug 2000 06:49:41 -0400 (EDT)
Received: from ietf.org by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: odin.ietf.org [132.151.1.176])
	id QQjcmd05410;
	Wed, 16 Aug 2000 10:49:40 GMT
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21550;
	Wed, 16 Aug 2000 06:49:39 -0400 (EDT)
Message-Id: <200008161049.GAA21550@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;
CC: mpls@UU.NET, te-wg@UU.NET
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-venkatachalam-interarea-mpls-te-00.txt
Date: Wed, 16 Aug 2000 06:49:39 -0400
Sender: owner-mpls@UU.NET
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: A Framework for the LSP Setup Across IGP Areas for 
                          MPLS Traffic Engineering
	Author(s)	: S. Venkatachalam, S. Dharanikota
	Filename	: draft-venkatachalam-interarea-mpls-te-00.txt
	Pages		: 15
	Date		: 15-Aug-00
	
In this draft, we propose architecture for the inter-area LSP setup 
based on criteria (combination of constraints). We derive the
architectural requirements for the routing protocols, signaling
protocols and the MIBs to support such an idea. We also demonstrate
how such a mechanism will reduce the crankback during LSP setup.
A possible outline of the modifications to the CSPF algorithm and
examples are presented. In the companion document [INTER_AREA_EXT]
we elaborate on the extensions required for such architecture.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-venkatachalam-interarea-mpls-te-00.txt

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-venkatachalam-interarea-mpls-te-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-venkatachalam-interarea-mpls-te-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:	<20000815100315.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-venkatachalam-interarea-mpls-te-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-venkatachalam-interarea-mpls-te-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000815100315.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-mpls@UU.NET  Wed Aug 16 08:04:23 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22870
	for <mpls-archive@lists.ietf.org>; Wed, 16 Aug 2000 08:04:23 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcmi20878;
	Wed, 16 Aug 2000 12:03:43 GMT
Received: by mail-control.mail.uu.net 
	id QQjcmi19245
	for mpls-outgoing; Wed, 16 Aug 2000 12:03:12 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjcmi19227
	for <mpls@mail-control.mail.uu.net>; Wed, 16 Aug 2000 12:03:07 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjcmi24504
	for <mpls@uu.net>; Wed, 16 Aug 2000 08:02:16 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjcmi14768
	for <mpls@uu.net>; Wed, 16 Aug 2000 12:02:15 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id IAA05983
	for mpls@uu.net; Wed, 16 Aug 2000 08:02:15 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjcmi14530
	for <mpls@mail-control.mail.uu.net>; Wed, 16 Aug 2000 12:01:55 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjcmi24344;
	Wed, 16 Aug 2000 08:00:53 -0400 (EDT)
Received: from picard.noroff.no by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [212.20.204.3])
	id QQjcmi13895;
	Wed, 16 Aug 2000 12:00:51 GMT
Received: by picard.noroff.no (Postfix, from userid 815)
	id 7703B22003; Wed, 16 Aug 2000 14:45:40 +0200 (CEST)
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177])
	by picard.noroff.no (Postfix) with ESMTP id 3244DB3802
	for <magg@NOROFF.NO>; Wed, 16 Aug 2000 14:45:33 +0200 (CEST)
Received: (from adm@localhost)
	by loki.ietf.org (8.9.1b+Sun/8.9.1) id GAA26381
	for ietf-123-outbound.09@ietf.org; Wed, 16 Aug 2000 06:55:00 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])
	by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA26323
	for <all-ietf@loki.ietf.org>; Wed, 16 Aug 2000 06:49:39 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21550;
	Wed, 16 Aug 2000 06:49:39 -0400 (EDT)
Message-Id: <200008161049.GAA21550@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;
Cc: mpls@UU.NET, te-wg@UU.NET
From: Internet-Drafts@ietf.org
Reply-To: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-venkatachalam-interarea-mpls-te-00.txt
Date: Wed, 16 Aug 2000 06:49:39 -0400
X-AntiVirus: scanned for viruses by Amavis 0.2.1-pre2
Sender: owner-mpls@UU.NET
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: A Framework for the LSP Setup Across IGP Areas for 
                          MPLS Traffic Engineering
	Author(s)	: S. Venkatachalam, S. Dharanikota
	Filename	: draft-venkatachalam-interarea-mpls-te-00.txt
	Pages		: 15
	Date		: 15-Aug-00
	
In this draft, we propose architecture for the inter-area LSP setup 
based on criteria (combination of constraints). We derive the
architectural requirements for the routing protocols, signaling
protocols and the MIBs to support such an idea. We also demonstrate
how such a mechanism will reduce the crankback during LSP setup.
A possible outline of the modifications to the CSPF algorithm and
examples are presented. In the companion document [INTER_AREA_EXT]
we elaborate on the extensions required for such architecture.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-venkatachalam-interarea-mpls-te-00.txt

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-venkatachalam-interarea-mpls-te-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-venkatachalam-interarea-mpls-te-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:	<20000815100315.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-venkatachalam-interarea-mpls-te-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-venkatachalam-interarea-mpls-te-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000815100315.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-mpls@UU.NET  Wed Aug 16 08:55:35 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23752
	for <mpls-archive@lists.ietf.org>; Wed, 16 Aug 2000 08:55:34 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcml18629;
	Wed, 16 Aug 2000 12:55:07 GMT
Received: by mail-control.mail.uu.net 
	id QQjcml22870
	for mpls-outgoing; Wed, 16 Aug 2000 12:54:34 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjcml22864
	for <mpls@mail-control.mail.uu.net>; Wed, 16 Aug 2000 12:54:30 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjcml01360
	for <mpls@uu.net>; Wed, 16 Aug 2000 08:54:19 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjcml18073
	for <mpls@uu.net>; Wed, 16 Aug 2000 12:54:18 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id IAA10887
	for mpls@uu.net; Wed, 16 Aug 2000 08:54:18 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjcml22841
	for <mpls@mail-control.mail.uu.net>; Wed, 16 Aug 2000 12:53:54 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjcml01309;
	Wed, 16 Aug 2000 08:53:48 -0400 (EDT)
From: Spencer.Giacalone@predictive.com
Received: from athena.predictive.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: athena.predictive.com [208.209.197.197])
	id QQjcml23215;
	Wed, 16 Aug 2000 12:53:33 GMT
To: te-wg@UU.NET, mpls@UU.NET, ospf.discuss@microsoft.com
Subject: New ID- SFMC
X-Mailer: Lotus Notes Release 5.0.2c (Intl) 2 February 2000
Message-ID: <OFD541AB99.B86A3E7E-ON8525693D.0045A85C@predictive.com>
Date: Wed, 16 Aug 2000 08:55:23 -0400
X-MIMETrack: Serialize by Router on Athena/Predictive(Release 5.0.4a |July 24, 2000) at
 08/16/2000 08:55:26 AM,
	Serialize complete at 08/16/2000 08:55:26 AM
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-mpls@UU.NET
Precedence: bulk

I just wanted to let you know that a new ID has been posted, entitled 
Scored Fair Metric Calculation. The intent of the draft is to present 
unified homogeneous metrics to routing protocols which are based on sets 
of heterogeneous metrics. SFMC allows forwarding selection to be based on 
paths that support the best mix of best metrics. More detail follows. Note 
that although the ID talks to interoperation with OSPF, (in a section 
dedicated to that) that section will be extensively revised. 

The URL is 
http://www.ietf.org/internet-drafts/draft-giacalone-scored-fair-metric-routing-00.txt

-Spence

Abstract

   This memo defines a modular metric calculation system termed Scored
   Fair Metric Calculation (SFMC). SFMC can be integrated with Link
   State and Distance Vector routing protocols and their extensions
   [1,4,5,6,7], enabling them to find network paths that support the
   highest possible number of best metrics across a network. SFMC makes
   it possible to support and mix large sets of heterogeneous network
   features and capabilities.

   SFMC solves many of the issues inherent in routing protocols that
   attempt to use complex sets of metrics by decoupling raw metric data
   from the input side of routing protocols. Unlike the past, SFMC
   regards all metrics all the time, while treating all metrics equally
   (by default).

   Additionally, the SFMC architecture provides a simple and flexible
   interface for extensive manipulation of path selection.

   Please send comments to ospf@discuss.microsoft.com.



From owner-mpls@UU.NET  Wed Aug 16 11:08:43 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27350
	for <mpls-archive@lists.ietf.org>; Wed, 16 Aug 2000 11:08:43 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcmu27613;
	Wed, 16 Aug 2000 15:07:11 GMT
Received: by mail-control.mail.uu.net 
	id QQjcmu08538
	for mpls-outgoing; Wed, 16 Aug 2000 15:06:37 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjcmu08478
	for <mpls@mail-control.mail.uu.net>; Wed, 16 Aug 2000 15:06:18 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjcmu13020
	for <mpls@uu.net>; Wed, 16 Aug 2000 11:06:11 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11])
	id QQjcmu26737
	for <mpls@uu.net>; Wed, 16 Aug 2000 15:06:11 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA18721
	for <mpls@uu.net>; Wed, 16 Aug 2000 08:06:27 -0700 (PDT)
Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id LAA05076 for mpls@uu.net; Wed, 16 Aug 2000 11:06:09 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjcmu00812
	for <mpls@mail-control.mail.uu.net>; Wed, 16 Aug 2000 15:02:02 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjcmu12232
	for <mpls@uu.net>; Wed, 16 Aug 2000 11:01:53 -0400 (EDT)
Received: from xover.hjinc.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [38.160.241.130])
	id QQjcmu23202
	for <mpls@uu.net>; Wed, 16 Aug 2000 15:01:12 GMT
Received: by xover.hjinc.com with Internet Mail Service (5.5.2650.21)
	id <QQ74Y2NX>; Wed, 16 Aug 2000 10:57:03 -0400
Message-ID: <7BF58A904536D411ADD400508BC97B85046BB6@xover1.netplane.com>
From: "Kullberg, Alan" <akullber@netplane.com>
To: "MPLS_WG (E-mail)" <mpls@UU.NET>
Subject: generalized MPLS signaling question
Date: Wed, 16 Aug 2000 10:57:19 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

I have a question regarding the generalized MPLS signaling draft.


     A                   B
      \                 /
       \               /
        1------2------3

In the above picture, LSRs A and B are at the edges of an optical
network, and LSRs 1, 2, and 3 are optical switches.  LSR-A has
previously setup 2 Lambda LSPs to LSR-B.  LSR-A then wants to
"label stack" on one of those Lambdas to LSR-B by requesting a
timeslot from one of the Lambda LSPs.  When LSR-A sends a
REQUEST/PATH message to LSR-B, how do LSR-A and LSR-B coordinate
the timeslot allocation so that LSR-A sends the data in the
timeslot on the correct Lambda?  Assume that signaling occurs
out of band.

It seems that LSR-A needs to send some indication to LSR-B, like
the 6-octet LSPID of the corresponding Lambda LSP, so that LSR-B
allocates a timeslot from the correct Lambda.

Thanks,

Alan



From owner-mpls@UU.NET  Wed Aug 16 12:17:57 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29295
	for <mpls-archive@lists.ietf.org>; Wed, 16 Aug 2000 12:17:56 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcmz00058;
	Wed, 16 Aug 2000 16:17:13 GMT
Received: by mail-control.mail.uu.net 
	id QQjcmz28403
	for mpls-outgoing; Wed, 16 Aug 2000 16:16:53 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjcmz28398
	for <mpls@mail-control.mail.uu.net>; Wed, 16 Aug 2000 16:16:47 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjcmz27095
	for <mpls@UU.NET>; Wed, 16 Aug 2000 12:16:41 -0400 (EDT)
Received: from red.juniper.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: natint.juniper.net [207.17.136.129])
	id QQjcmz20400
	for <mpls@UU.NET>; Wed, 16 Aug 2000 16:16:24 GMT
Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90])
	by red.juniper.net (8.9.3/8.9.3) with ESMTP id JAA28460;
	Wed, 16 Aug 2000 09:16:20 -0700 (PDT)
Received: (from kireeti@localhost) by kummer.juniper.net (8.8.7/8.7.3) id JAA00198; Wed, 16 Aug 2000 09:15:55 -0700 (PDT)
Date: Wed, 16 Aug 2000 09:15:55 -0700 (PDT)
From: Kireeti Kompella <kireeti@juniper.net>
Message-Id: <200008161615.JAA00198@kummer.juniper.net>
To: akullber@netplane.com, mpls@UU.NET
Subject: Re: generalized MPLS signaling question
Sender: owner-mpls@UU.NET
Precedence: bulk

> how do LSR-A and LSR-B coordinate
> the timeslot allocation so that LSR-A sends the data in the
> timeslot on the correct Lambda?

Using the ERO.  Each lambda (actually, lambda-switched path) is
uniquely identified, either by an IP address or by an "interface"
index as defined in the unnumbered draft.

Kireeti.


From owner-mpls@UU.NET  Wed Aug 16 12:51:39 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29976
	for <mpls-archive@lists.ietf.org>; Wed, 16 Aug 2000 12:51:39 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcnb14004;
	Wed, 16 Aug 2000 16:50:26 GMT
Received: by mail-control.mail.uu.net 
	id QQjcnb29725
	for mpls-outgoing; Wed, 16 Aug 2000 16:49:51 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjcnb29714
	for <mpls@mail-control.mail.uu.net>; Wed, 16 Aug 2000 16:49:39 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjcnb15160
	for <mpls@UU.NET>; Wed, 16 Aug 2000 12:49:22 -0400 (EDT)
Received: from icarian.ZAFFIRE.COM by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ATHM-64-232-xxx-132.home.net [64.232.69.132] (may be forged))
	id QQjcnb13102
	for <mpls@UU.NET>; Wed, 16 Aug 2000 16:49:21 GMT
Received: by ICARIAN with Internet Mail Service (5.5.2650.21)
	id <QX14Y0PV>; Wed, 16 Aug 2000 09:57:14 -0700
Message-ID: <4D3F9F2BEC58D4118FCE009027B0A66213612A@ICARIAN>
From: Eric Gray <EGray@zaffire.com>
To: "'Kireeti Kompella'" <kireeti@juniper.net>
Cc: Eric Gray <EGray@zaffire.com>, mpls@UU.NET, akullber@netplane.com
Subject: RE: generalized MPLS signaling question
Date: Wed, 16 Aug 2000 09:57:13 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Kireeti,

	Hi.

	I'm afraid that this doesn't help, too much,
in understanding how this might be done.  For one
thing, if the interface ID sub-object type you've
defined in the unnumbered draft (I am assuming you
refer to draft-kompella-mpls-unnum-00) is intended
to be used to identify LSPs, then it should maybe
have been defined as a larger than 16-bit field.
Since LSPs may be extended to large numbers of 
LSRs either directly or indirectly connected, the
number of interface IDs needed may be arbitrarily 
large.

	For another, there's an issue with how an LSR
might interpret an IPv4 prefix in an ERO when there
are multiple routes to that prefix - including one
or more that traverse an LSP.  In fact, there is 
nothing to prevent having more than one LSP at any
LSR that extends toward an IPv4 prefix, is there?   
And, although it may make sense to use an LSP that 
directly connects the current LSR to a remote next 
hop associated with the IPv4 prefix specified in an 
ERO, if you cannot explicitly identify the LSP, the 
local routing engine may decide to use another route.  
This would appear to defeat the purpose of using the 
ERO.

	So, I guess the question comes down to "is there
a reason why a user might want to force the path to
follow a particular LSP even when routing would prefer
a different path?"  I think the answer is yes, using
Alan's specific example as a case in point, so the
next question is - "how do we force this behavior?"

	In CR-LDP, there is an explicit LSPID Hop type.
Perhaps there should be a "Session" sub-object for 
RSVP-TE?

	Thanks!

> -----Original Message-----
> From: Kireeti Kompella [mailto:kireeti@juniper.net]
> Sent: Wednesday, August 16, 2000 9:16 AM
> To: akullber@netplane.com; mpls@UU.NET
> Subject: Re: generalized MPLS signaling question
> 
> 
> > how do LSR-A and LSR-B coordinate
> > the timeslot allocation so that LSR-A sends the data in the
> > timeslot on the correct Lambda?
> 
> Using the ERO.  Each lambda (actually, lambda-switched path) is
> uniquely identified, either by an IP address or by an "interface"
> index as defined in the unnumbered draft.
> 
> Kireeti.
> 


From owner-mpls@UU.NET  Wed Aug 16 13:30:49 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00581
	for <mpls-archive@lists.ietf.org>; Wed, 16 Aug 2000 13:30:49 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcne12410;
	Wed, 16 Aug 2000 17:30:08 GMT
Received: by mail-control.mail.uu.net 
	id QQjcnd13960
	for mpls-outgoing; Wed, 16 Aug 2000 17:29:34 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjcnd13953
	for <mpls@mail-control.mail.uu.net>; Wed, 16 Aug 2000 17:29:17 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjcnd21644
	for <mpls@UU.NET>; Wed, 16 Aug 2000 13:29:12 -0400 (EDT)
Received: from mailrelay.laurelnetworks.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: laurelnetworks.com [206.67.234.84])
	id QQjcnd11123
	for <mpls@UU.NET>; Wed, 16 Aug 2000 17:28:42 GMT
Received: from localhost.laurelnetworks.com (IDENT:root@jleu-laptop.laurelnetworks.com [192.168.0.110])
	by mailrelay.laurelnetworks.com (8.9.3/8.9.3) with ESMTP id NAA10908;
	Wed, 16 Aug 2000 13:28:39 -0400
Received: (from jleu@localhost)
	by localhost.laurelnetworks.com (8.9.3/8.9.3) id NAA01409;
	Wed, 16 Aug 2000 13:28:38 -0400
Date: Wed, 16 Aug 2000 13:28:38 -0400
From: "James R. Leu" <jleu@laurelnetworks.com>
To: Eric Gray <EGray@zaffire.com>
Cc: "'Kireeti Kompella'" <kireeti@juniper.net>, mpls@UU.NET,
        akullber@netplane.com
Subject: Re: generalized MPLS signaling question
Message-ID: <20000816132838.A874@laurelnetworks.com>
Reply-To: jleu@laurelnetworks.com
References: <4D3F9F2BEC58D4118FCE009027B0A66213612A@ICARIAN>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <4D3F9F2BEC58D4118FCE009027B0A66213612A@ICARIAN>; from EGray@zaffire.com on Wed, Aug 16, 2000 at 09:57:13AM -0700
Organization: Laurel Networks
Sender: owner-mpls@UU.NET
Precedence: bulk

I agree with Eric.

Not only would this provide a means to clearly indicate that the resulting
LSP should utilize (tunnel through) and existing LSP.  It would also align
RSVP-TE, CR-LDP, and the TE-MIB with respect to EROs.

Jim
-- 
James R. Leu
Software Engineer
Laurel Networks, Inc
jleu@laurelnetworks.com

On Wed, Aug 16, 2000 at 09:57:13AM -0700, Eric Gray wrote:
> Kireeti,
> 
> 	Hi.
> 
> 	I'm afraid that this doesn't help, too much,
> in understanding how this might be done.  For one
> thing, if the interface ID sub-object type you've
> defined in the unnumbered draft (I am assuming you
> refer to draft-kompella-mpls-unnum-00) is intended
> to be used to identify LSPs, then it should maybe
> have been defined as a larger than 16-bit field.
> Since LSPs may be extended to large numbers of 
> LSRs either directly or indirectly connected, the
> number of interface IDs needed may be arbitrarily 
> large.
> 
> 	For another, there's an issue with how an LSR
> might interpret an IPv4 prefix in an ERO when there
> are multiple routes to that prefix - including one
> or more that traverse an LSP.  In fact, there is 
> nothing to prevent having more than one LSP at any
> LSR that extends toward an IPv4 prefix, is there?   
> And, although it may make sense to use an LSP that 
> directly connects the current LSR to a remote next 
> hop associated with the IPv4 prefix specified in an 
> ERO, if you cannot explicitly identify the LSP, the 
> local routing engine may decide to use another route.  
> This would appear to defeat the purpose of using the 
> ERO.
> 
> 	So, I guess the question comes down to "is there
> a reason why a user might want to force the path to
> follow a particular LSP even when routing would prefer
> a different path?"  I think the answer is yes, using
> Alan's specific example as a case in point, so the
> next question is - "how do we force this behavior?"
> 
> 	In CR-LDP, there is an explicit LSPID Hop type.
> Perhaps there should be a "Session" sub-object for 
> RSVP-TE?
> 
> 	Thanks!
> 
> > -----Original Message-----
> > From: Kireeti Kompella [mailto:kireeti@juniper.net]
> > Sent: Wednesday, August 16, 2000 9:16 AM
> > To: akullber@netplane.com; mpls@UU.NET
> > Subject: Re: generalized MPLS signaling question
> > 
> > 
> > > how do LSR-A and LSR-B coordinate
> > > the timeslot allocation so that LSR-A sends the data in the
> > > timeslot on the correct Lambda?
> > 
> > Using the ERO.  Each lambda (actually, lambda-switched path) is
> > uniquely identified, either by an IP address or by an "interface"
> > index as defined in the unnumbered draft.
> > 
> > Kireeti.
> > 



From owner-mpls@UU.NET  Wed Aug 16 14:01:53 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01209
	for <mpls-archive@lists.ietf.org>; Wed, 16 Aug 2000 14:01:53 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcng07020;
	Wed, 16 Aug 2000 18:01:14 GMT
Received: by mail-control.mail.uu.net 
	id QQjcng18097
	for mpls-outgoing; Wed, 16 Aug 2000 18:00:35 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjcng18068
	for <mpls@mail-control.mail.uu.net>; Wed, 16 Aug 2000 18:00:34 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjcng27608
	for <mpls@uu.net>; Wed, 16 Aug 2000 14:00:26 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88])
	id QQjcng06378
	for <mpls@uu.net>; Wed, 16 Aug 2000 18:00:25 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id LAA18798
	for <mpls@uu.net>; Wed, 16 Aug 2000 11:00:42 -0700 (PDT)
Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id OAA05701 for mpls@uu.net; Wed, 16 Aug 2000 14:00:22 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjcnf15062
	for <mpls@mail-control.mail.uu.net>; Wed, 16 Aug 2000 17:46:38 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjcnf24797
	for <mpls@UU.NET>; Wed, 16 Aug 2000 13:46:22 -0400 (EDT)
Received: from xover.hjinc.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [38.160.241.130])
	id QQjcnf05561
	for <mpls@UU.NET>; Wed, 16 Aug 2000 17:46:20 GMT
Received: by xover.hjinc.com with Internet Mail Service (5.5.2650.21)
	id <QQ74Y24P>; Wed, 16 Aug 2000 13:42:11 -0400
Message-ID: <7BF58A904536D411ADD400508BC97B85046BB7@xover1.netplane.com>
From: "Kullberg, Alan" <akullber@netplane.com>
To: "'Eric Gray'" <EGray@zaffire.com>,
        "'Kireeti Kompella'"
	 <kireeti@juniper.net>
Cc: mpls@UU.NET
Subject: RE: generalized MPLS signaling question
Date: Wed, 16 Aug 2000 13:42:26 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Eric,

Unfortunately, the LSPID ER Hop type from CR-LDP doesn't
help in this case because the LSPID ER Hop is removed
before sending the REQUEST message.  See 4.7.4/crldp-03.

Alan

> -----Original Message-----
> From: Eric Gray [mailto:EGray@zaffire.com]
> Sent: Wednesday, August 16, 2000 12:57 PM
> To: 'Kireeti Kompella'
> Cc: Eric Gray; mpls@UU.NET; akullber@netplane.com
> Subject: RE: generalized MPLS signaling question
> 
> 
> Kireeti,
> 
> 	Hi.
> 
> 	I'm afraid that this doesn't help, too much,
> in understanding how this might be done.  For one
> thing, if the interface ID sub-object type you've
> defined in the unnumbered draft (I am assuming you
> refer to draft-kompella-mpls-unnum-00) is intended
> to be used to identify LSPs, then it should maybe
> have been defined as a larger than 16-bit field.
> Since LSPs may be extended to large numbers of 
> LSRs either directly or indirectly connected, the
> number of interface IDs needed may be arbitrarily 
> large.
> 
> 	For another, there's an issue with how an LSR
> might interpret an IPv4 prefix in an ERO when there
> are multiple routes to that prefix - including one
> or more that traverse an LSP.  In fact, there is 
> nothing to prevent having more than one LSP at any
> LSR that extends toward an IPv4 prefix, is there?   
> And, although it may make sense to use an LSP that 
> directly connects the current LSR to a remote next 
> hop associated with the IPv4 prefix specified in an 
> ERO, if you cannot explicitly identify the LSP, the 
> local routing engine may decide to use another route.  
> This would appear to defeat the purpose of using the 
> ERO.
> 
> 	So, I guess the question comes down to "is there
> a reason why a user might want to force the path to
> follow a particular LSP even when routing would prefer
> a different path?"  I think the answer is yes, using
> Alan's specific example as a case in point, so the
> next question is - "how do we force this behavior?"
> 
> 	In CR-LDP, there is an explicit LSPID Hop type.
> Perhaps there should be a "Session" sub-object for 
> RSVP-TE?
> 
> 	Thanks!
> 
> > -----Original Message-----
> > From: Kireeti Kompella [mailto:kireeti@juniper.net]
> > Sent: Wednesday, August 16, 2000 9:16 AM
> > To: akullber@netplane.com; mpls@UU.NET
> > Subject: Re: generalized MPLS signaling question
> > 
> > 
> > > how do LSR-A and LSR-B coordinate
> > > the timeslot allocation so that LSR-A sends the data in the
> > > timeslot on the correct Lambda?
> > 
> > Using the ERO.  Each lambda (actually, lambda-switched path) is
> > uniquely identified, either by an IP address or by an "interface"
> > index as defined in the unnumbered draft.
> > 
> > Kireeti.
> > 
> 



From owner-mpls@UU.NET  Wed Aug 16 14:08:12 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01314
	for <mpls-archive@lists.ietf.org>; Wed, 16 Aug 2000 14:08:12 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcng21008;
	Wed, 16 Aug 2000 18:07:27 GMT
Received: by mail-control.mail.uu.net 
	id QQjcng28097
	for mpls-outgoing; Wed, 16 Aug 2000 18:06:46 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjcng28085
	for <mpls@mail-control.mail.uu.net>; Wed, 16 Aug 2000 18:06:39 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjcng28613
	for <mpls@UU.NET>; Wed, 16 Aug 2000 14:06:27 -0400 (EDT)
Received: from icarian.ZAFFIRE.COM by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ATHM-64-232-xxx-132.home.net [64.232.69.132] (may be forged))
	id QQjcng19920
	for <mpls@UU.NET>; Wed, 16 Aug 2000 18:06:11 GMT
Received: by ICARIAN with Internet Mail Service (5.5.2650.21)
	id <QX14ZAGZ>; Wed, 16 Aug 2000 11:14:07 -0700
Message-ID: <4D3F9F2BEC58D4118FCE009027B0A66213612E@ICARIAN>
From: Eric Gray <EGray@zaffire.com>
To: "'Alan Kullberg'" <akullber@netplane.com>,
        "'Kireeti Kompella'"
	 <kireeti@juniper.net>
Cc: mpls@UU.NET, Eric Gray <EGray@zaffire.com>
Subject: RE: generalized MPLS signaling question
Date: Wed, 16 Aug 2000 11:14:06 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Alan,

	Been a while (one or two weeks) since I looked
at that.  Possibly there is some ambiguity (I am not
trying to say that CR-LDP has the answer), but the
next phrase (fter the one that says you have to lose
the LSP-ID Hop) says that you forward the Request
message on a session associated with that (CR-)LSP.
This makes it considerably less ambiguous than if -
say - you forward a signaling message based on a 
routing look-up for the IPv4 prefix specified as the
next ER Hop in the ERO.

	I believe that what Kireeti suggest will work
in many implementations since - as he says - the IP
address uniquely identifies the LSP.  However, it is
an IP address and therefore likely to match a route
table entry.  If the implementation injects the IP
address of the LSP as a host route into the routing
table (I don't recall if this behavior is specified),
then the LSP will be the longest match.  Then, as
long as there are not two host routes to that same IP 
address, there should be no ambiguity.

	But this fits snugly under the heading of a "neat
trick" and it would be clearer and less likely to cause
trouble down the road if some mechanism were used to
specify an LSP explicitly.

> -----Original Message-----
> From: Kullberg, Alan [mailto:akullber@netplane.com]
> Sent: Wednesday, August 16, 2000 10:42 AM
> To: 'Eric Gray'; 'Kireeti Kompella'
> Cc: mpls@UU.NET
> Subject: RE: generalized MPLS signaling question
> 
> 
> Eric,
> 
> Unfortunately, the LSPID ER Hop type from CR-LDP doesn't
> help in this case because the LSPID ER Hop is removed
> before sending the REQUEST message.  See 4.7.4/crldp-03.
> 
> Alan
> 
> > -----Original Message-----
> > From: Eric Gray [mailto:EGray@zaffire.com]
> > Sent: Wednesday, August 16, 2000 12:57 PM
> > To: 'Kireeti Kompella'
> > Cc: Eric Gray; mpls@UU.NET; akullber@netplane.com
> > Subject: RE: generalized MPLS signaling question
> > 
> > 
> > Kireeti,
> > 
> > 	Hi.
> > 
> > 	I'm afraid that this doesn't help, too much,
> > in understanding how this might be done.  For one
> > thing, if the interface ID sub-object type you've
> > defined in the unnumbered draft (I am assuming you
> > refer to draft-kompella-mpls-unnum-00) is intended
> > to be used to identify LSPs, then it should maybe
> > have been defined as a larger than 16-bit field.
> > Since LSPs may be extended to large numbers of 
> > LSRs either directly or indirectly connected, the
> > number of interface IDs needed may be arbitrarily 
> > large.
> > 
> > 	For another, there's an issue with how an LSR
> > might interpret an IPv4 prefix in an ERO when there
> > are multiple routes to that prefix - including one
> > or more that traverse an LSP.  In fact, there is 
> > nothing to prevent having more than one LSP at any
> > LSR that extends toward an IPv4 prefix, is there?   
> > And, although it may make sense to use an LSP that 
> > directly connects the current LSR to a remote next 
> > hop associated with the IPv4 prefix specified in an 
> > ERO, if you cannot explicitly identify the LSP, the 
> > local routing engine may decide to use another route.  
> > This would appear to defeat the purpose of using the 
> > ERO.
> > 
> > 	So, I guess the question comes down to "is there
> > a reason why a user might want to force the path to
> > follow a particular LSP even when routing would prefer
> > a different path?"  I think the answer is yes, using
> > Alan's specific example as a case in point, so the
> > next question is - "how do we force this behavior?"
> > 
> > 	In CR-LDP, there is an explicit LSPID Hop type.
> > Perhaps there should be a "Session" sub-object for 
> > RSVP-TE?
> > 
> > 	Thanks!
> > 
> > > -----Original Message-----
> > > From: Kireeti Kompella [mailto:kireeti@juniper.net]
> > > Sent: Wednesday, August 16, 2000 9:16 AM
> > > To: akullber@netplane.com; mpls@UU.NET
> > > Subject: Re: generalized MPLS signaling question
> > > 
> > > 
> > > > how do LSR-A and LSR-B coordinate
> > > > the timeslot allocation so that LSR-A sends the data in the
> > > > timeslot on the correct Lambda?
> > > 
> > > Using the ERO.  Each lambda (actually, lambda-switched path) is
> > > uniquely identified, either by an IP address or by an "interface"
> > > index as defined in the unnumbered draft.
> > > 
> > > Kireeti.
> > > 
> > 
> 


From owner-mpls@UU.NET  Wed Aug 16 14:10:08 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01338
	for <mpls-archive@lists.ietf.org>; Wed, 16 Aug 2000 14:10:07 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcng22813;
	Wed, 16 Aug 2000 18:09:31 GMT
Received: by mail-control.mail.uu.net 
	id QQjcng28333
	for mpls-outgoing; Wed, 16 Aug 2000 18:08:42 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjcng28301
	for <mpls@mail-control.mail.uu.net>; Wed, 16 Aug 2000 18:08:31 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjcng17002
	for <mpls@UU.NET>; Wed, 16 Aug 2000 14:08:17 -0400 (EDT)
Received: from red.juniper.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: natint.juniper.net [207.17.136.129])
	id QQjcng21225
	for <mpls@UU.NET>; Wed, 16 Aug 2000 18:07:38 GMT
Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90])
	by red.juniper.net (8.9.3/8.9.3) with ESMTP id LAA09228;
	Wed, 16 Aug 2000 11:07:33 -0700 (PDT)
Received: (from kireeti@localhost) by kummer.juniper.net (8.8.7/8.7.3) id LAA00606; Wed, 16 Aug 2000 11:07:08 -0700 (PDT)
Date: Wed, 16 Aug 2000 11:07:08 -0700 (PDT)
From: Kireeti Kompella <kireeti@juniper.net>
Message-Id: <200008161807.LAA00606@kummer.juniper.net>
To: EGray@zaffire.com, kireeti@juniper.net
Subject: RE: generalized MPLS signaling question
Cc: akullber@netplane.com, mpls@UU.NET
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Eric,

> 	I'm afraid that this doesn't help, too much,
> in understanding how this might be done.  For one
> thing, if the interface ID sub-object type you've
> defined in the unnumbered draft (I am assuming you
> refer to draft-kompella-mpls-unnum-00) is intended
> to be used to identify LSPs, then it should maybe
> have been defined as a larger than 16-bit field.

Yes, that's the draft.  If you really think that 65536 is
too small, it's easy enough to make this a 24-bit number.

> 	For another, there's an issue with how an LSR
> might interpret an IPv4 prefix in an ERO when there
> are multiple routes to that prefix - including one
> or more that traverse an LSP.  In fact, there is 
> nothing to prevent having more than one LSP at any
> LSR that extends toward an IPv4 prefix, is there?   

That applies as is to interfaces.  One could have several
interfaces and/or LSPs identically numbered between two
routers.  The fact that they are identically numbered means
you don't care which one is used.  With in-band signalling,
there is no issue; with out-of-band signalling, you'd need
to bundle the links, and use the Link ID so both ends agree
on which link to use.

> 	So, I guess the question comes down to "is there
> a reason why a user might want to force the path to
> follow a particular LSP even when routing would prefer
> a different path?"  I think the answer is yes.

I agree completely that choosing a path is necessary.
a) Number the interfaces and LSPs distinctly; or
b) Run unnumbered
to force the path the way you choose.  Or

c) Bundle the interfaces and LSPs, and use the Link ID
to make both ends use consistent links.

These approaches work for both interfaces and LSPs.  A
session ID mechanism only works for LSPs; also, it isn't
enough to extend RSVP EROs to include session IDs, you also
need to carry the session ID in the IGP to be able to compute
the paths you want to force (options a and b).

Question: what does a session ID offer that can't be done
with an "interface index"?

Kireeti.


From owner-mpls@UU.NET  Wed Aug 16 14:43:27 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01936
	for <mpls-archive@lists.ietf.org>; Wed, 16 Aug 2000 14:43:27 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcni17603;
	Wed, 16 Aug 2000 18:42:10 GMT
Received: by mail-control.mail.uu.net 
	id QQjcni02239
	for mpls-outgoing; Wed, 16 Aug 2000 18:41:46 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjcni02205
	for <mpls@mail-control.mail.uu.net>; Wed, 16 Aug 2000 18:41:30 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjcni23361
	for <mpls@UU.NET>; Wed, 16 Aug 2000 14:41:10 -0400 (EDT)
Received: from icarian.ZAFFIRE.COM by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ATHM-64-232-xxx-132.home.net [64.232.69.132] (may be forged))
	id QQjcni06530
	for <mpls@UU.NET>; Wed, 16 Aug 2000 18:40:54 GMT
Received: by ICARIAN with Internet Mail Service (5.5.2650.21)
	id <QX14ZA4R>; Wed, 16 Aug 2000 11:48:50 -0700
Message-ID: <4D3F9F2BEC58D4118FCE009027B0A662136131@ICARIAN>
From: Eric Gray <EGray@zaffire.com>
To: "'Kireeti Kompella'" <kireeti@juniper.net>,
        Eric Gray
	 <EGray@zaffire.com>
Cc: akullber@netplane.com, mpls@UU.NET
Subject: RE: generalized MPLS signaling question
Date: Wed, 16 Aug 2000 11:48:50 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Kireeti,

	Please see embedded comments, below.

> ... <snip> ...
> 
> Hi Eric,
> 
> > 	I'm afraid that this doesn't help, too much,
> > in understanding how this might be done.  For one
> > thing, if the interface ID sub-object type you've
> > defined in the unnumbered draft (I am assuming you
> > refer to draft-kompella-mpls-unnum-00) is intended
> > to be used to identify LSPs, then it should maybe
> > have been defined as a larger than 16-bit field.
> 
> Yes, that's the draft.  If you really think that 65536 is
> too small, it's easy enough to make this a 24-bit number.

I've participated in a number of discussions in which
the point was made that the IETF community has a long
standing tradition of under-shooting on estimating the
size of a number space needed.

> 
> > 	For another, there's an issue with how an LSR
> > might interpret an IPv4 prefix in an ERO when there
> > are multiple routes to that prefix - including one
> > or more that traverse an LSP.  In fact, there is 
> > nothing to prevent having more than one LSP at any
> > LSR that extends toward an IPv4 prefix, is there?   
> 
> That applies as is to interfaces.  One could have several
> interfaces and/or LSPs identically numbered between two
> routers.  The fact that they are identically numbered means
> you don't care which one is used.  With in-band signaling,
> there is no issue; with out-of-band signaling, you'd need
> to bundle the links, and use the Link ID so both ends agree
> on which link to use.

Yes, this makes sense.

> 
> > 	So, I guess the question comes down to "is there
> > a reason why a user might want to force the path to
> > follow a particular LSP even when routing would prefer
> > a different path?"  I think the answer is yes.
> 
> I agree completely that choosing a path is necessary.
> a) Number the interfaces and LSPs distinctly; or
> b) Run unnumbered
> to force the path the way you choose.  Or
> 
> c) Bundle the interfaces and LSPs, and use the Link ID
> to make both ends use consistent links.
> 
> These approaches work for both interfaces and LSPs.  A
> session ID mechanism only works for LSPs; also, it isn't
> enough to extend RSVP EROs to include session IDs, you also
> need to carry the session ID in the IGP to be able to compute
> the paths you want to force (options a and b).

Okay, this makes the issues clearer.  I agree that -
if one is relying on routing protocol to develop the
ERO - then this would be needed.  I'm not sure that
this reliance on routing is assumed universally.

> 
> Question: what does a session ID offer that can't be done
> with an "interface index"?

Actually, there's an analogous operation in RSVP-TE used
to support re-routing of TE tunnels (section 2.5 of RSVP-TE).
The SENDER_TEMPLATE object for an LSP_TUNNEL_IPV4 is very
nearly identical to the LSP-ID object in CR-LDP.

The interface index would have the same effective size, if
the LSR processing the ERO is able to retain the IPv4 address 
from the ER Hop preceding the "interface index" sub-object in
the ERO being processed.  If this can be any of the LSR's 
valid IP addresses, then the "interface index" effective
size is increased by a factor of the number of IP addresses
of the processing LSR.

> 
> Kireeti.
> 


From owner-mpls@UU.NET  Wed Aug 16 14:52:11 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02098
	for <mpls-archive@lists.ietf.org>; Wed, 16 Aug 2000 14:52:10 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcnj14601;
	Wed, 16 Aug 2000 18:51:24 GMT
Received: by mail-control.mail.uu.net 
	id QQjcnj03485
	for mpls-outgoing; Wed, 16 Aug 2000 18:50:39 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjcnj03471
	for <mpls@mail-control.mail.uu.net>; Wed, 16 Aug 2000 18:50:29 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjcnj25378
	for <mpls@UU.NET>; Wed, 16 Aug 2000 14:50:27 -0400 (EDT)
Received: from red.juniper.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: natint.juniper.net [207.17.136.129])
	id QQjcnj13698
	for <mpls@UU.NET>; Wed, 16 Aug 2000 18:50:23 GMT
Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90])
	by red.juniper.net (8.9.3/8.9.3) with ESMTP id LAA13077;
	Wed, 16 Aug 2000 11:50:19 -0700 (PDT)
Received: (from kireeti@localhost) by kummer.juniper.net (8.8.7/8.7.3) id LAA00844; Wed, 16 Aug 2000 11:49:54 -0700 (PDT)
Date: Wed, 16 Aug 2000 11:49:54 -0700 (PDT)
From: Kireeti Kompella <kireeti@juniper.net>
Message-Id: <200008161849.LAA00844@kummer.juniper.net>
To: akullber@netplane.com, EGray@zaffire.com, kireeti@juniper.net
Subject: RE: generalized MPLS signaling question
Cc: mpls@UU.NET
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Eric,

> 	But this fits snugly under the heading of a "neat
> trick" and it would be clearer and less likely to cause
> trouble down the road if some mechanism were used to
> specify an LSP explicitly.

Actually, if you really want to choose ("force") the path,
you'd use strict hops.  If LSPs/interfaces are uniquely
numbered, there isn't (shouldn't be!) any ambiguity.

Kireeti.


From owner-mpls@UU.NET  Wed Aug 16 16:54:42 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03799
	for <mpls-archive@lists.ietf.org>; Wed, 16 Aug 2000 16:54:41 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcnr16695;
	Wed, 16 Aug 2000 20:50:10 GMT
Received: by mail-control.mail.uu.net 
	id QQjcnr08300
	for mpls-outgoing; Wed, 16 Aug 2000 20:49:40 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjcnr08295
	for <mpls@mail-control.mail.uu.net>; Wed, 16 Aug 2000 20:49:34 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjcnr29407
	for <mpls@uu.net>; Wed, 16 Aug 2000 16:49:25 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjcnr15790
	for <mpls@uu.net>; Wed, 16 Aug 2000 20:49:24 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA25931
	for mpls@uu.net; Wed, 16 Aug 2000 16:49:24 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjcnr08281
	for <mpls@mail-control.mail.uu.net>; Wed, 16 Aug 2000 20:48:54 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjcnr29215
	for <mpls@UU.NET>; Wed, 16 Aug 2000 16:48:39 -0400 (EDT)
Received: from xover.hjinc.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [38.160.241.130])
	id QQjcnr29151
	for <mpls@UU.NET>; Wed, 16 Aug 2000 20:48:23 GMT
Received: by xover.hjinc.com with Internet Mail Service (5.5.2650.21)
	id <QQ74Y28F>; Wed, 16 Aug 2000 16:44:15 -0400
Message-ID: <7BF58A904536D411ADD400508BC97B85046BBA@xover1.netplane.com>
From: "Kullberg, Alan" <akullber@netplane.com>
To: "'Kireeti Kompella'" <kireeti@juniper.net>, mpls@UU.NET
Subject: RE: generalized MPLS signaling question
Date: Wed, 16 Aug 2000 16:44:31 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Kireeti,

> -----Original Message-----
> From: Kireeti Kompella [mailto:kireeti@juniper.net]
> Sent: Wednesday, August 16, 2000 12:16 PM
> To: akullber@netplane.com; mpls@UU.NET
> Subject: Re: generalized MPLS signaling question
> 
> 
> > how do LSR-A and LSR-B coordinate
> > the timeslot allocation so that LSR-A sends the data in the
> > timeslot on the correct Lambda?
> 
> Using the ERO.  Each lambda (actually, lambda-switched path) is
> uniquely identified, either by an IP address or by an "interface"
> index as defined in the unnumbered draft.

Let's assume the lambda-switched paths are unnumbered and are assigned
"interface" indices as per the unnumbered draft.  When LSR-B receives
an ERO with the "Interface ID" subobject, how is the association made
with the correct lambda-switched path for timeslot allocation?

Alan



From owner-mpls@UU.NET  Wed Aug 16 17:19:27 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04103
	for <mpls-archive@lists.ietf.org>; Wed, 16 Aug 2000 17:19:26 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcnt08363;
	Wed, 16 Aug 2000 21:18:52 GMT
Received: by mail-control.mail.uu.net 
	id QQjcnt22914
	for mpls-outgoing; Wed, 16 Aug 2000 21:18:19 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjcnt22909
	for <mpls@mail-control.mail.uu.net>; Wed, 16 Aug 2000 21:18:07 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjcnt24640
	for <mpls@UU.NET>; Wed, 16 Aug 2000 17:18:06 -0400 (EDT)
Received: from red.juniper.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: natint.juniper.net [207.17.136.129])
	id QQjcnt07469
	for <mpls@UU.NET>; Wed, 16 Aug 2000 21:17:50 GMT
Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90])
	by red.juniper.net (8.9.3/8.9.3) with ESMTP id OAA00163;
	Wed, 16 Aug 2000 14:17:50 -0700 (PDT)
Received: (from kireeti@localhost) by kummer.juniper.net (8.8.7/8.7.3) id OAA01334; Wed, 16 Aug 2000 14:17:25 -0700 (PDT)
Date: Wed, 16 Aug 2000 14:17:25 -0700 (PDT)
From: Kireeti Kompella <kireeti@juniper.net>
Message-Id: <200008162117.OAA01334@kummer.juniper.net>
To: akullber@netplane.com, kireeti@juniper.net, mpls@UU.NET
Subject: RE: generalized MPLS signaling question
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Alan,

> Let's assume the lambda-switched paths are unnumbered and are assigned
> "interface" indices as per the unnumbered draft.  When LSR-B receives
> an ERO with the "Interface ID" subobject, how is the association made
> with the correct lambda-switched path for timeslot allocation?

Excellent question.  The implicit assumption was that with out-of-band
signalling, some other means of identifying the links is used (e.g., a
variant of LMP).  I.e., LSR-A knows (per the ERO) which FA
(lambda-switched path) to use.  LSR-A and LSR-B have already identified
the links (e.g., with some variant of LMP).  LSR-A then sends the Path
message with a Link ID object (from the bundling document) to let LSR-B
know which FA LSR-A wants to use.

However, this is not altogether satisfactory (variant of LMP, etc).
An alternate solution is being worked on.

Kireeti.


From owner-mpls@UU.NET  Wed Aug 16 17:55:36 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04448
	for <mpls-archive@lists.ietf.org>; Wed, 16 Aug 2000 17:55:36 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcnv25584;
	Wed, 16 Aug 2000 21:54:49 GMT
Received: by mail-control.mail.uu.net 
	id QQjcnv24473
	for mpls-outgoing; Wed, 16 Aug 2000 21:54:17 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjcnv24468
	for <mpls@mail-control.mail.uu.net>; Wed, 16 Aug 2000 21:54:05 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjcnv10574
	for <mpls@UU.NET>; Wed, 16 Aug 2000 17:53:45 -0400 (EDT)
Received: from icarian.ZAFFIRE.COM by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ATHM-64-232-xxx-132.home.net [64.232.69.132] (may be forged))
	id QQjcnv01788
	for <mpls@UU.NET>; Wed, 16 Aug 2000 21:53:30 GMT
Received: by ICARIAN with Internet Mail Service (5.5.2650.21)
	id <QX14ZB8X>; Wed, 16 Aug 2000 15:01:26 -0700
Message-ID: <4D3F9F2BEC58D4118FCE009027B0A662136138@ICARIAN>
From: Eric Gray <EGray@zaffire.com>
To: "'Kireeti Kompella'" <kireeti@juniper.net>,
        Eric Gray
	 <EGray@zaffire.com>
Cc: mpls@UU.NET
Subject: RE: generalized MPLS signaling question
Date: Wed, 16 Aug 2000 15:01:25 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Kireeti,

	Please see embedded comment.

> -----Original Message-----
> From: Kireeti Kompella [mailto:kireeti@juniper.net]
> Sent: Wednesday, August 16, 2000 11:50 AM
> To: akullber@netplane.com; EGray@zaffire.com; kireeti@juniper.net
> Cc: mpls@UU.NET
> Subject: RE: generalized MPLS signaling question
> 
> 
> Hi Eric,
> 
> > 	But this fits snugly under the heading of a "neat
> > trick" and it would be clearer and less likely to cause
> > trouble down the road if some mechanism were used to
> > specify an LSP explicitly.
> 
> Actually, if you really want to choose ("force") the path,
> you'd use strict hops.  If LSPs/interfaces are uniquely
> numbered, there isn't (shouldn't be!) any ambiguity.

I agree that this should work.  I also like the
approach of not having a different answer for
MPLS and other link types.

What I can't seem to find is where it is made
clear that an LSR would necessarily find this 
one unique IP address route.  As I said earlier, 
it makes sense, but I don't think we can get 
away with not specifying something explicitly 
because it makes sense.  Lots of things make 
sense.

I looked through the following drafts: 	

	draft-kompella-mpls-optical-00.txt
	draft-kompella-mpls-bundle-02.txt
	draft-kompella-lsp-hierarchy-00.txt
	draft-kompella-mpls-unnum-00.txt

I was looking for something that said something
like:

"When processing an ERO, if a forwarding adjacency
 has an IP address that exactly matches the address
 in the ERO sub-object (in the case of RSVP-TE), 
 the LSP being established is expected to traverse
 the forwarding adjacency LSP using label stacking.

"If the ERO's next sub-object is an interface index
 sub-object and there is a corresponding unnumbered
 forwarding adjacency with a matching interface index,
 the LSP being established is expected to traverse
 the forwarding adjacency LSP using label stacking."

If something like this exists already, can you point
it out?

In fairness, you could argue that this is implied if
the forwarding adjacency is advertised into an IGP.
But advertising a forwarding adjacency into a specific
IGP is not mandated in any of the drafts noted above.
Yet, I assume that - if the LSP initiator somehow got
a hold of the IP address for such a FA-LSP - we would
still want the corresponding LSP used.  If not, then
this is not clear either.

Thanks!

> 
> Kireeti.
> 


From nghani@sorrentonet.com  Wed Aug 16 18:42:44 2000
Received: from srnex01.sd.osicom.com ([131.143.32.21])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04787
	for <mpls-archive@lists.ietf.org>; Wed, 16 Aug 2000 18:42:33 -0400 (EDT)
Received: by srnex01.sd.osicom.com with Internet Mail Service (5.5.2650.21)
	id <Q98XXW4G>; Wed, 16 Aug 2000 14:58:36 -0700
Message-ID: <F45297C63162D411BE3600D0B7824AAF0F6E7F@srnex01.sd.osicom.com>
From: "Ghani, Nasir" <nghani@sorrentonet.com>
To: "'pleela@utopia.hclt.com'" <pleela@utopia.hclt.com>,
        "'ietf.info@hilan.de'" <ietf.info@hilan.de>,
        "'chuangcc@ms1.hinet.net'"
	 <chuangcc@ms1.hinet.net>,
        "'ofcaltos@ms14.hinet.net'"
	 <ofcaltos@ms14.hinet.net>,
        "'atarashi@ebina.hitachi.co.jp'"
	 <atarashi@ebina.hitachi.co.jp>,
        "'fukusima@sdl.hitachi.co.jp'"
	 <fukusima@sdl.hitachi.co.jp>,
        "'hkanai@ebina.hitachi.co.jp'"
	 <hkanai@ebina.hitachi.co.jp>,
        "'k-kawagu@sdl.hitachi.co.jp'"
	 <k-kawagu@sdl.hitachi.co.jp>,
        "'saka-ken@crl.hitachi.co.jp'"
	 <saka-ken@crl.hitachi.co.jp>,
        "'sohno@ebina.hitachi.co.jp'"
	 <sohno@ebina.hitachi.co.jp>,
        "'ysako@ebina.hitachi.co.jp'"
	 <ysako@ebina.hitachi.co.jp>,
        "'akullber@hjinc.com'" <akullber@hjinc.com>,
        "'hjinc_tagsw@hjinc.com'" <hjinc_tagsw@hjinc.com>,
        "'andy_luque@hotmail.com'" <andy_luque@hotmail.com>,
        "'ehabh@hotmail.com'" <ehabh@hotmail.com>,
        "'jaarons@hotmail.com'"
	 <jaarons@hotmail.com>,
        "'jim_dez@hotmail.com'" <jim_dez@hotmail.com>,
        "'k_neeraj@hotmail.com'" <k_neeraj@hotmail.com>,
        "'mps@hplb.hpl.hp.com'"
	 <mps@hplb.hpl.hp.com>,
        "'Hanna.Karjalainen@hpy.fi'"
	 <Hanna.Karjalainen@hpy.fi>,
        "'isomaki@hpylab.rc.hpy.fi'"
	 <isomaki@hpylab.rc.hpy.fi>,
        "'swan@hpy.fi'" <swan@hpy.fi>,
        "'h0444wzx@rz.hu-berlin.de'" <h0444wzx@rz.hu-berlin.de>,
        "'jgalgay@i3s.net'" <jgalgay@i3s.net>,
        "'ajithn@sg.ibm.com'"
	 <ajithn@sg.ibm.com>,
        "'edbowen@us.ibm.com'" <edbowen@us.ibm.com>,
        "'marianne_aubry@fr.ibm.com'" <marianne_aubry@fr.ibm.com>,
        "'markk@sg.ibm.com'" <markk@sg.ibm.com>,
        "'ml-mpls@zurich.ibm.com'"
	 <ml-mpls@zurich.ibm.com>,
        "'mpls@listgate.iconnet.net'"
	 <mpls@listgate.iconnet.net>,
        "'dward@ieng.com'" <dward@ieng.com>, "'jgs@ieng.com'" <jgs@ieng.com>,
        "'lpj@ieng.com'" <lpj@ieng.com>, "'patg@imp.ch'" <patg@imp.ch>,
        "'Cristina.Vistoli@cnaf.infn.it'"
	 <Cristina.Vistoli@cnaf.infn.it>,
        "'huang@christine.infonet.com'"
	 <huang@christine.infonet.com>,
        "'nadim@christine.infonet.com'"
	 <nadim@christine.infonet.com>,
        "'FREYNA@infosel.com.mx'"
	 <FREYNA@infosel.com.mx>,
        "'jbotello@infosel.com.mx'"
	 <jbotello@infosel.com.mx>,
        "'dbaker@integralaccess.com'"
	 <dbaker@integralaccess.com>,
        "'dons@interlog.com'" <dons@interlog.com>,
        "'ncraven@interlog.com'" <ncraven@interlog.com>,
        "'radu@interspeed.com'"
	 <radu@interspeed.com>,
        "'herzog@iphighway.com'" <herzog@iphighway.com>,
        "'tagswitch@ipsilon.com'" <tagswitch@ipsilon.com>,
        "'tomoharu@iri.co.jp'"
	 <tomoharu@iri.co.jp>,
        "'gsluz@ironbridgenetworks.com'"
	 <gsluz@ironbridgenetworks.com>,
        "'jkr@ironbridgenetworks.com'"
	 <jkr@ironbridgenetworks.com>,
        "'lists-mpls@ironbridgenetworks.com'"
	 <lists-mpls@ironbridgenetworks.com>,
        "'alan@isi.net'" <alan@isi.net>, "'berson@ISI.EDU'" <berson@ISI.EDU>,
        "'javad@isi.edu'" <javad@ISI.EDU>, "'mankin@ISI.EDU'" <mankin@ISI.EDU>,
        "'suresh@isi.edu'" <suresh@ISI.EDU>,
        "'STEPHEN.GEIS@ITU.CH'" <STEPHEN.GEIS@ITU.CH>,
        "'kevin@nosc.ja.net'"
	 <kevin@nosc.ja.net>,
        "'kuri@japan-telecom.co.jp'"
	 <kuri@japan-telecom.co.jp>,
        "'yone@japan-telecom.co.jp'"
	 <yone@japan-telecom.co.jp>,
        "'szeto_chung@jpmorgan.com'"
	 <szeto_chung@jpmorgan.com>,
        "'rjbulk@jr.com'" <rjbulk@jr.com>,
        "'in-ietf-mpls@juniper.net'" <in-ietf-mpls@juniper.net>,
        "'jstewart@juniper.net'" <jstewart@juniper.net>,
        "'yuji@juniper.net'"
	 <yuji@juniper.net>,
        "'tanaike@eagle.cnt.jusoft.co.jp'"
	 <tanaike@eagle.cnt.jusoft.co.jp>,
        "'hotta@lab.kdd.co.jp'"
	 <hotta@lab.kdd.co.jp>,
        "'ovguy@kocsistem.com.tr'"
	 <ovguy@kocsistem.com.tr>,
        "'H.A.B.vandeVlag@research.kpn.com'"
	 <H.A.B.vandeVlag@research.kpn.com>,
        "'jim.boyle@l3.com'"
	 <jim.boyle@l3.com>,
        "'luca@l3.net'" <luca@l3.net>,
        "'Nasser.ElAawar@L3.com'" <Nasser.ElAawar@l3.com>,
        "'Andrewb@layer8.co.uk'" <Andrewb@layer8.co.uk>,
        "'Luis.Costa@lip6.fr'"
	 <Luis.Costa@lip6.fr>,
        "'Olivier.Fourmaux@lip6.fr'"
	 <Olivier.Fourmaux@lip6.fr>,
        "'Pascal.Anelli@lip6.fr'"
	 <Pascal.Anelli@lip6.fr>,
        "'Serge.Fdida@lip6.fr'" <Serge.Fdida@lip6.fr>,
        "'chirouze@lirmm.fr'" <chirouze@lirmm.fr>,
        "'dkataria@aloft.micro.lucent.com'" <dkataria@aloft.micro.lucent.com>,
        "'dromasca@lucent.com'" <dromasca@lucent.com>,
        "'gratta@holta.ho.lucent.com'" <gratta@holta.ho.lucent.com>,
        "'lgnavarro@lucent.com'" <lgnavarro@lucent.com>,
        "'lotfi@hoserve.ho.lucent.com'" <lotfi@hoserve.ho.lucent.com>,
        "'venki@lucent.com'" <venki@lucent.com>,
        "'xuyg@lucent.com'"
	 <xuyg@lucent.com>,
        "'rbonica@MCI.NET'" <rbonica@MCI.NET>,
        "'joel@mcquillan.com'" <joel@mcquillan.com>,
        "'John@mcquillan.com'"
	 <John@mcquillan.com>,
        "'cjs@mediasc.com'" <cjs@mediasc.com>,
        "'fm-listproc@mediatrix.com'" <fm-listproc@mediatrix.com>,
        "'chopps@merit.edu'" <chopps@merit.edu>,
        "'wfs@merit.edu'"
	 <wfs@merit.edu>,
        "'zheng@merl.com'" <zheng@merl.com>,
        "'zdf@metrocom.ru'" <zdf@metrocom.ru>,
        "'yuasa@trc.mew.co.jp'"
	 <yuasa@trc.mew.co.jp>,
        "'Ales.Dryak@mfcr.cz'" <Ales.Dryak@mfcr.cz>,
        "'arvindm@microsoft.com'" <arvindm@microsoft.com>,
        "'cristina@midnight.com'" <cristina@midnight.com>,
        "'kamelden@mindspring.com'" <kamelden@mindspring.com>,
        "'dina@ai.mit.edu'" <dina@ai.mit.edu>,
        "'es@vorlon.mit.edu'"
	 <es@vorlon.mit.edu>,
        "'jnc@ginger.lcs.mit.edu'" <jnc@ginger.lcs.mit.edu>,
        "'jtw@lcs.mit.edu'" <jtw@lcs.mit.edu>,
        "'cmk013@lmpsil02.comm.mot.com'"
	 <cmk013@lmpsil02.comm.mot.com>,
        "'ttg536@email.sps.mot.com'"
	 <ttg536@email.sps.mot.com>,
        "'parnigoni-neill@email.msn.com'"
	 <parnigoni-neill@email.msn.com>,
        "'vuppala@cse.msu.edu'"
	 <vuppala@cse.msu.edu>,
        "'tagswitch@nanospace.com'"
	 <tagswitch@nanospace.com>,
        "'jloiacon@nastg.gsfc.nasa.gov'"
	 <jloiacon@nastg.gsfc.nasa.gov>,
        "'lamaster@george.arc.nasa.gov'"
	 <lamaster@george.arc.nasa.gov>,
        "'kodonog@nswc.navy.mil'"
	 <kodonog@nswc.navy.mil>,
        "'dowd@afterlife.ncsc.mil'"
	 <dowd@afterlife.ncsc.mil>,
        "'suguri@cc22.ne.jp'" <suguri@cc22.ne.jp>,
        "'kenshin@ptl.abk.nec.co.jp'" <kenshin@ptl.abk.nec.co.jp>,
        "'kiso@fnw.abk.nec.co.jp'" <kiso@fnw.abk.nec.co.jp>,
        "'kolarov@ccrl.nj.nec.com'" <kolarov@ccrl.nj.nec.com>,
        "'lucky@swd.abk.nec.co.jp'" <lucky@swd.abk.nec.co.jp>,
        "'mgr@ccrl.nj.nec.com'" <mgr@ccrl.nj.nec.com>,
        "'miyamoto@bcd.abk.nec.co.jp'" <miyamoto@bcd.abk.nec.co.jp>,
        "'motoo@ptl.abk.nec.co.jp'" <motoo@ptl.abk.nec.co.jp>,
        "'yozo@sw.land.fc.nec.co.jp'" <yozo@sw.land.fc.nec.co.jp>,
        "'jochen@netcom.com'" <jochen@netcom.com>,
        "'kijiny@ix.netcom.com'"
	 <kijiny@ix.netcom.com>,
        "'sanjeev@netcom.com'" <sanjeev@netcom.com>,
        "'magda@netinsight.se'" <magda@netinsight.se>,
        "'rrb@netrix.com'"
	 <rrb@netrix.com>,
        "'AlonB@netro-corp.com'" <AlonB@netro-corp.com>,
        "'smills@netspeak.com'" <smills@netspeak.com>,
        "'hchan@newbridge.com'"
	 <hchan@newbridge.com>,
        "'jlaw@Newbridge.COM'" <jlaw@newbridge.com>,
        "'cbenz@nexabit.com'" <cbenz@nexabit.com>,
        "'dflowers@nexabit.com'"
	 <dflowers@nexabit.com>,
        "'dhaskin@nexabit.com'" <dhaskin@nexabit.com>,
        "'gmirsky@nexabit.com'" <gmirsky@nexabit.com>,
        "'ram@nexabit.com'"
	 <ram@nexabit.com>,
        "'hunt@nexen.com'" <hunt@nexen.com>,
        "'navali@nexen.com'" <navali@nexen.com>,
        "'ramaraju@nexen.com'"
	 <ramaraju@nexen.com>,
        "'sajin@nexen.com'" <sajin@nexen.com>,
        "'bdevalla@nortelnetworks.com'" <bdevalla@nortelnetworks.com>,
        "'cremis@nortelnetworks.com'" <cremis@nortelnetworks.com>,
        "'jasman@nortelnetworks.com'" <jasman@nortelnetworks.com>,
        "'Robert.Tomkins.rtomkins@nortelnetworks.com'"
	 <Robert.Tomkins.rtomkins@nortelnetworks.com>,
        "'gstrawn@nsf.gov'"
	 <gstrawn@nsf.gov>,
        "'sgoldste@nsf.gov'" <sgoldste@nsf.gov>,
        "'george@scc.ntnu.edu.tw'" <george@scc.ntnu.edu.tw>,
        "'hide@ntt-wt.co.jp'" <hide@ntt-wt.co.jp>,
        "'ayano@exa.onlab.ntt.co.jp'"
	 <ayano@exa.onlab.ntt.co.jp>,
        "'chimaru.takeshi@nslab.ntt.co.jp'"
	 <chimaru.takeshi@nslab.ntt.co.jp>,
        "'kihara@isl.ntt.co.jp'"
	 <kihara@isl.ntt.co.jp>,
        "'masuda@nttmhs.tnl.ntt.co.jp'"
	 <masuda@nttmhs.tnl.ntt.co.jp>,
        "'oohara@hashi.tnl.ntt.co.jp'"
	 <oohara@hashi.tnl.ntt.co.jp>,
        "'Shiomoto.Kohei@nslab.ntt.co.jp'"
	 <Shiomoto.Kohei@nslab.ntt.co.jp>,
        "'tagswitch@nttssl.nslab.ntt.co.jp'"
	 <tagswitch@nttssl.nslab.ntt.co.jp>,
        "'apoh@comp.nus.edu.sg'"
	 <apoh@comp.nus.edu.sg>,
        "'jduffy@nww.com'" <jduffy@nww.com>,
        "'mwooten@sw.ods.com'" <mwooten@sw.ods.com>,
        "'goyal@cis.ohio-state.edu'"
	 <goyal@cis.ohio-state.edu>,
        "'wsun@cis.ohio-state.edu'"
	 <wsun@cis.ohio-state.edu>,
        "'cwhite@omnia.com'" <cwhite@omnia.com>,
        "'mpls-archive@cell.onecall.net'" <mpls-archive@cell.onecall.net>,
        "'twerner@onecall.net'" <twerner@onecall.net>,
        "'hildeoi@online.no'"
	 <hildeoi@online.no>,
        "'Ulrich.Schulz@oppenheim.de'"
	 <Ulrich.Schulz@oppenheim.de>,
        "'SAlagar@opticworks.com'"
	 <SAlagar@opticworks.com>,
        "'yuki@k-isit.or.jp'" <yuki@k-isit.or.jp>,
        "'elainel@pacific.net.sg'" <elainel@pacific.net.sg>,
        "'davidc@packetengines.com'" <davidc@packetengines.com>,
        "'sdommeti@packetengines.com'" <sdommeti@packetengines.com>,
        "'Vhsu@ttl.pactel.com'" <Vhsu@ttl.pactel.com>,
        "'attique@snoopy.pakistan.com'" <attique@snoopy.pakistan.com>,
        "'cbrown@paracom.com'" <cbrown@paracom.com>,
        "'rsp@nj.paradyne.com'"
	 <rsp@nj.paradyne.com>,
        "'john@patsy.com'" <john@patsy.com>,
        "'pgn@perform.fr'" <pgn@perform.fr>,
        "'znati@cs.pitt.edu'"
	 <znati@cs.pitt.edu>,
        "'skirmont@pluris.com'" <skirmont@pluris.com>,
        "'cheng@pmc-sierra.com'" <cheng@pmc-sierra.com>,
        "'lambert@psc.edu'"
	 <lambert@psc.edu>,
        "'beckman@purplecow.com'" <beckman@purplecow.com>,
        "'Marcus.Daley@uk.quza.com'" <Marcus.Daley@uk.quza.com>,
        "'bcchoi@etri.re.kr'" <bcchoi@etri.re.kr>,
        "'bcjeon@nice.etri.re.kr'"
	 <bcjeon@nice.etri.re.kr>,
        "'bikim@etri.re.kr'" <bikim@etri.re.kr>,
        "'choits@etri.re.kr'" <choits@etri.re.kr>,
        "'cmpark@etri.re.kr'"
	 <cmpark@etri.re.kr>,
        "'etxkang@etri.re.kr'" <etxkang@etri.re.kr>,
        "'hrlee@etri.re.kr'" <hrlee@etri.re.kr>,
        "'jaeho@etri.re.kr'"
	 <jaeho@etri.re.kr>,
        "'jaesup@etri.re.kr'" <jaesup@etri.re.kr>,
        "'msjang@etri.re.kr'" <msjang@etri.re.kr>,
        "'parkhj@etri.re.kr'"
	 <parkhj@etri.re.kr>,
        "'phk@etri.re.kr'" <phk@etri.re.kr>,
        "'ykjeong@etri.re.kr'" <ykjeong@etri.re.kr>,
        "'cristina@redstonecom.com'"
	 <cristina@redstonecom.com>,
        "'Tim_Weingarten@rsco.com'"
	 <Tim_Weingarten@rsco.com>,
        "'Rajesh@saharanet.com'"
	 <Rajesh@saharanet.com>,
        "'banghyun@secns.sec.samsung.co.kr'"
	 <banghyun@secns.sec.samsung.co.kr>,
        "'heejin@secns.sec.samsung.co.kr'"
	 <heejin@secns.sec.samsung.co.kr>,
        "'MSchneid@tri.sbc.com'"
	 <MSchneid@tri.sbc.com>,
        "'eric@seinedynamics.com'"
	 <eric@seinedynamics.com>,
        "'AAlles@shastanets.com'"
	 <AAlles@shastanets.com>,
        "'alin@shastanets.com'" <alin@shastanets.com>,
        "'bgleeson@shastanets.com'" <bgleeson@shastanets.com>,
        "'CYuan@shastanets.com'" <CYuan@shastanets.com>,
        "'dginsburg@shastanets.com'" <dginsburg@shastanets.com>,
        "'LLL@shastanets.com'" <LLL@shastanets.com>,
        "'peter@sics.se'"
	 <peter@sics.se>,
        "'Derek.Harkness@vs.siemens.de'"
	 <Derek.Harkness@vs.siemens.de>,
        "'Eugen.Wallmeier@oen.siemens.de'"
	 <Eugen.Wallmeier@oen.siemens.de>,
        "'jens.voigt@icn.siemens.de'"
	 <jens.voigt@icn.siemens.de>,
        "'Mike.Chapman@oen.siemens.de'"
	 <Mike.Chapman@oen.siemens.de>,
        "'Thomas.Theimer@oen.siemens.de'"
	 <Thomas.Theimer@oen.siemens.de>,
        "'george@silicon.net.my'"
	 <george@silicon.net.my>,
        "'gmlim@staff.singnet.com.sg'"
	 <gmlim@staff.singnet.com.sg>,
        "'Steve.Turner@pt.nce.sita.int'"
	 <Steve.Turner@pt.nce.sita.int>,
        "'niclas.comstedt@sonera.se'"
	 <niclas.comstedt@sonera.se>,
        "'onoe@sm.sony.co.jp'" <onoe@sm.sony.co.jp>,
        "'Kert.E.Mezger@mail.sprint.com'" <Kert.E.Mezger@mail.sprint.com>,
        "'phillips@sprint.net'" <phillips@sprint.net>,
        "'rrockell@sprint.net'"
	 <rrockell@sprint.net>,
        "'akar@sprintcorp.com'" <akar@sprintcorp.com>,
        "'rgr@stanford.edu'" <rgr@stanford.edu>,
        "'flavio@stratumone.com'"
	 <flavio@stratumone.com>,
        "'michael@stratumone.com'"
	 <michael@stratumone.com>,
        "'tomimura@sumitomo.com'"
	 <tomimura@sumitomo.com>,
        "'yoshida@sumitomo.com'" <yoshida@sumitomo.com>,
        "'joew@poplar.East.Sun.COM'" <joew@poplar.East.Sun.COM>,
        "'michael.speer@Eng.Sun.COM'" <michael.speer@Eng.Sun.COM>,
        "'Niels.denOtter@SURFnet.nl'" <Niels.denOtter@SURFnet.nl>,
        "'Fabien.Berger@swisscom.com'" <Fabien.Berger@swisscom.com>,
        "'Juerg.Fankhauser@swisscom.com'" <Juerg.Fankhauser@swisscom.com>,
        "'Raphael.Schumacher@Swisscom.com'" <Raphael.Schumacher@swisscom.com>,
        "'naini@syndesis.com'" <naini@syndesis.com>,
        "'tailor@syndesis.com'"
	 <tailor@syndesis.com>,
        "'ppmorris@syr.edu'" <ppmorris@syr.edu>,
        "'fari@loc201.tandem.com'" <fari@loc201.tandem.com>,
        "'tagswitch@tbit.dk'" <tagswitch@tbit.dk>,
        "'tagswitch@lohi.dat.tele.fi'"
	 <tagswitch@lohi.dat.tele.fi>,
        "'jrstuart@telefonica.com.pe'"
	 <jrstuart@telefonica.com.pe>,
        "'bernhard@telia.net'"
	 <bernhard@telia.net>,
        "'kim@telia.net'" <kim@telia.net>,
        "'Leif.J.Bystrom@telia.se'" <Leif.J.Bystrom@telia.se>,
        "'mpls@lohi.eng.telia.fi'" <mpls@lohi.eng.telia.fi>,
        "'Olle.K.Pers@telia.se'" <Olle.K.Pers@telia.se>,
        "'Oscar.A.Bravo@telia.se'" <Oscar.A.Bravo@telia.se>,
        "'ietf.mpls@mail.teliafi.net'" <ietf.mpls@mail.teliafi.net>,
        "'Risto.Soila@tellabs.fi'" <Risto.Soila@tellabs.fi>,
        "'Tino.Rodriguez@tellabs.com'" <Tino.Rodriguez@tellabs.com>,
        "'albert@netboss.cdn.telstra.com.au'" <albert@netboss.cdn.telstra.com.au>,
        "'davidw@telstra.net'" <davidw@telstra.net>,
        "'gih@telstra.net'"
	 <gih@telstra.net>,
        "'r.liu@trl.telstra.com.au'"
	 <r.liu@trl.telstra.com.au>,
        "'asodder@tenornetworks.com'"
	 <asodder@tenornetworks.com>,
        "'slblake@torrentnet.com'"
	 <slblake@torrentnet.com>,
        "'ken.nagami@toshiba.co.jp'"
	 <ken.nagami@toshiba.co.jp>,
        "'shigeom@isl.rdc.toshiba.co.jp'"
	 <shigeom@isl.rdc.toshiba.co.jp>,
        "'sirakawa@isl.rdc.toshiba.co.jp'"
	 <sirakawa@isl.rdc.toshiba.co.jp>,
        "'tagswitch@isl.rdc.toshiba.co.jp'"
	 <tagswitch@isl.rdc.toshiba.co.jp>,
        "'olcay@tr-net.net.tr'"
	 <olcay@tr-net.net.tr>,
        "'rschaffner@trace.de'" <rschaffner@trace.de>,
        "'yuank@tuns.ca'" <yuank@tuns.ca>,
        "'jtian@cs.ubc.ca'" <jtian@cs.ubc.ca>,
        "'lixia@CS.UCLA.EDU'" <lixia@CS.UCLA.EDU>,
        "'jamesz@ucscomm.com'"
	 <jamesz@ucscomm.com>,
        "'sliu@cs.uiowa.edu'" <sliu@cs.uiowa.edu>,
        "'ananth@ittc.ukans.edu'" <ananth@ittc.ukans.edu>,
        "'grobe@raven.cc.ukans.edu'" <grobe@raven.cc.ukans.edu>,
        "'hauser-s@ma.ultranet.com'" <hauser-s@ma.ultranet.com>,
        "'phelan@ultranet.com'" <phelan@ultranet.com>,
        "'georgeap@cs.umd.edu'"
	 <georgeap@cs.umd.edu>,
        "'ashish@eecs.umich.edu'" <ashish@eecs.umich.edu>,
        "'bsc@umich.edu'" <bsc@umich.edu>,
        "'digravin@nts.umn.edu'"
	 <digravin@nts.umn.edu>,
        "'rdb@iol.unh.edu'" <rdb@iol.unh.edu>,
        "'cabo@Informatik.Uni-Bremen.DE'" <cabo@Informatik.Uni-Bremen.DE>,
        "'dolzer@ind.uni-stuttgart.de'" <dolzer@ind.uni-stuttgart.de>,
        "'mpls@mail2news.unibe.ch'" <mpls@mail2news.unibe.ch>,
        "'matinata@dca.fee.unicamp.br'" <matinata@dca.fee.unicamp.br>,
        "'mauricio@dca.fee.unicamp.br'" <mauricio@dca.fee.unicamp.br>,
        "'jad@network-services.uoregon.edu'" <jad@network-services.uoregon.edu>,
        "'meyer@network-services.uoregon.edu'"
	 <meyer@network-services.uoregon.edu>,
        "'paul@st.elec.uow.edu.au'"
	 <paul@st.elec.uow.edu.au>,
        "'guerin@ee.upenn.edu'" <guerin@ee.upenn.edu>,
        "'list_ietf_mpls@donuts.isc-net.upenn.edu'"
	 <list_ietf_mpls@donuts.isc-net.upenn.edu>,
        "'kchinth@advtech.uswest.com'" <kchinth@advtech.uswest.com>,
        "'aps@ee.uts.edu.au'" <aps@ee.uts.edu.au>,
        "'awduche@UU.NET'"
	 <awduche@UU.NET>, "'louie@UU.NET'" <louie@UU.NET>,
        "'tsheehan@vanstar.com'" <tsheehan@vanstar.com>,
        "'proy@videotron.net'"
	 <proy@videotron.net>,
        "'corbato@cac.washington.edu'"
	 <corbato@cac.washington.edu>,
        "'pdickson@westpac.com.au'"
	 <pdickson@westpac.com.au>,
        "'amsden@worldpath.net'"
	 <amsden@worldpath.net>,
        "'geof@xylan.com'" <geof@xylan.com>,
        "'Ides.Vanneuville@xylan.com'" <Ides.Vanneuville@xylan.com>,
        "'michael.see@xylan.com'" <michael.see@xylan.com>,
        "'paramesh@xylan.com'"
	 <paramesh@xylan.com>,
        "'sk@yagosys.com'" <sk@yagosys.com>,
        "'scapshaw@yahoo.com'" <scapshaw@yahoo.com>,
        "'leung@YorkU.CA'"
	 <leung@YorkU.CA>,
        "'troy@zyxel.com.tw'" <troy@zyxel.com.tw>,
        "'erosen@cisco.com'" <erosen@cisco.com>,
        "'francesco.cialini@globalone.net'" <francesco.cialini@globalone.net>,
        "'grogier@greatplains.net'" <grogier@greatplains.net>,
        "'dheitman@i3s.net'" <dheitman@i3s.net>,
        "'egashira@ccm.cl.nec.co.jp'"
	 <egashira@ccm.cl.nec.co.jp>,
        "'mm@olicom.dk'" <mm@olicom.dk>,
        "'hyryu@etri.re.kr'" <hyryu@etri.re.kr>,
        "'M.H.Kluwer@research.kpn.com'"
	 <M.H.Kluwer@research.kpn.com>,
        "'bluesea@etri.re.kr'"
	 <bluesea@etri.re.kr>,
        "'albertp@nortelnetworks.com'"
	 <albertp@nortelnetworks.com>,
        "'ABREDSKINS@aol.com'"
	 <ABREDSKINS@aol.com>,
        "'avisng@newbridge.com'" <avisng@newbridge.com>,
        "'mohan@tiaranet.com'" <mohan@tiaranet.com>,
        "'skohalmi@quarrytech.com'"
	 <skohalmi@quarrytech.com>,
        "'EROGERS@BFDS.com'" <EROGERS@BFDS.com>,
        "'dajs@nortelnetworks.com'" <dajs@nortelnetworks.com>,
        "'noah@Level3.net'" <noah@Level3.net>,
        "'jian@qwest.net'"
	 <jian@qwest.net>,
        "'rmcclune@BayNetworks.COM'"
	 <rmcclune@BayNetworks.COM>,
        "'mduffy@quarrytech.com'"
	 <mduffy@quarrytech.com>,
        "'mahidell@dynarc.se'" <mahidell@dynarc.se>,
        "'oscar@nortelnetworks.com'" <oscar@nortelnetworks.com>,
        "'gskuo@IMRNET.MGT.NCU.EDU.TW'" <gskuo@IMRNET.MGT.NCU.EDU.TW>,
        "'gspiride@seas.smu.edu'" <gspiride@seas.smu.edu>,
        "'gary.baldwin@cerent.com'" <gary.baldwin@cerent.com>,
        "'jhhahm@pec.etri.re.kr'" <jhhahm@pec.etri.re.kr>,
        "'arvind@tenornetworks.com'" <arvind@tenornetworks.com>,
        "'randy@psg.com'" <randy@psg.com>,
        "'t-ishii@tsdd.ts.fujitsu.co.jp'"
	 <t-ishii@tsdd.ts.fujitsu.co.jp>,
        "'sshelly@avici.com'"
	 <sshelly@avici.com>,
        "'vijay@juniper.net'" <vijay@juniper.net>,
        "'msmui@att.com'" <msmui@att.com>,
        "'ldupless@reltectransport.com'"
	 <ldupless@reltectransport.com>,
        "'daven@msn.bt.co.uk'"
	 <daven@msn.bt.co.uk>,
        "'mrg@nortelnetworks.com'"
	 <mrg@nortelnetworks.com>,
        "'hovpros@online.no'" <hovpros@online.no>, "'dm@bbn.com'" <dm@bbn.com>,
        "'bjp@ascend.com'" <bjp@ascend.com>, "'kann@ISI.EDU'" <kann@ISI.EDU>,
        "'fred.schmidt@cdcgy.com'"
	 <fred.schmidt@cdcgy.com>,
        "'lhk@dacl3.snu.ac.kr'" <lhk@dacl3.snu.ac.kr>,
        "'IanQ@Interconnect.co.nz'" <IanQ@Interconnect.co.nz>,
        "'osama.qadan@intelsat.int'" <osama.qadan@intelsat.int>,
        "'ted@siara.com'" <ted@siara.com>,
        "'naderv@email.msn.com'"
	 <naderv@email.msn.com>,
        "'m134514@er.uqam.ca'" <m134514@er.uqam.ca>,
        "'Moreau@tcl.ite.mee.com'" <Moreau@tcl.ite.mee.com>,
        "'marquet@ttt-atm.ttt.bme.hu'" <marquet@ttt-atm.ttt.bme.hu>,
        "'bsn@nexen.com'" <bsn@nexen.com>,
        "'arni@caip.rutgers.edu'"
	 <arni@caip.rutgers.edu>,
        "'daveg@psyton.com'" <daveg@psyton.com>,
        "'bakre@ccrl.sj.nec.com'" <bakre@ccrl.sj.nec.com>,
        "'szabo@david.ttt.bme.hu'" <szabo@david.ttt.bme.hu>,
        "'Aziz.Mohammed@aud.alcatel.com'" <Aziz.Mohammed@aud.alcatel.com>,
        "'kfowler@ironbridgenetworks.com'" <kfowler@ironbridgenetworks.com>,
        "'edusalomao@openlink.com.br'" <edusalomao@openlink.com.br>,
        "'jbuerkle@rtp-bosch.com'" <jbuerkle@rtp-bosch.com>,
        "'michelg@upperside.fr'" <michelg@upperside.fr>,
        "'higuchi@bnet.ts.fujitsu.co.jp'" <higuchi@bnet.ts.fujitsu.co.jp>,
        "'taka@ennovatenetworks.com'" <taka@ennovatenetworks.com>,
        "'mjackson@cw.net'" <mjackson@cw.net>,
        "'NKossack@aptis.com'"
	 <NKossack@aptis.com>,
        "'tian@siara.com'" <tian@siara.com>,
        "'iwidjaja@tddny.fujitsu.com'" <iwidjaja@tddny.fujitsu.com>,
        "'jscano@redstonecom.com'" <jscano@redstonecom.com>,
        "'thahler@UU.NET'"
	 <thahler@UU.NET>,
        "'demizu@dd.iij4u.or.jp'" <demizu@dd.iij4u.or.jp>,
        "'swhong@wh.myongji.ac.kr'" <swhong@wh.myongji.ac.kr>,
        "'fgarcia@ctc.cl'"
	 <fgarcia@ctc.cl>,
        "'Imran.Chowdhury@ascend.com'"
	 <Imran.Chowdhury@ascend.com>,
        "'jsullivan@quarrytech.com'"
	 <jsullivan@quarrytech.com>,
        "'st@cam.org'" <st@cam.org>,
        "'andyk@ambernetworks.com'" <andyk@ambernetworks.com>,
        "'pfronti@satec.es'" <pfronti@satec.es>,
        "'Brook.Crossman@Computerland.co.nz'" <Brook.Crossman@Computerland.co.nz>,
        "'beggs@us.ibm.com'" <beggs@us.ibm.com>,
        "'yuka@momo.core.ecl.net'"
	 <yuka@momo.core.ecl.net>,
        "'jgrandhi@ficon-tech.com'"
	 <jgrandhi@ficon-tech.com>,
        "'sydir@cplane.com'" <sydir@cplane.com>,
        "'pablo@lucent.com'" <pablo@lucent.com>,
        "'akyol@ieee.org'"
	 <akyol@ieee.org>,
        "'olle.ronnberg@ericsson.com'"
	 <olle.ronnberg@ericsson.com>,
        "'Kevin.Zhang@comsat.com'"
	 <Kevin.Zhang@comsat.com>,
        "'blaine@UU.NET'" <blaine@UU.NET>,
        "'terryc@newbridge.com'" <terryc@newbridge.com>,
        "'mcolven@netscape.net'"
	 <mcolven@netscape.net>,
        "'harry@meretrix.com'" <harry@meretrix.com>,
        "'ptr@msn.bt.co.uk'" <ptr@msn.bt.co.uk>, "'sav@unh.edu'" <sav@unh.edu>,
        "'cwaitzmann@alcatel.de'" <cwaitzmann@alcatel.de>,
        "'bpeters@torrentnet.com'" <bpeters@torrentnet.com>,
        "'sjahn@ics.uci.edu'" <sjahn@ics.uci.edu>,
        "'charles@hn-networks.co.uk'"
	 <charles@hn-networks.co.uk>,
        "'manis@future.futsoft.com'"
	 <manis@future.futsoft.com>,
        "'fioanid@panafon.gr'" <fioanid@panafon.gr>,
        "'javier@satec.es'" <javier@satec.es>,
        "'chlinton@nexabit.com'"
	 <chlinton@nexabit.com>,
        "'cbrown@tenornetworks.com'"
	 <cbrown@tenornetworks.com>,
        "'rajeev@siara.com'" <rajeev@siara.com>,
        "'durresi@cis.ohio-state.edu'" <durresi@cis.ohio-state.edu>,
        "'Christophe.Bouhier@etm.ericsson.se'"
	 <Christophe.Bouhier@etm.ericsson.se>,
        "'shimizu@ebina.hitachi.co.jp'"
	 <shimizu@ebina.hitachi.co.jp>,
        "'etxfili@etxb.ericsson.se'"
	 <etxfili@etxb.ericsson.se>,
        "'black@layer8.net'" <black@layer8.net>,
        "'jjmoran@nortelnetworks.com'" <jjmoran@nortelnetworks.com>,
        "'hans.sjostrand@etx.ericsson.se'" <hans.sjostrand@etx.ericsson.se>,
        "'fayaz@nortelnetworks.com'" <fayaz@nortelnetworks.com>,
        "'billh@hjinc.com'" <billh@hjinc.com>,
        "'tgraefe@newbridge.com'"
	 <tgraefe@newbridge.com>,
        "'btownsend@tenornetworks.com'"
	 <btownsend@tenornetworks.com>,
        "'sfr@ccci.com'" <sfr@ccci.com>,
        "'jlawson@redbacknetworks.com'" <jlawson@redbacknetworks.com>,
        "'nsko@mail.icu.ac.kr'" <nsko@ns.icu.ac.kr>,
        "'jayb@braeburn.org'"
	 <jayb@braeburn.org>,
        "'tone.ingvaldsen@telenor.com'"
	 <tone.ingvaldsen@telenor.com>,
        "'ed.stern@siroccosystems.com'"
	 <ed.stern@siroccosystems.com>,
        "'alex@uminho.pt'" <alex@uminho.pt>,
        "'mgudavalli@winstar.com'" <mgudavalli@winstar.com>,
        "'saula@hjinc.com'"
	 <saula@hjinc.com>,
        "'rajeshs@futsoft.com'" <rajeshs@futsoft.com>,
        "'mkhare@dtix.com'" <mkhare@dtix.com>,
        "'zm@chinascape.cn.net'"
	 <zm@chinascape.cn.net>,
        "'atow@home.net'" <atow@home.net>,
        "'Henrik.J.Villfor@telia.se'" <Henrik.J.Villfor@telia.se>,
        "'parker@saturnsystems.com'" <parker@saturnsystems.com>,
        "'post-mpls@partan.com'" <post-mpls@partan.com>,
        "'SJONES@IIRLTD.CO.UK'"
	 <SJONES@IIRLTD.CO.UK>,
        "'Lilian.Falkner@icn.siemens.de'"
	 <Lilian.Falkner@icn.siemens.de>,
        "'bchen@casc.com'" <bchen@casc.com>,
        "'walterw@UU.NET'" <walterw@UU.NET>,
        "'rsastry@casc.com'"
	 <rsastry@casc.com>,
        "'morton@nortelnetworks.com'"
	 <morton@nortelnetworks.com>,
        "'jaw@UU.NET'" <jaw@UU.NET>,
        "'prasanna@cromp.ernet.in'" <prasanna@cromp.ernet.in>,
        "'snigdho.bardalai@tddtx.fujitsu.com'"
	 <snigdho.bardalai@tddtx.fujitsu.com>,
        "'keyre@newbridge.com'"
	 <keyre@newbridge.com>,
        "'ushijima852@ainet.oki.co.jp'"
	 <ushijima852@ainet.oki.co.jp>,
        "'bbelling@bellsouth.net'"
	 <bbelling@bellsouth.net>,
        "'jpuderer@nortelnetworks.com'"
	 <jpuderer@nortelnetworks.com>,
        "'crawbuck@vnet.ibm.com'"
	 <crawbuck@vnet.ibm.com>,
        "'curtis@avici.com'" <curtis@avici.com>,
        "'jlloyd@raleigh.ibm.com'" <jlloyd@raleigh.ibm.com>,
        "'Robert.Curran@CRAMER.CO.UK'" <Robert.Curran@CRAMER.CO.UK>,
        "'starta@primenet.com'" <starta@primenet.com>,
        "'J.Williams@ftel.co.uk'"
	 <J.Williams@ftel.co.uk>,
        "'pbilling@nortelnetworks.com'"
	 <pbilling@nortelnetworks.com>,
        "'chase@nortelnetworks.com'"
	 <chase@nortelnetworks.com>,
        "'nbehki@newbridge.com'"
	 <nbehki@newbridge.com>,
        "'jchiong@cosinecom.com'"
	 <jchiong@cosinecom.com>,
        "'azhang@fore.com'" <azhang@fore.com>,
        "'dco@nortelnetworks.com'" <dco@nortelnetworks.com>,
        "'Benjamin.Abarbanel@adn.alcatel.com'"
	 <Benjamin.Abarbanel@adn.alcatel.com>,
        "'choi@paltek.co.jp'"
	 <choi@paltek.co.jp>,
        "'hjyun@etri.re.kr'" <hjyun@etri.re.kr>,
        "'kend@newbridge.com'" <kend@newbridge.com>,
        "'yy@qsun.ho.att.com'"
	 <yy@qsun.ho.att.com>,
        "'thomas@wolfram.net'" <thomas@wolfram.net>,
        "'yokung@lgic.co.kr'" <yokung@lgic.co.kr>,
        "'skhosla@atmcanada.com'"
	 <skhosla@atmcanada.com>,
        "'massadb@netscout.com'" <massadb@netscout.com>,
        "'burruss@ironbridgenetworks.com'" <burruss@ironbridgenetworks.com>,
        "'chong@stratumone.com'" <chong@stratumone.com>,
        "'sgriffiths@tenornetworks.com'" <sgriffiths@tenornetworks.com>,
        "'smiller@hjinc.com'" <smiller@hjinc.com>,
        "'AF@datcon.co.uk'"
	 <AF@datcon.co.uk>,
        "'akleineb@tfi.com'" <akleineb@tfi.com>,
        "'jonweil@nortelnetworks.com'" <jonweil@nortelnetworks.com>,
        "'fredk@tc.fluke.com'" <fredk@tc.fluke.com>,
        "'Tove_Madsen@baynetworks.com'" <Tove_Madsen@BayNetworks.COM>,
        "'Sergio.Verduci@icn.siemens.com'" <Sergio.Verduci@icn.siemens.com>,
        "'XDAT11@NAmerica.mot.com'" <XDAT11@NAmerica.mot.com>,
        "'shriharsha.hegde@intel.com'" <shriharsha.hegde@intel.com>,
        "'toivotuo@fishpool.com'" <toivotuo@fishpool.com>,
        "'nbitar@casc.com'"
	 <nbitar@casc.com>,
        "'sshah@ficon-tech.com'" <sshah@ficon-tech.com>,
        "'KRyon@ixc-comm.com'" <KRyon@ixc-comm.com>,
        "'harai@crl.go.jp'"
	 <harai@crl.go.jp>,
        "'gzs@clark.net'" <gzs@clark.net>,
        "'doleary@juniper.net'" <doleary@juniper.net>,
        "'markstahl@lucent.com'"
	 <markstahl@lucent.com>,
        "'kgalway@newbridge.com'"
	 <kgalway@newbridge.com>,
        "'poothon@eos.ncsu.edu'" <poothon@eos.ncsu.edu>,
        "'mkb@raistlin.min.ov.com'" <mkb@raistlin.min.ov.com>,
        "'chun@comeng.chungnam.ac.kr'" <chun@comeng.chungnam.ac.kr>,
        "'M.Muench@alcatel.de'" <M.Muench@alcatel.de>,
        "'mikey@lucent.com'"
	 <mikey@lucent.com>,
        "'Brian.Buggy@CRAMER.CO.UK'"
	 <Brian.Buggy@CRAMER.CO.UK>,
        "'hshah@nexabit.com'" <hshah@nexabit.com>, "'pfig@ip.pt'" <pfig@ip.pt>,
        "'karthik@fore.com'" <karthik@fore.com>,
        "'glauer@crescentnets.com'" <glauer@crescentnets.com>,
        "'rwestfall@abatis-sys.com'" <rwestfall@abatis-sys.com>,
        "'thierry.tribondeau@alcatel.fr'" <thierry.tribondeau@alcatel.fr>,
        "'aahaah@hotmail.com'" <aahaah@hotmail.com>,
        "'choid@ncr.disa.mil'"
	 <choid@ncr.disa.mil>,
        "'nodono@nttca.com'" <nodono@nttca.com>,
        "'numa@csc.melco.co.jp'" <numa@csc.melco.co.jp>,
        "'Vincent.Parfait@pt.nce.sita.int'" <Vincent.Parfait@pt.nce.sita.int>,
        "'meijen@lucent.com'" <meijen@lucent.com>,
        "'nwillhit@nortelnetworks.com'" <nwillhit@nortelnetworks.com>,
        "'henryc@mindspring.com'" <henryc@mindspring.com>,
        "'kwko@rcunix.kotel.co.kr'" <kwko@rcunix.kotel.co.kr>,
        "'vinay@jedi.luminousnetworks.com'" <vinay@jedi.luminousnetworks.com>,
        "'siddharth@alpha.dtix.com'" <siddharth@alpha.dtix.com>,
        "'ywang@UU.NET'"
	 <ywang@UU.NET>,
        "'mcmanus@appliedtheory.com'"
	 <mcmanus@appliedtheory.com>,
        "'kwakayam@crl.hitachi.co.jp'"
	 <kwakayam@crl.hitachi.co.jp>,
        "'os@online.no'" <os@online.no>,
        "'doukai@ss.ts.fujitsu.co.jp'" <doukai@ss.ts.fujitsu.co.jp>,
        "'toni@satec.es'" <toni@satec.es>,
        "'vszeto@nortelnetworks.com'"
	 <vszeto@nortelnetworks.com>,
        "'hsook@ns.hiper.co.kr'"
	 <hsook@ns.hiper.co.kr>,
        "'crawbuck@torrentnet.com'"
	 <crawbuck@torrentnet.com>,
        "'aparthas@nortelnetworks.com'"
	 <aparthas@nortelnetworks.com>,
        "'hjlee294@etri.re.kr'"
	 <hjlee294@etri.re.kr>,
        "'pasi.vaananen@nokia.com'"
	 <pasi.vaananen@nokia.com>,
        "'thomas.cornely@cnet.francetelecom.fr'"
	 <thomas.cornely@cnet.francetelecom.fr>,
        "'grs@nortelnetworks.com'"
	 <grs@nortelnetworks.com>,
        "'david.durham@intel.com'"
	 <david.durham@intel.com>,
        "'Jim_Loehndorf@asc1.com'"
	 <Jim_Loehndorf@asc1.com>,
        "'sehermit@nortelnetworks.com'"
	 <sehermit@nortelnetworks.com>,
        "'Joe_McGarvey@zd.com'"
	 <Joe_McGarvey@zd.com>,
        "'ccwang@earthlink.net'" <ccwang@earthlink.net>,
        "'dkw@ixc-comm.com'" <dkw@ixc-comm.com>,
        "'philou@philou.ch'"
	 <philou@philou.ch>,
        "'carson@antd.nist.gov'" <carson@antd.nist.gov>,
        "'antonela@nortelnetworks.com'" <antonela@nortelnetworks.com>,
        "'peter.lewis@upperside.fr'" <peter.lewis@upperside.fr>,
        "'AGUPTA@ambernetworks.com'" <AGUPTA@ambernetworks.com>,
        "'kini@dnrc.bell-labs.com'" <kini@dnrc.bell-labs.com>,
        "'yxu@ascend.com.hk'" <yxu@ascend.com.hk>,
        "'Diego.Caviglia@marconicomms.com'" <Diego.Caviglia@marconicomms.com>,
        "'ajun@comm.toronto.edu'" <ajun@comm.toronto.edu>,
        "'mreeves@newbridge.com'" <mreeves@newbridge.com>,
        "'sylor@concord.com'"
	 <sylor@concord.com>,
        "'HO@ambernetworks.com'" <HO@ambernetworks.com>,
        "'sunwlee@netlab.ce.kyungpook.ac.kr'" <sunwlee@netlab.ce.kyungpook.ac.kr>,
        "'harald.pettersen@telenor.com'" <harald.pettersen@telenor.com>,
        "'simon.f.carter@bt.com'" <simon.f.carter@bt.com>,
        "'swadhwa@redstonecom.com'" <swadhwa@redstonecom.com>,
        "'christer.svensson@broadswitch.com'" <christer.svensson@broadswitch.com>,
        "'kjohnson@uu.net'" <kjohnson@UU.NET>,
        "'kky_lee@yahoo.com'"
	 <kky_lee@yahoo.com>,
        "'mvb@miscrit.be'" <mvb@miscrit.be>,
        "'sudarsand@future.futsoft.com'" <sudarsand@future.futsoft.com>,
        "'Mangin@tcl.ite.mee.com'" <Mangin@tcl.ite.mee.com>,
        "'dcaplan@avici.com'" <dcaplan@avici.com>,
        "'eberspaecher@ind.uni-stuttgart.de'" <eberspaecher@ind.uni-stuttgart.de>,
        "'Fritz-Joachim.Westphal@telekom.de'" <Fritz-Joachim.Westphal@telekom.de>,
        "'dmorrell@juniper.net'" <dmorrell@juniper.net>,
        "'pchen@ennovatenetworks.com'" <pchen@ennovatenetworks.com>,
        "'jkarthik@avici.com'" <jkarthik@avici.com>,
        "'namura@ksw.ncos.nec.co.jp'" <namura@ksw.ncos.nec.co.jp>,
        "'kschroder@nexabit.com'" <kschroder@nexabit.com>,
        "'nandakb@future.futsoft.com'" <nandakb@future.futsoft.com>,
        "'pravinb@caip.rutgers.edu'" <pravinb@caip.rutgers.edu>,
        "'debopam@alpha.dtix.com'" <debopam@alpha.dtix.com>,
        "'sukeshgg@caip.rutgers.edu'" <sukeshgg@caip.rutgers.edu>,
        "'jdoyle@juniper.net'" <jdoyle@juniper.net>,
        "'cpignata@softnet.com.ar'"
	 <cpignata@softnet.com.ar>,
        "'Zakolskij@telbank.pl'"
	 <Zakolskij@telbank.pl>,
        "'mkontoff@avici.com'" <mkontoff@avici.com>,
        "'weiguo.wang@alcatel.com.sg'" <weiguo.wang@alcatel.com.sg>,
        "'jenny@nm3.ccl.itri.org.tw'" <jenny@nm4.ccl.itri.org.tw>,
        "'sean.murphy@Teltec.DCU.IE'" <sean.murphy@Teltec.DCU.IE>,
        "'ssingatw@nortelnetworks.com'" <ssingatw@nortelnetworks.com>,
        "'xing.chen@usa.alcatel.com'" <xing.chen@usa.alcatel.com>,
        "'fni@miscrit.be'" <fni@miscrit.be>,
        "'Wayne.Ding.wding@nortelnetworks.com'"
	 <Wayne.Ding.wding@nortelnetworks.com>,
        "'Gregory.Wright.gwright@nortelnetworks.com'"
	 <Gregory.Wright.gwright@nortelnetworks.com>,
        "'Michael.Chen.mchen@nortelnetworks.com'"
	 <Michael.Chen.mchen@nortelnetworks.com>,
        "'Liam.Casey.liam@nortelnetworks.com'"
	 <Liam.Casey.liam@nortelnetworks.com>,
        "'dallan@nortelnetworks.com'"
	 <dallan@nortelnetworks.com>,
        "'ballarte@nortelnetworks.com'"
	 <ballarte@nortelnetworks.com>,
        "'bryenton@nortelnetworks.com'"
	 <bryenton@nortelnetworks.com>,
        "'petera@nortelnetworks.com'"
	 <petera@nortelnetworks.com>,
        "'jamoussi@nortelnetworks.com'"
	 <jamoussi@nortelnetworks.com>,
        "'huiwc@nortelnetworks.com'"
	 <huiwc@nortelnetworks.com>,
        "'iduncan@nortelnetworks.com'"
	 <iduncan@nortelnetworks.com>,
        "'rachid@nortelnetworks.com'"
	 <rachid@nortelnetworks.com>,
        "'gerardp@nortelnetworks.com'"
	 <gerardp@nortelnetworks.com>,
        "'djamies@nortelnetworks.com'"
	 <djamies@nortelnetworks.com>,
        "'peter.atterton.atterton@nortelnetworks.com'"
	 <peter.atterton.atterton@nortelnetworks.com>,
        "'sdshew@nortelnetworks.com'" <sdshew@nortelnetworks.com>,
        "'sparmar@nortelnetworks.com'" <sparmar@nortelnetworks.com>,
        "'osama@nortelnetworks.com'" <osama@nortelnetworks.com>,
        "'leecy@nortelnetworks.com'" <leecy@nortelnetworks.com>,
        "'aabes@quarrytech.com'" <aabes@quarrytech.com>,
        "'dproch@fore.com'"
	 <dproch@fore.com>,
        "'wiztech@cmpnetmail.com'" <wiztech@cmpnetmail.com>,
        "'pathan@motispd.com'" <pathan@motispd.com>,
        "'h.kanayama@esc.longdist.ntt.co.jp'" <h.kanayama@esc.longdist.ntt.co.jp>,
        "'mpls-archive@lists.ietf.org'" <mpls-archive@ietf.org>,
        "'phoulik@redstonecom.com'" <phoulik@redstonecom.com>,
        "'marcf@us.ibm.com'" <marcf@us.ibm.com>,
        "'suchi@lcs.mit.edu'"
	 <suchi@lcs.mit.edu>,
        "'roland_yeo@nus.edu.sg'" <roland_yeo@nus.edu.sg>,
        "'derek@wireless.stanford.edu'" <derek@wireless.stanford.edu>,
        "'ssevans@nortelnetworks.com'" <ssevans@nortelnetworks.com>,
        "'nafea@galileo.co.il'" <nafea@galileo.co.il>,
        "'ytq@sz.huawei.com.cn'"
	 <ytq@mail.huawei.com.cn>,
        "'shbiswas@nortelnetworks.com'"
	 <shbiswas@nortelnetworks.com>,
        "'kaifu@3com.com'" <kaifu@3com.com>,
        "'ietf-mpls-newsgate@nntp.cig.mot.com'"
	 <ietf-mpls-newsgate@nntp.cig.mot.com>,
        "'JonDuri.Sarott@broadnet.ascom.ch'" <JonDuri.Sarott@broadnet.ascom.ch>,
        "'sanjayk@dnrc.bell-labs.com'" <sanjayk@dnrc.bell-labs.com>,
        "'tom.ruban@gmx.net'" <tom.ruban@gmx.net>,
        "'jagnese@northpoint.net'"
	 <jagnese@northpoint.net>,
        "'akshat@daewoo.dti.daewoo.co.kr'"
	 <akshat@daewoo.dti.daewoo.co.kr>,
        "'javigon@nortelnetworks.com'"
	 <javigon@nortelnetworks.com>,
        "'pschlatt@nt.hirschmann.de'"
	 <pschlatt@nt.hirschmann.de>,
        "'raj@redback.com'" <raj@redback.com>,
        "'etxmacu@etxb.ericsson.se'" <etxmacu@etxb.ericsson.se>,
        "'jeanlou.dupont@na.marconicomms.com'"
	 <jeanlou.dupont@na.marconicomms.com>,
        "'work@pack.org'" <work@pack.org>, "'eshee@att.com'" <eshee@att.com>,
        "'pkj@cypress.com'" <pkj@cypress.com>,
        "'dparaje@teleline.es'" <dparaje@teleline.es>,
        "'Ignas.Bagdonas@sc.vu.lt'" <Ignas.Bagdonas@sc.vu.lt>,
        "'vknu@otol.fi'"
	 <vknu@otol.fi>,
        "'rksingh@hss.hns.com'" <rksingh@hss.hns.com>,
        "'ghassansemaan@yahoo.com'" <ghassansemaan@yahoo.com>,
        "'abe.shin@mti.longdist.ntt.co.jp'" <abe.shin@mti.longdist.ntt.co.jp>,
        "'Jani.M.Kokkonen@nokia.com'" <Jani.M.Kokkonen@nokia.com>,
        "'damien.collart@win.be'" <damien.collart@win.be>,
        "'qv@juniper.net'"
	 <qv@juniper.net>,
        "'mland@cignal.com'" <mland@cignal.com>,
        "'chaitk@Exchange.Microsoft.com'" <chaitk@Exchange.Microsoft.com>,
        "'parksy@ccs.sogang.ac.kr'" <parksy@ccs.sogang.ac.kr>,
        "'teruyuki@bcd.abk.nec.co.jp'" <teruyuki@bcd.abk.nec.co.jp>,
        "'Alexander.Marhold@xandl.cso.net'" <Alexander.Marhold@xandl.cso.net>,
        "'yhkim@etri.re.kr'" <yhkim@etri.re.kr>,
        "'shung@allayer.com'"
	 <shung@allayer.com>,
        "'Sudhanshu.Jain@lucent.com'"
	 <Sudhanshu.Jain@lucent.com>,
        "'ricardo.gerbolesespina@telefonica.es'"
	 <ricardo.gerbolesespina@telefonica.es>,
        "'Jean.Conti@swisscom.com'"
	 <Jean.Conti@swisscom.com>,
        "'jreister@coppermountain.com'"
	 <jreister@coppermountain.com>,
        "'lberger@labn.net'" <lberger@labn.net>,
        "'David_Ready@tenornetworks.com'" <David_Ready@tenornetworks.com>,
        "'okim@telperion-net.com'" <okim@telperion-net.com>,
        "'ayyangar@apollo.mctr.umbc.edu'" <ayyangar@apollo.mctr.umbc.edu>,
        "'jmedlock@TenorNetworks.com'" <jmedlock@tenornetworks.com>,
        "'adunstan@avici.com'" <adunstan@avici.com>,
        "'yoon.chang@nist.gov'"
	 <yoon.chang@nist.gov>,
        "'tanun@ee.eng.chula.ac.th'"
	 <tanun@ee.eng.chula.ac.th>,
        "'gabriele@prz.tu-berlin.de'"
	 <gabriele@prz.tu-berlin.de>,
        "'chitrapu@cotton.vislab.olemiss.edu'"
	 <chitrapu@cotton.vislab.olemiss.edu>,
        "'mhospoda@rocs.com'"
	 <mhospoda@rocs.com>,
        "'jquinn@compd.com'" <jquinn@compd.com>,
        "'jinsuh@dcn.soongsil.ac.kr'" <jinsuh@dcn.soongsil.ac.kr>,
        "'Dirk.Maeckelberghe@swift.com'" <Dirk.Maeckelberghe@swift.com>,
        "'rramos@euskaltel.es'" <rramos@euskaltel.es>,
        "'James.Fu@tellabs.com'"
	 <James.Fu@tellabs.com>,
        "'achal@ipmobile.com'" <achal@ipmobile.com>,
        "'chris@algx.net'" <chris@algx.net>,
        "'natalie.c.ramsay@adn.alcatel.com'"
	 <natalie.c.ramsay@adn.alcatel.com>,
        "'James.Cheng@fnc.fujitsu.com'"
	 <James.Cheng@fnc.fujitsu.com>,
        "'zzhang@argon.com'" <zzhang@argon.com>,
        "'kojima@sst.abk.nec.co.jp'" <kojima@sst.abk.nec.co.jp>,
        "'fsalazar@corp.netcom.ca'" <fsalazar@corp.netcom.ca>,
        "'ramy@nortelnetworks.com'" <ramy@nortelnetworks.com>,
        "'ppatel@ipmobile.com'" <ppatel@ipmobile.com>,
        "'ShenXulei@sbell.com.cn'"
	 <ShenXulei@sbell.com.cn>,
        "'gash@att.com'" <gash@att.com>, "'jwhyte@UU.NET'" <jwhyte@UU.NET>,
        "'kdegraaf@argon.com'"
	 <kdegraaf@argon.com>,
        "'pavel@nortelnetworks.com'"
	 <pavel@nortelnetworks.com>,
        "'jsugg@juniper.net'" <jsugg@juniper.net>,
        "'christiane@trt6.gov.br'" <christiane@trt6.gov.br>,
        "'nishant@nortelnetworks.com'" <nishant@nortelnetworks.com>,
        "'stacy@ixc-comm.com'" <stacy@ixc-comm.com>,
        "'mmathew@nortelnetworks.com'" <mmathew@nortelnetworks.com>,
        "'rshekhar@redstonecom.com'" <rshekhar@redstonecom.com>,
        "'prz@siara.com'" <prz@siara.com>,
        "'Frank_Kerremans@baynetworks.com'"
	 <Frank_Kerremans@BayNetworks.COM>,
        "'cheng@motispd.com'"
	 <cheng@motispd.com>,
        "'duan@cs.umn.edu'" <duan@cs.umn.edu>,
        "'prabakarts@future.futsoft.com'" <prabakarts@future.futsoft.com>,
        "'AB@datcon.co.uk'" <AB@datcon.co.uk>,
        "'gikas@csi.forth.gr'"
	 <gikas@csi.forth.gr>,
        "'dbruns@brutus.demon.digex.net'"
	 <dbruns@brutus.demon.digex.net>,
        "'rfrancis@fore.com'"
	 <rfrancis@fore.com>,
        "'jhkim@dmc.htc.hanwha.co.kr'"
	 <jhkim@dmc.htc.hanwha.co.kr>,
        "'reese@access1.digex.net'"
	 <reese@access1.digex.net>,
        "'Luca.DeMatteis@CRAMER.CO.UK'"
	 <Luca.DeMatteis@CRAMER.CO.UK>,
        "'Don.Frey@fnc.fujitsu.com'"
	 <Don.Frey@fnc.fujitsu.com>,
        "'mkarasek@anect.cz'" <mkarasek@anect.cz>,
        "'cchen@asl.dl.nec.com'" <cchen@asl.dl.nec.com>,
        "'pramodh@ittc.ukans.edu'" <pramodh@ittc.ukans.edu>,
        "'VijayK@ambernetworks.com'" <VijayK@ambernetworks.com>,
        "'jfneu@newbridge.com'" <jfneu@newbridge.com>,
        "'lgao@public.bta.net.cn'"
	 <lgao@public.bta.net.cn>,
        "'jixh@chinascape.cn.net'"
	 <jixh@chinascape.cn.net>,
        "'willems@lucent.com'" <willems@lucent.com>,
        "'radriaan@nortelnetworks.com'" <radriaan@nortelnetworks.com>,
        "'Mark.Bath@RacalInternet.com'" <Mark.Bath@RacalInternet.com>,
        "'dmbrooks@lucent.com'" <dmbrooks@lucent.com>,
        "'mld@dks.se'"
	 <mld@dks.se>,
        "'jesus.garcia@b3telecom.fr'" <jesus.garcia@b3telecom.fr>,
        "'sushma@yagosys.com'" <sushma@yagosys.com>,
        "'tomkri@freya.unik.no'"
	 <tomkri@freya.unik.no>,
        "'petzi@apfel.de'" <petzi@apfel.de>,
        "'eng@allayer.com'" <eng@allayer.com>,
        "'jkchoi@icu.ac.kr'"
	 <jkchoi@icu.ac.kr>,
        "'mpls@apollo.mctr.umbc.edu'"
	 <mpls@apollo.mctr.umbc.edu>,
        "'raor@techmail.gdc.com'"
	 <raor@techmail.gdc.com>,
        "'iokumus@mailbox.syr.edu'"
	 <iokumus@mailbox.syr.edu>,
        "'dwood@digex.net'" <dwood@digex.net>,
        "'vatsa@fore.com'" <vatsa@fore.com>,
        "'bohallor@nortelnetworks.com'"
	 <bohallor@nortelnetworks.com>,
        "'miroslav.vrana@alcatel.be'"
	 <miroslav.vrana@alcatel.be>,
        "'Patrik.Evaldsson@era-t.ericsson.se'"
	 <Patrik.Evaldsson@era-t.ericsson.se>,
        "'albin@owl.frontier.com'"
	 <albin@owl.frontier.com>,
        "'sridhar@samsung.co.kr'"
	 <sridhar@samsung.co.kr>,
        "'mike.frietman@icoe.att.com'"
	 <mike.frietman@icoe.att.com>,
        "'Jan.van.der.Graaf@bcn.ericsson.se'"
	 <Jan.van.der.Graaf@bcn.ericsson.se>,
        "'etxmibu@etxb.ericsson.se'"
	 <etxmibu@etxb.ericsson.se>,
        "'RNewcomb@invernessinc.com'"
	 <RNewcomb@invernessinc.com>,
        "'suelin@vnet.ibm.com'"
	 <suelin@vnet.ibm.com>,
        "'hao@owl.wpi.edu'" <hao@cs.WPI.EDU>,
        "'myang@abaqos.com'" <myang@abaqos.com>,
        "'NPW@datcon.co.uk'"
	 <NPW@datcon.co.uk>,
        "'bugalloh@metrored.com.ar'"
	 <bugalloh@metrored.com.ar>,
        "'Kenneth.Hann@tellabs.fi'"
	 <Kenneth.Hann@tellabs.fi>,
        "'gbnaidu@sasi.com'" <gbnaidu@sasi.com>,
        "'Muhammad.Sarwar@tddny.fujitsu.com'" <Muhammad.Sarwar@tddny.fujitsu.com>,
        "'dai@IRI.co.jp'" <dai@iri.co.jp>,
        "'vsinha@fore.com'" <vsinha@fore.com>,
        "'gregs@prioritycall.com'" <gregs@prioritycall.com>,
        "'jparsons@bbnplanet.com'" <jparsons@bbnplanet.com>,
        "'snyder@RedBackNetworks.com'" <snyder@redbacknetworks.com>,
        "'ostokes@extremenetworks.com'" <ostokes@extremenetworks.com>,
        "'WTu@PRIMUSTEL.com'" <WTu@PRIMUSTEL.com>,
        "'molendin@ultra5.unile.it'"
	 <molendin@ultra5.unile.it>,
        "'mtaira@logicaleffect.com'"
	 <mtaira@logicaleffect.com>,
        "'Ramana_Gollamudi@Newbridge.COM'"
	 <Ramana_Gollamudi@newbridge.com>,
        "'h.hopkins@accent-on-networks.co.uk'"
	 <h.hopkins@accent-on-networks.co.uk>,
        "'fredrik@it.kth.se'"
	 <fredrik@it.kth.se>,
        "'sten.nordell@utfors.se'" <sten.nordell@utfors.se>,
        "'MLTeng@aol.com'" <MLTeng@aol.com>,
        "'vanik@future.futsoft.com'"
	 <vanik@future.futsoft.com>,
        "'russmanr@psi.com'" <russmanr@psi.com>,
        "'muhammad@ctr.columbia.edu'" <muhammad@ctr.columbia.edu>,
        "'ceylan@ece.uci.edu'" <ceylan@ece.uci.edu>,
        "'ojas@ipmobile.com'"
	 <ojas@ipmobile.com>,
        "'ananda@dtix.com'" <ananda@dtix.com>,
        "'sduggal@inktomi.com'" <sduggal@inktomi.com>,
        "'takenaga@pkt.ts.fujitsu.co.jp'" <takenaga@pkt.ts.fujitsu.co.jp>,
        "'cflores@ixc-comm.com'" <cflores@ixc-comm.com>,
        "'clitvan@advtech.uswest.com'" <clitvan@advtech.uswest.com>,
        "'vjshah@nortelnetworks.com'" <vjshah@nortelnetworks.com>,
        "'tnlan@gmx.net'" <tnlan@gmx.net>,
        "'dwfedyk@nortelnetworks.com'"
	 <dwfedyk@nortelnetworks.com>,
        "'neetug@daewoo.dti.daewoo.co.kr'"
	 <neetug@daewoo.dti.daewoo.co.kr>,
        "'gkhera@nortelnetworks.com'"
	 <gkhera@nortelnetworks.com>,
        "'manu.prakash@xylan.com'"
	 <manu.prakash@xylan.com>,
        "'crimson@gweep.net'" <crimson@gweep.net>,
        "'tor@redback.com'" <tor@redback.com>,
        "'nzvaig@adtech-inc.com'"
	 <nzvaig@adtech-inc.com>,
        "'rmanur@ncorenetworks.com'"
	 <rmanur@ncorenetworks.com>,
        "'yun@trd.tmg.nec.co.jp'"
	 <yun@trd.tmg.nec.co.jp>,
        "'sdey@dtix.com'" <sdey@dtix.com>,
        "'timm@tenornetworks.com'" <timm@tenornetworks.com>,
        "'bill@wizard.gsfc.nasa.gov'" <bill@wizard.nasa.atd.net>,
        "'kisikawa@mxk.mesh.ne.jp'" <kisikawa@mxk.mesh.ne.jp>,
        "'inas.said@nokia.com'" <inas.said@nokia.com>,
        "'sumimoto.junichi@lab.ntt.co.jp'" <sumimoto.junichi@lab.ntt.co.jp>,
        "'JBadd@bclnz.co.nz'" <JBadd@bclnz.co.nz>,
        "'Robert.Shaw@itu.int'"
	 <Robert.Shaw@itu.int>,
        "'Alex.Rosenbaum@predictive.com'"
	 <Alex.Rosenbaum@predictive.com>,
        "'fowler@syndesis.com'"
	 <fowler@syndesis.com>,
        "'ren@appiancom.com'" <ren@appiancom.com>,
        "'asr@latency.net'" <asr@latency.net>,
        "'n-kobayasi@fdt.ts.fujitsu.co.jp'" <n-kobayasi@fdt.ts.fujitsu.co.jp>,
        "'EKrainov@microtest.ru'" <EKrainov@microtest.ru>,
        "'afuellemann@unisphere.cc'" <afuellemann@unisphere.cc>,
        "'kireeti@juniper.net'" <kireeti@juniper.net>,
        "'gmlee@icu.ac.kr'"
	 <gmlee@icu.ac.kr>,
        "'dkatz@juniper.net'" <dkatz@juniper.net>,
        "'csocso@sch.bme.hu'" <csocso@sch.bme.hu>,
        "'shuli@UU.NET'"
	 <shuli@UU.NET>,
        "'mirzaa@nortelnetworks.com'"
	 <mirzaa@nortelnetworks.com>,
        "'allank@packetcom.com'"
	 <allank@packetcom.com>,
        "'bfox@equipecom.com'" <bfox@equipecom.com>,
        "'mjork@avici.com'" <mjork@avici.com>,
        "'Faycal.Bennani@enst.fr'"
	 <Faycal.Bennani@enst.fr>,
        "'Laxman@ambernetworks.com'"
	 <Laxman@ambernetworks.com>,
        "'Ben.Mack-Crane@tellabs.com'"
	 <Ben.Mack-Crane@tellabs.com>
Subject: Call For Papers: IEEE Network Magazine special issue on IP over F
	iber
Date: Wed, 16 Aug 2000 14:58:25 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C007CD.1EF31A74"

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_01C007CD.1EF31A74
Content-Type: text/plain;
	charset="iso-8859-1"

http://www.comsoc.org/socstr/techcom/ntwrk/special/ip-over-fiber.html
Call For Papers 
IEEE Network Magazine
Special Issue on IP Over Fiber
Guest Editors:
Dr. Debanjan Saha, Tellium Optical Networks Systems, 2 Crescent Place,
Oceanport NJ 07757-0901
      Phone: (732) 923-4264, Fax: (732) 923-9804, Email: dsaha@tellium.com
Dr. Nasir Ghani, Sorrento Networks Inc., 9990 Mesa Rim Road, San Diego, CA
92121
     Phone: (858) 646-7192, Fax: (858) 558-3980, Email:
nghani@sorrentonet.com
Scope:
Recent advances in optical technologies have opened up a world of new
opportunities. Optical networks offer virtually unlimited bandwidth, a very
important ingredient for sustaining the organic and explosive growth of the
Internet. Massive deployment of optical networking gear is already underway
in long-haul networks. Falling component costs have also made metro and
access arena deployment prospects increasingly viable. In light of this new
technological trend "IP over Fiber" has become a topic of unprecedented
interest in academia and industry alike.
It is widely expected that the convergence of IP and Optical layers will be
the defining theme in the next phase of expansion of the Internet. The
emergence of the IP multi-protocol label switching (MPLS) framework as a
common control plane for data and optical layers is an early, but definitive
indication of that trend. This is clearly going to influence how future
network elements are designed, and how the networks are architected,
engineered and managed. A number of vendors are developing "hybrid" devices
that integrate IP and optical networking technologies in very innovative
ways. Various service providers are architecting their networks around these
new "convergent" network elements and planning for cost-effective migration
strategies from the current TDM-based infrastructures to the network of the
future. 
In order to gain a better understanding of this exciting new field of
telecommunications, this special issue of IEEE Network Magazine seeks to
survey, consolidate, and present the leading-edge research and engineering
work in the IP-over-fiber space. In particular, focused tutorial and survey
contributions are solicited on (but not restricted to) the following subject
categories: 
*	Multi-protocol Lambda Switching 
*	Traffic engineering across optical and data planes 
*	Constraint based lightpath routing 
*	IP routing protocol enhancements for lightpath routing 
*	Signaling protocols for lightpath provisioning 
*	IP centric restoration schemes for lightpaths 
*	Convergent network architectures, hybrid network elements 
*	IP centric service and network management solutions 
*	Migration and deployment scenarios/solutions 
*	Test-bed implementations, network trials, and related experimental
projects. 
Submission:
We plan to use electronic submission in either PostScript (.ps) or PDF file
formats. In order to submit a paper for consideration, authors should send
the following information to the guest editors via email (dsaha@tellium.com
<mailto:dsaha@tellium.com> and nghani@sorrentonet.com
<mailto:nghani@sorrentonet.com>)
	Title, Abstract of the paper and list of authors. 
	Indicate which author is to serve as the primary correspondence
contact. 
	Please list affiliation, mailing address, phone/fax numbers, and
email address of the correspondence author. 
The correspondence author will then be provided with instructions to upload
the paper at a Website.
In order to ensure that the PostScript versions of the papers can be
printed, please use PostScript Version 2 or later. Also ensure that the
paper fits on "US Letter" size paper (8.5x11 inches). Reference only
Computer Modern or standard Adobe printer fonts (i.e., Courier, Times,
Roman, or Helvetica); other fonts may be used but must be included in the
PostScript file. 
Additional information including "Guidelines for authors" is available at
the IEEE Network Website:
<http://www.comsoc.org/socstr/techcom/ntwrk/authors.html>
Schedule: 
*	Paper Submission Deadline: November 15, 2000 
*	Feedback to Authors: February 15, 2001 
*	Final Manuscripts to Publisher: April 15, 2001 
*	Publication of Special Issue: July/August 2001 



------_=_NextPart_001_01C007CD.1EF31A74
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>Call For Papers: IEEE Network Magazine special issue on IP over =
Fiber</TITLE>
</HEAD>
<BODY>

<P><FONT FACE=3D"Times New Roman"><A =
HREF=3D"http://www.comsoc.org/socstr/techcom/ntwrk/special/ip-over-fiber=
.html" =
TARGET=3D"_blank">http://www.comsoc.org/socstr/techcom/ntwrk/special/ip-=
over-fiber.html</A></FONT>

<P ALIGN=3DCENTER><B><I><FONT SIZE=3D5 FACE=3D"Times New Roman">Call =
For Papers</FONT></I><BR>
<FONT SIZE=3D5 FACE=3D"Times New Roman">IEEE Network =
Magazine</FONT></B></P>

<P ALIGN=3DCENTER><B><FONT SIZE=3D5 FACE=3D"Times New Roman">Special =
Issue on IP Over Fiber</FONT></B></P>

<P><B><FONT SIZE=3D4 FACE=3D"Times New Roman">Guest Editors:</FONT></B>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Dr. Debanjan Saha, Tellium Optical =
Networks Systems, 2 Crescent Place, Oceanport NJ 07757-0901</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Phone: =
(732) 923-4264, Fax: (732) 923-9804, Email: dsaha@tellium.com</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Dr. Nasir Ghani, Sorrento Networks =
Inc., 9990 Mesa Rim Road, San Diego, CA 92121</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; Phone: (858) =
646-7192, Fax: (858) 558-3980, Email: =
nghani@sorrentonet.com</FONT><B></B><B></B><B></B>
<BR><B><FONT SIZE=3D4 FACE=3D"Times New Roman">Scope:</FONT></B>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Recent advances in optical =
technologies have opened up a world of new opportunities. Optical =
networks offer virtually unlimited bandwidth, a very important =
ingredient for sustaining the organic and explosive growth of the =
Internet. Massive deployment of optical networking gear is already =
underway in long-haul networks. Falling component costs have also made =
metro and access arena deployment prospects increasingly viable. In =
light of this new technological trend &quot;IP over Fiber&quot; has =
become a topic of unprecedented interest in academia and industry =
alike.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">It is widely expected that the =
convergence of IP and Optical layers will be the defining theme in the =
next phase of expansion of the Internet. The emergence of the =
IP</FONT><I> <FONT SIZE=3D2 FACE=3D"Arial">multi-protocol label =
switching</FONT></I> <FONT SIZE=3D2 FACE=3D"Arial">(MPLS) framework as =
a common control plane for data and optical layers is an early, but =
definitive indication of that trend. This is clearly going to influence =
how future network elements are designed, and how the networks are =
architected, engineered and managed. A number of vendors are developing =
&quot;hybrid&quot; devices that integrate IP and optical networking =
technologies in very innovative ways. Various service providers are =
architecting their networks around these new &quot;convergent&quot; =
network elements and planning for cost-effective migration strategies =
from the current TDM-based infrastructures to the network of the =
future. </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">In order to gain a better =
understanding of this exciting new field of telecommunications, this =
special issue of</FONT><I> <FONT SIZE=3D2 FACE=3D"Arial">IEEE Network =
Magazine</FONT></I><FONT SIZE=3D2 FACE=3D"Arial"> seeks to survey, =
consolidate, and present the leading-edge research and engineering work =
in the IP-over-fiber space. In particular, focused tutorial and survey =
contributions are solicited on (but not restricted to) the following =
subject categories: </FONT></P>
<UL>
<UL><LI><FONT SIZE=3D2 FACE=3D"Arial">Multi-protocol Lambda =
Switching</FONT> </LI>
<LI><FONT SIZE=3D2 FACE=3D"Arial">Traffic engineering across optical =
and data planes</FONT> </LI>
<LI><FONT SIZE=3D2 FACE=3D"Arial">Constraint based lightpath =
routing</FONT> </LI>
<LI><FONT SIZE=3D2 FACE=3D"Arial">IP routing protocol enhancements for =
lightpath routing</FONT> </LI>
<LI><FONT SIZE=3D2 FACE=3D"Arial">Signaling protocols for lightpath =
provisioning</FONT> </LI>
<LI><FONT SIZE=3D2 FACE=3D"Arial">IP centric restoration schemes for =
lightpaths</FONT> </LI>
<LI><FONT SIZE=3D2 FACE=3D"Arial">Convergent network architectures, =
hybrid network elements</FONT> </LI>
<LI><FONT SIZE=3D2 FACE=3D"Arial">IP centric service and network =
management solutions</FONT> </LI>
<LI><FONT SIZE=3D2 FACE=3D"Arial">Migration and deployment =
scenarios/solutions</FONT> </LI>
<LI><FONT SIZE=3D2 FACE=3D"Arial">Test-bed implementations, network =
trials, and related experimental projects.</FONT><FONT FACE=3D"Times =
New Roman"> </FONT></LI>
</UL></UL>
<P><B><FONT FACE=3D"Times New Roman">Submission:</FONT></B>
<BR><FONT SIZE=3D2 FACE=3D"Arial">We plan to use electronic submission =
in either PostScript (.ps) or PDF file formats. In order to submit a =
paper for consideration, authors should send the following information =
to the guest editors via email (<U></U></FONT><U><FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">dsaha@tellium.com &lt;<A =
HREF=3D"mailto:dsaha@tellium.com">mailto:dsaha@tellium.com</A>&gt;</FONT=
></U><FONT SIZE=3D2 FACE=3D"Arial"> and</FONT><U> <FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">nghani@sorrentonet.com &lt;<A =
HREF=3D"mailto:nghani@sorrentonet.com">mailto:nghani@sorrentonet.com</A>=
&gt;</FONT></U><FONT SIZE=3D2 FACE=3D"Arial">)</FONT></P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">Title, Abstract of the paper and list =
of authors. </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Indicate which author is to serve as =
the primary correspondence contact. </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Please list affiliation, mailing =
address, phone/fax numbers, and email address of the correspondence =
author. </FONT>
</UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">The correspondence author will then be =
provided with instructions to upload the paper at a Website.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">In order to ensure that the =
PostScript versions of the papers can be printed, please use PostScript =
Version 2 or later. Also ensure that the paper fits on &quot;US =
Letter&quot; size paper (8.5x11 inches). Reference only Computer Modern =
or standard Adobe printer fonts (i.e., Courier, Times, Roman, or =
Helvetica); other fonts may be used but must be included in the =
PostScript file.<BR>
Additional information including &quot;Guidelines for authors&quot; is =
available at the IEEE Network Website:</FONT><U> <FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">&lt;<A =
HREF=3D"http://www.comsoc.org/socstr/techcom/ntwrk/authors.html" =
TARGET=3D"_blank">http://www.comsoc.org/socstr/techcom/ntwrk/authors.htm=
l</A>&gt;</FONT></U></P>

<P><B><FONT FACE=3D"Times New Roman">Schedule:</FONT></B><FONT =
FACE=3D"Times New Roman"> </FONT>
<UL>
<UL><LI><FONT SIZE=3D2 FACE=3D"Arial">Paper Submission Deadline: =
November 15, 2000</FONT> </LI>
<LI><FONT SIZE=3D2 FACE=3D"Arial">Feedback to Authors: February 15, =
2001</FONT> </LI>
<LI><FONT SIZE=3D2 FACE=3D"Arial">Final Manuscripts to Publisher: April =
15, 2001</FONT><FONT FACE=3D"Times New Roman"> </FONT></LI>
<LI><FONT SIZE=3D2 FACE=3D"Arial">Publication of Special Issue: =
July/August 2001</FONT><FONT FACE=3D"Times New Roman"> </FONT></LI>
<BR>
<BR>
</UL></UL>
</BODY>
</HTML>
------_=_NextPart_001_01C007CD.1EF31A74--


From owner-mpls@UU.NET  Thu Aug 17 05:46:48 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22813
	for <mpls-archive@lists.ietf.org>; Thu, 17 Aug 2000 05:46:48 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcpr24577;
	Thu, 17 Aug 2000 09:45:20 GMT
Received: by mail-control.mail.uu.net 
	id QQjcpq03841
	for mpls-outgoing; Thu, 17 Aug 2000 09:44:45 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjcpq03821
	for <mpls@mail-control.mail.uu.net>; Thu, 17 Aug 2000 09:44:36 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjcpq24053;
	Thu, 17 Aug 2000 05:44:18 -0400 (EDT)
Received: from coltrane.datcon.co.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtp.datcon.co.uk [192.91.191.4])
	id QQjcpq04735;
	Thu, 17 Aug 2000 09:44:03 GMT
Received: by smtp.datcon.co.uk with Internet Mail Service (5.5.2650.21)
	id <PDN0YG8L>; Thu, 17 Aug 2000 10:44:00 +0100
Message-ID: <6DEA508A9A0ED31192E80000F6CC176E2C9EFC@monk.datcon.co.uk>
From: Adrian Farrel <AF@datcon.co.uk>
To: Kireeti Kompella <kireeti@juniper.net>
Cc: mpls@UU.NET, te-wg@UU.NET
Subject: draft-kompella-mpls-te-mib-00.txt
Date: Thu, 17 Aug 2000 10:43:49 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Kireeti,

Having missed out on the tewg meeting in Pittsburgh and been unable to find
any minutes, I wonder if you could update us all on the status of this
draft.

I'm aware that there was some concern in the run-up to Pittsburgh that your
draft had considerable overlap with the MIB drafts in the mplswg.  Could you
summarize the current state of this debate for us on the list so that we can
move forward.

Thanks for your help.
Regards,
Adrian
--
Adrian Farrel  mailto:af@datcon.co.uk
Network Convergence Group
Data Connection Ltd., Chester, UK
http://www.datcon.co.uk/
Tel: +44 (0) 1244 313440  Fax: +44 (0) 1244 312422


From owner-mpls@UU.NET  Thu Aug 17 07:01:34 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23423
	for <mpls-archive@lists.ietf.org>; Thu, 17 Aug 2000 07:01:33 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcpv22273;
	Thu, 17 Aug 2000 10:59:56 GMT
Received: by mail-control.mail.uu.net 
	id QQjcpv22515
	for mpls-outgoing; Thu, 17 Aug 2000 10:59:25 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjcpv22510
	for <mpls@mail-control.mail.uu.net>; Thu, 17 Aug 2000 10:59:09 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjcpv07641
	for <mpls@uu.net>; Thu, 17 Aug 2000 06:58:49 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjcpv21405
	for <mpls@uu.net>; Thu, 17 Aug 2000 10:58:48 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA21419
	for mpls@uu.net; Thu, 17 Aug 2000 06:58:48 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjcpv22479
	for <mpls@mail-control.mail.uu.net>; Thu, 17 Aug 2000 10:58:08 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjcpv07534
	for <mpls@uu.net>; Thu, 17 Aug 2000 06:58:01 -0400 (EDT)
Received: from ietf.org by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: odin.ietf.org [132.151.1.176])
	id QQjcpv20934
	for <mpls@uu.net>; Thu, 17 Aug 2000 10:58:00 GMT
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23311;
	Thu, 17 Aug 2000 06:57:59 -0400 (EDT)
Message-Id: <200008171057.GAA23311@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;
Cc: mpls@UU.NET
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mpls-ldp-10.txt
Date: Thu, 17 Aug 2000 06:57:59 -0400
Sender: owner-mpls@UU.NET
Precedence: bulk

--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		: LDP Specification
	Author(s)	: L. Andersson, P. Doolan, N. Feldman,
                          A. Fredette, B. Thomas
	Filename	: draft-ietf-mpls-ldp-10.txt
	Pages		: 135
	Date		: 16-Aug-00
	
The architecture for Multi Protocol Label Switching (MPLS) is
described in [ARCH].  A fundamental concept in MPLS is that two Label
Switching Routers (LSRs) must agree on the meaning of the labels used
to forward traffic between and through them.  This common
understanding is achieved by using a set of procedures, called a
label distribution protocol, by which one LSR informs another of
label bindings it has made.  This document defines a set of such
procedures called LDP (for Label Distribution Protocol) by which LSRs
distribute labels to support MPLS forwarding along normally routed
paths [LDPAPPLIC].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-10.txt

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-ldp-10.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-ldp-10.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:	<20000816143949.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mpls-ldp-10.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mpls-ldp-10.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000816143949.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-mpls@UU.NET  Thu Aug 17 07:11:53 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23516
	for <mpls-archive@lists.ietf.org>; Thu, 17 Aug 2000 07:11:53 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcpw28727;
	Thu, 17 Aug 2000 11:10:24 GMT
Received: by mail-control.mail.uu.net 
	id QQjcpw04940
	for mpls-outgoing; Thu, 17 Aug 2000 11:09:45 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjcpw04935
	for <mpls@mail-control.mail.uu.net>; Thu, 17 Aug 2000 11:09:29 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjcpw09043
	for <mpls@uu.net>; Thu, 17 Aug 2000 07:09:24 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjcpw27914
	for <mpls@uu.net>; Thu, 17 Aug 2000 11:09:08 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id HAA22400
	for mpls@uu.net; Thu, 17 Aug 2000 07:09:08 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjcpw04918
	for <mpls@mail-control.mail.uu.net>; Thu, 17 Aug 2000 11:08:38 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjcpw02973
	for <mpls@UU.NET>; Thu, 17 Aug 2000 07:08:31 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88])
	id QQjcpw27443
	for <mpls@UU.NET>; Thu, 17 Aug 2000 11:08:16 GMT
Received: from rhthomas-sun2.cisco.com (rhthomas-sun2.cisco.com [161.44.134.47])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id EAA20037
	for <mpls@UU.NET>; Thu, 17 Aug 2000 04:08:34 -0700 (PDT)
Received: (rhthomas@localhost) by rhthomas-sun2.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id HAA10308; Thu, 17 Aug 2000 07:08:15 -0400 (EDT)
Date: Thu, 17 Aug 2000 07:08:15 -0400 (EDT)
Message-Id: <200008171108.HAA10308@rhthomas-sun2.cisco.com>
From: Bob Thomas <rhthomas@cisco.com>
To: mpls@UU.NET
Subject: draft-ietf-mpls-ldp-09.txt and draft-ietf-mpls-ldp-10.txt
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

FYI:

The 2 recent revisions of the LDP I-D were issued to address issues
identified by the IESG:

- Draft ldp-09.txt differs from ldp-08.txt in that it removes
  references to the MPLS Framework I-D.

- Draft ldp-10.txt revises the IANA considerations section slightly
  by making IANA's role more explicitly stated and by correcting a typo.


Neither draft changes the protocol itself.


Bob



From owner-mpls@UU.NET  Thu Aug 17 08:46:23 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25578
	for <mpls-archive@lists.ietf.org>; Thu, 17 Aug 2000 08:46:22 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcqd25447;
	Thu, 17 Aug 2000 12:45:23 GMT
Received: by mail-control.mail.uu.net 
	id QQjcqc23075
	for mpls-outgoing; Thu, 17 Aug 2000 12:44:55 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjcqc23070
	for <mpls@mail-control.mail.uu.net>; Thu, 17 Aug 2000 12:44:54 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjcqc20538
	for <mpls@uu.net>; Thu, 17 Aug 2000 08:44:35 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjcqc15541
	for <mpls@uu.net>; Thu, 17 Aug 2000 12:44:20 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id IAA28376
	for mpls@uu.net; Thu, 17 Aug 2000 08:44:19 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjcqc22933
	for <mpls@mail-control.mail.uu.net>; Thu, 17 Aug 2000 12:43:59 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjcqc15204
	for <mpls@UU.NET>; Thu, 17 Aug 2000 08:43:42 -0400 (EDT)
Received: from picard.noroff.no by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [212.20.204.3])
	id QQjcqc24170
	for <mpls@UU.NET>; Thu, 17 Aug 2000 12:43:39 GMT
Received: by picard.noroff.no (Postfix, from userid 815)
	id 78B3422003; Thu, 17 Aug 2000 15:28:35 +0200 (CEST)
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177])
	by picard.noroff.no (Postfix) with ESMTP id D0E92B3802
	for <magg@NOROFF.NO>; Thu, 17 Aug 2000 15:28:32 +0200 (CEST)
Received: (from adm@localhost)
	by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA28701
	for ietf-123-outbound.09@ietf.org; Thu, 17 Aug 2000 07:55:02 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])
	by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA28361
	for <all-ietf@loki.ietf.org>; Thu, 17 Aug 2000 06:57:59 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23311;
	Thu, 17 Aug 2000 06:57:59 -0400 (EDT)
Message-Id: <200008171057.GAA23311@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;
Cc: mpls@UU.NET
From: Internet-Drafts@ietf.org
Reply-To: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mpls-ldp-10.txt
Date: Thu, 17 Aug 2000 06:57:59 -0400
X-AntiVirus: scanned for viruses by Amavis 0.2.1-pre2
Sender: owner-mpls@UU.NET
Precedence: bulk

--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		: LDP Specification
	Author(s)	: L. Andersson, P. Doolan, N. Feldman,
                          A. Fredette, B. Thomas
	Filename	: draft-ietf-mpls-ldp-10.txt
	Pages		: 135
	Date		: 16-Aug-00
	
The architecture for Multi Protocol Label Switching (MPLS) is
described in [ARCH].  A fundamental concept in MPLS is that two Label
Switching Routers (LSRs) must agree on the meaning of the labels used
to forward traffic between and through them.  This common
understanding is achieved by using a set of procedures, called a
label distribution protocol, by which one LSR informs another of
label bindings it has made.  This document defines a set of such
procedures called LDP (for Label Distribution Protocol) by which LSRs
distribute labels to support MPLS forwarding along normally routed
paths [LDPAPPLIC].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-10.txt

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-ldp-10.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-ldp-10.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:	<20000816143949.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mpls-ldp-10.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mpls-ldp-10.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000816143949.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-mpls@UU.NET  Thu Aug 17 09:09:31 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26003
	for <mpls-archive@lists.ietf.org>; Thu, 17 Aug 2000 09:09:31 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcqe01081;
	Thu, 17 Aug 2000 13:08:47 GMT
Received: by mail-control.mail.uu.net 
	id QQjcqe06032
	for mpls-outgoing; Thu, 17 Aug 2000 13:08:27 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjcqe06027
	for <mpls@mail-control.mail.uu.net>; Thu, 17 Aug 2000 13:08:19 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjcqe19431
	for <mpls@uu.net>; Thu, 17 Aug 2000 09:08:09 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjcqe00285
	for <mpls@uu.net>; Thu, 17 Aug 2000 13:07:38 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA00955
	for mpls@uu.net; Thu, 17 Aug 2000 09:07:38 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjcqe05999
	for <mpls@mail-control.mail.uu.net>; Thu, 17 Aug 2000 13:07:17 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjcqe23931
	for <mpls@uu.net>; Thu, 17 Aug 2000 09:07:06 -0400 (EDT)
Received: from cvis29.marconicomms.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cvis29.marconicomms.com [195.99.244.61])
	id QQjcqe10261
	for <mpls@uu.net>; Thu, 17 Aug 2000 13:06:36 GMT
Received: from cvis01.gpt.co.uk (cvis01.gpt.co.uk) by cvis29.marconicomms.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <Tc363f43dfe4e158fca3b@cvis29.marconicomms.com> for <mpls@uu.net>;
 Thu, 17 Aug 2000 14:06:34 +0100
Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP
 (8.8.8+Sun/cvms-27) id OAA00309; Thu, 17 Aug 2000 14:06:31 +0100 (BST)
Received: by marconicomms.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id 8025693E.0047F63E ; Thu, 17 Aug 2000 14:06:00 +0100
X-Lotus-FromDomain: MCMAIN@MCEXT
From: "Diego Caviglia" <Diego.Caviglia@marconi.com>
To: mpls@UU.NET
Message-ID: <8025693E.0047F4AE.00@marconicomms.com>
Date: Thu, 17 Aug 2000 15:06:13 +0200
Subject: OSPF extension in support of MPL(ambda)S
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-mpls@UU.NET
Precedence: bulk



Hi All,
     I have some doubts about two OSPF extension drafts,
drfat-kompella-mpls-optical and draft-osmpls-ospf-extension .
Those two drafts seem to discuss the same topic but differ in some details e.g.
Chapter 3.3 drfat-kompella-mpls-optical ".....In OSPF, this TLV is a sub-TLV of
the Link TLV,  with type 11."
Chapter 5.3 draft-osmpls-ospf-extension "...The SRLG sub-TLV is a sub-TLV of the
Link TLV with type 13...".
Which draft is right?

Diego




From owner-mpls@UU.NET  Thu Aug 17 09:38:31 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26361
	for <mpls-archive@lists.ietf.org>; Thu, 17 Aug 2000 09:38:30 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcqg21182;
	Thu, 17 Aug 2000 13:37:41 GMT
Received: by mail-control.mail.uu.net 
	id QQjcqg07299
	for mpls-outgoing; Thu, 17 Aug 2000 13:37:07 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjcqg07294
	for <mpls@mail-control.mail.uu.net>; Thu, 17 Aug 2000 13:36:49 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjcqg24487
	for <mpls@uu.net>; Thu, 17 Aug 2000 09:36:25 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjcqg19742
	for <mpls@uu.net>; Thu, 17 Aug 2000 13:35:54 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA04128
	for mpls@uu.net; Thu, 17 Aug 2000 09:35:54 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjcqg07248
	for <mpls@mail-control.mail.uu.net>; Thu, 17 Aug 2000 13:35:10 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjcqg28449
	for <mpls@UU.NET>; Thu, 17 Aug 2000 09:35:02 -0400 (EDT)
Received: from xover.hjinc.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [38.160.241.130])
	id QQjcqg29505
	for <mpls@UU.NET>; Thu, 17 Aug 2000 13:34:47 GMT
Received: by xover.hjinc.com with Internet Mail Service (5.5.2650.21)
	id <QQ74YJMR>; Thu, 17 Aug 2000 09:30:38 -0400
Message-ID: <7BF58A904536D411ADD400508BC97B85046BBB@xover1.netplane.com>
From: "Kullberg, Alan" <akullber@netplane.com>
To: "'Kireeti Kompella'" <kireeti@juniper.net>, mpls@UU.NET
Subject: RE: generalized MPLS signaling question
Date: Thu, 17 Aug 2000 09:30:54 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Kireeti,

Thanks for the response.  The "variant of LMP" to which you
refer sounds overly complicated for the problem to be solved.
Perhaps that's why you are seeking an alternate solution.
Does the solution involve a new Object/TLV to travel in the
PATH/REQUEST message to aid in communicating to LSR-B the binding
between the FA-LSP and the PATH/REQUEST?  In my earlier email,
I suggested that the 6 octet LSPID (from CR-LDP) could serve
this purpose just fine.  To be specific, in the PATH/REQUEST
message from LSR-A to LSR-B that is requesting timeslot(s) be
assigned from the FA-LSP (lambda), a new TLV is included that
carries the LSPID corresponding to the FA-LSP that is to be
used for stacking.

Alan

> -----Original Message-----
> From: Kireeti Kompella [mailto:kireeti@juniper.net]
> Sent: Wednesday, August 16, 2000 5:17 PM
> To: akullber@netplane.com; kireeti@juniper.net; mpls@UU.NET
> Subject: RE: generalized MPLS signaling question
> 
> 
> Hi Alan,
> 
> > Let's assume the lambda-switched paths are unnumbered and 
> are assigned
> > "interface" indices as per the unnumbered draft.  When 
> LSR-B receives
> > an ERO with the "Interface ID" subobject, how is the 
> association made
> > with the correct lambda-switched path for timeslot allocation?
> 
> Excellent question.  The implicit assumption was that with out-of-band
> signalling, some other means of identifying the links is used (e.g., a
> variant of LMP).  I.e., LSR-A knows (per the ERO) which FA
> (lambda-switched path) to use.  LSR-A and LSR-B have already 
> identified
> the links (e.g., with some variant of LMP).  LSR-A then sends the Path
> message with a Link ID object (from the bundling document) to 
> let LSR-B
> know which FA LSR-A wants to use.
> 
> However, this is not altogether satisfactory (variant of LMP, etc).
> An alternate solution is being worked on.
> 
> Kireeti.
> 



From owner-mpls@UU.NET  Thu Aug 17 11:16:29 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28404
	for <mpls-archive@lists.ietf.org>; Thu, 17 Aug 2000 11:16:24 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcqm13111;
	Thu, 17 Aug 2000 15:14:44 GMT
Received: by mail-control.mail.uu.net 
	id QQjcqm09432
	for mpls-outgoing; Thu, 17 Aug 2000 15:14:19 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjcqm09419
	for <mpls@mail-control.mail.uu.net>; Thu, 17 Aug 2000 15:14:12 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjcqm15923
	for <mpls@UU.NET>; Thu, 17 Aug 2000 11:14:04 -0400 (EDT)
Received: from zrtps06s.us.nortel.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [47.140.48.50])
	id QQjcqm12290
	for <mpls@UU.NET>; Thu, 17 Aug 2000 15:13:51 GMT
Received: from zmers013 (actually zmers013.ca.nortel.com) 
          by zrtps06s.us.nortel.com; Thu, 17 Aug 2000 11:11:05 -0400
Received: from zcard00p.ca.nortel.com by zmers013;
          Thu, 17 Aug 2000 11:10:54 -0400
Received: from americasm01.nt.com (wcars0v1.ca.nortel.com [47.14.98.167]) 
          by zcard00p.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) 
          id RCQKQ201; Thu, 17 Aug 2000 11:10:51 -0400
Message-ID: <399C007B.EB8EE1A@americasm01.nt.com>
Date: Thu, 17 Aug 2000 11:10:51 -0400
From: "Darek Skalecki" <dareks@nortelnetworks.com>
Organization: Nortel
X-Mailer: Mozilla 4.06 [en] (X11; I; SunOS 5.6 sun4u)
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: LSP setup across IGP areas
References: <200008161049.GAA21550@ietf.org> <399AB10E.D52BF1D2@americasm01.nt.com>
Content-Type: multipart/alternative;
              boundary="------------81D00366A2DF1007CB705236"
X-Orig: <dareks@americasm01.nt.com>
Sender: owner-mpls@UU.NET
Precedence: bulk


--------------81D00366A2DF1007CB705236
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Skalecki, Darek (EXCHANGE:CAR:9K12) wrote:

> I have a couple of questions/comments in association with
> draft-venkatachalam-interarea-mpls-te-00.txt about LSP setup across
> IGP areas.
>
> 1. In section 4.4 (Routing algorithm):
>
>    6. If the destination is in this area, calculate an intra-area
> route
>       from the originating node to the destination that satisfies the
>                ^^^^^^^^^^^^^^^^
>       constraints, and splice the egress of the original LSP and the
>                                                 ^^^^^^^^^^^^
>       ingress of the new LSP.
>
> Shouldn't it be transit ABR instead of originating node, and also
> upstream LSP instead of original LSP.
>
> 2. Is there some special software entity besides the signaling entity
> (RSVP-TE or CR-LDP) at ABR that splices upstream LSP section to
> downstream LSP section. Is this entity what you call routing process
> in step 4 of section 4.4. Is this entity responsible for intercepting
> LABEL_REQUEST and PATH (as well as other CR-LDP and RSVP) messages at
> ABRs.
>
> 3. About crankback. It is stated that crankback is to the previous
> nearest ABR from the point of failure. At that ABR the routing
> algorithm by routing process is repeated.  Is there any mechanism that
> prevents the selection of the same ABR as was used previously. For
> example, refering to the following example
>
> Area 1                      Area 0                    Area 2
> --------------------    ------------------
> ------------------------
> |                  |    |                 |    |
> |
> |  |N1  PPS1       -------    PPS3       --------      PPS5      |N2
> |
> |  |-------------- |ABR1  |--------------|ABR 2 |--------X-------|
> |
> |  |-------|       -------               -------- --|PPS7 |------|
> |
> |   PSS2   |       -------    PSS4       --------   |-----| PSS6
> |
> |          --------|ABR 3 |--------------|ABR 4  |---------
> |
> |                  -------               --------
> |
> |                  |    |                 |    |
> |
> --------------------    -------------------
> -------------------------
>
> Let's assume PPS5 failed and we initially cranked back to ABR 2 but
> there was no intra-area route to the destination so we cranked back to
> ABR1. At ABR1 when performing the algorithm of section 4.4 we should
> not consider ABR2 as this is from where we cranked back and we know
> that ABR2 already tried unsuccessfully to route to the destination.
>
> Also, routing in response to crankback really depends on whether the
> failure causing the crankback was within the current area or another
> downstream area. If it was within the current area then same
> downstream ABR can be selected. If it was outside of the current area
> then a different ABR should be selected. For example, if PPS5 fails
> and we crank back to ABR2 then to ABR1 (as I eluded to above) then
> ABR2 should not be considered when routing at ABR1. On the other hand,
> if PPS3 fails and we crank back to ABR1 then ABR2 should be
> considered.
>
> 4. Have you given some thought to the idea that an LSP section failure
> in one area should not have an effect on surrounding LSP sections in
> other areas. For example, refering to the above picture, if PPS3 fails
> then another intra-area route through Area 0 between ABR1 and ABR2 is
> computed and LSP section reestablished along that route without
> affecting LSP sections PPS1 and PPS5. This would be similar to "local
> repair" where local = area.
>
> Cheers,
>
> Darek
>
>
>

--------------81D00366A2DF1007CB705236
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
Skalecki, Darek (EXCHANGE:CAR:9K12) wrote:
<BLOCKQUOTE TYPE=CITE>
I have a couple of questions/comments in association
with draft-venkatachalam-interarea-mpls-te-00.txt about LSP setup across
IGP areas.
<P>1. In section 4.4 (Routing algorithm):
<P><TT>&nbsp;&nbsp; 6. If the destination is in this area, calculate an
intra-area route</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; from the originating node to the
destination that satisfies the</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
^^^^^^^^^^^^^^^^</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; constraints, and splice the egress
of the original LSP and the</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
^^^^^^^^^^^^</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ingress of the new LSP.</TT>
<P>Shouldn't it be transit ABR instead of originating node, and also upstream
LSP instead of original LSP.
<P>2. Is there some special software entity besides the signaling entity
(RSVP-TE or CR-LDP) at ABR that splices upstream LSP section to downstream
LSP section. Is this entity what you call routing process in step 4 of
section 4.4. Is this entity responsible for intercepting LABEL_REQUEST
and PATH (as well as other CR-LDP and RSVP) messages at ABRs.
<P>3. About crankback. It is stated that crankback is to the previous nearest
ABR from the point of failure. At that ABR the routing algorithm by routing
process is repeated.&nbsp; Is there any mechanism that prevents the selection
of the same ABR as was used previously. For example, refering to the following
example
<P><TT>Area 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Area 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Area 2</TT>
<BR><TT>--------------------&nbsp;&nbsp;&nbsp; ------------------&nbsp;&nbsp;&nbsp;&nbsp;
------------------------</TT>
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</TT>
<BR><TT>|&nbsp; |N1&nbsp; PPS1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -------&nbsp;&nbsp;&nbsp;
PPS3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; --------&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
PPS5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |N2&nbsp;&nbsp; |</TT>
<BR><TT>|&nbsp; |-------------- |ABR1&nbsp; |--------------|ABR 2 |--------X-------|&nbsp;&nbsp;&nbsp;&nbsp;
|</TT>
<BR><TT>|&nbsp; |-------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -------&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
-------- --|PPS7 |------|&nbsp;&nbsp;&nbsp;&nbsp; |</TT>
<BR><TT>|&nbsp;&nbsp; PSS2&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
-------&nbsp;&nbsp;&nbsp; PSS4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; --------&nbsp;&nbsp;
|-----| PSS6&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</TT>
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; --------|ABR
3 |--------------|ABR 4&nbsp; |---------&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</TT>
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
-------&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
--------&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</TT>
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</TT>
<BR><TT>--------------------&nbsp;&nbsp;&nbsp; -------------------&nbsp;&nbsp;&nbsp;
-------------------------</TT>
<P>Let's assume PPS5 failed and we initially cranked back to ABR 2 but
there was no intra-area route to the destination so we cranked back to
ABR1. At ABR1 when performing the algorithm of section 4.4 we should not
consider ABR2 as this is from where we cranked back and we know that ABR2
already tried unsuccessfully to route to the destination.
<P>Also, routing in response to crankback really depends on whether the
failure causing the crankback was within the current area or another downstream
area. If it was within the current area then same downstream ABR can be
selected. If it was outside of the current area then a different ABR should
be selected. For example, if PPS5 fails and we crank back to ABR2 then
to ABR1 (as I eluded to above) then ABR2 should not be considered when
routing at ABR1. On the other hand, if PPS3 fails and we crank back to
ABR1 then ABR2 should be considered.
<P>4. Have you given some thought to the idea that an LSP section failure
in one area should not have an effect on surrounding LSP sections in other
areas. For example, refering to the above picture, if PPS3 fails then another
intra-area route through Area 0 between ABR1 and ABR2 is computed and LSP
section reestablished along that route without affecting LSP sections PPS1
and PPS5. This would be similar to "local repair" where local = area.
<P>Cheers,
<P>Darek
<BR>&nbsp;
<BR>&nbsp;
<BR>&nbsp;</BLOCKQUOTE>
</HTML>

--------------81D00366A2DF1007CB705236--



From owner-mpls@UU.NET  Thu Aug 17 11:32:20 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28695
	for <mpls-archive@lists.ietf.org>; Thu, 17 Aug 2000 11:32:19 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcqo25567;
	Thu, 17 Aug 2000 15:31:14 GMT
Received: by mail-control.mail.uu.net 
	id QQjcqo11196
	for mpls-outgoing; Thu, 17 Aug 2000 15:30:39 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjcqo11188
	for <mpls@mail-control.mail.uu.net>; Thu, 17 Aug 2000 15:30:37 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjcqo19062
	for <mpls@UU.NET>; Thu, 17 Aug 2000 11:30:28 -0400 (EDT)
Received: from fortress.fnc.fujitsu.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: fortress.fnc.fujitsu.com [204.253.82.1])
	id QQjcqo09093
	for <mpls@UU.NET>; Thu, 17 Aug 2000 15:30:12 GMT
Received: from rchsemx2.fnc.fujitsu.com (rchsemx2.fnc.fujitsu.com [167.254.105.13]) by fortress.fnc.fujitsu.com (8.8.7/FNC/ITG-2.0.1) with ESMTP id KAA29781 for <mpls@UU.NET>; Thu, 17 Aug 2000 10:30:10 -0500 (CDT)
Received: by rchsemx2.fnc.fujitsu.com with Internet Mail Service (5.5.2650.21)
	id <PPQKHGL7>; Thu, 17 Aug 2000 10:30:11 -0500
Message-ID: <F8B312027514D21197BC0000F81E25A30977C21D@fnc03.fnc.fujitsu.com>
From: "Dawkins, Spencer" <Spencer.DAWKINS@fnc.fujitsu.com>
To: mpls@UU.NET
Subject: LMP Acronym question
Date: Thu, 17 Aug 2000 10:29:56 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

In draft-lang-mpls-lmp-01.txt, section 3.0 makes reference to TDM, LSC, and
FSC, without defining these terms. I found the definitions in
draft-ashwood-generalized-mpls-signaling-00.txt - could they be made
explicit in the LMP draft?

Spencer


From owner-mpls@UU.NET  Thu Aug 17 11:36:59 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28780
	for <mpls-archive@lists.ietf.org>; Thu, 17 Aug 2000 11:36:59 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcqo29269;
	Thu, 17 Aug 2000 15:35:38 GMT
Received: by mail-control.mail.uu.net 
	id QQjcqo11639
	for mpls-outgoing; Thu, 17 Aug 2000 15:35:19 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjcqo11634
	for <mpls@mail-control.mail.uu.net>; Thu, 17 Aug 2000 15:35:11 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjcqo19883
	for <mpls@UU.NET>; Thu, 17 Aug 2000 11:35:02 -0400 (EDT)
Received: from red.juniper.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: natint.juniper.net [207.17.136.129])
	id QQjcqo12062
	for <mpls@UU.NET>; Thu, 17 Aug 2000 15:34:31 GMT
Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90])
	by red.juniper.net (8.9.3/8.9.3) with ESMTP id IAA05596;
	Thu, 17 Aug 2000 08:34:31 -0700 (PDT)
Received: (from kireeti@localhost) by kummer.juniper.net (8.8.7/8.7.3) id IAA04205; Thu, 17 Aug 2000 08:34:03 -0700 (PDT)
Date: Thu, 17 Aug 2000 08:34:03 -0700 (PDT)
From: Kireeti Kompella <kireeti@juniper.net>
Message-Id: <200008171534.IAA04205@kummer.juniper.net>
To: Diego.Caviglia@marconi.com, mpls@UU.NET
Subject: Re: OSPF extension in support of MPL(ambda)S
Sender: owner-mpls@UU.NET
Precedence: bulk

draft-kompella-mpls-optical has been superceded and will eventually
expire.

Kireeti.


From owner-mpls@UU.NET  Thu Aug 17 12:05:57 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29283
	for <mpls-archive@lists.ietf.org>; Thu, 17 Aug 2000 12:05:57 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcqq20238;
	Thu, 17 Aug 2000 16:04:10 GMT
Received: by mail-control.mail.uu.net 
	id QQjcqq22170
	for mpls-outgoing; Thu, 17 Aug 2000 16:03:29 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjcqq22082
	for <mpls@mail-control.mail.uu.net>; Thu, 17 Aug 2000 16:03:26 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjcqq22074
	for <mpls@uu.net>; Thu, 17 Aug 2000 12:03:24 -0400 (EDT)
From: Ted44tedT@netscape.net
Received: from imo-d01.mx.aol.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imo-d01.mx.aol.com [205.188.157.33])
	id QQjcqq02106
	for <mpls@uu.net>; Thu, 17 Aug 2000 16:03:08 GMT
Received: from Ted44tedT@netscape.net
	by imo-d01.mx.aol.com (mail_out_v27.12.) id 1.f1.bc722 (16244);
	Thu, 17 Aug 2000 12:03:06 -0400 (EDT)
Received: from  netscape.com (aimmail08.aim.aol.com [205.188.144.200]) by air-in03.mx.aol.com (v75_b3.11) with ESMTP; Thu, 17 Aug 2000 12:03:05 -0400
Message-ID: <079381D0.296D02B1.02882A9A@netscape.net>
Date: Thu, 17 Aug 2000 12:03:05 -0400
To: mpls@UU.NET, mpls-ops@mplsrc.com
Subject: SE style
X-Mailer: Franklin Webmailer 1.0
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi,

Quick question from RSVP-TE:

In section 2.4.3, it says "SE style reservations can be provided using multipoint-to-point label-switched-path or LSP per sender.  Multipoint-to-point LSPs may be used when path messages do not carry the EXPLICIT_ROUTE object, or when Path messages have identical EXPLICIT_ROUTE objects.  In either of these cases a common label may be assigned."

I was confused about that. Why ERO can't be assigned?

Regards,
Ted





----------
Get your own FREE, personal Netscape Webmail account today at http://home.netscape.com/webmail/


From owner-mpls@UU.NET  Thu Aug 17 14:23:21 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02033
	for <mpls-archive@lists.ietf.org>; Thu, 17 Aug 2000 14:23:21 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcqz04156;
	Thu, 17 Aug 2000 18:22:05 GMT
Received: by mail-control.mail.uu.net 
	id QQjcqz01118
	for mpls-outgoing; Thu, 17 Aug 2000 18:19:40 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjcqz01113
	for <mpls@mail-control.mail.uu.net>; Thu, 17 Aug 2000 18:19:25 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjcqz20175
	for <mpls@UU.NET>; Thu, 17 Aug 2000 14:19:04 -0400 (EDT)
Received: from maplenetworks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: w082.z216112072.sjc-ca.dsl.cnc.net [216.112.72.82])
	id QQjcqz02207
	for <mpls@UU.NET>; Thu, 17 Aug 2000 18:18:59 GMT
Received: from prasuncomp (farhad_pc [192.168.10.239])
	by maplenetworks.com (8.9.3+Sun/8.9.3/jcm Maplenetworks hub 1.4) with SMTP id LAA07071
	for <mpls@UU.NET>; Thu, 17 Aug 2000 11:18:46 -0700 (PDT)
Message-ID: <018701c00877$fca6e3a0$ef0aa8c0@maplenetworks.com>
From: "Sudhanshu Jain" <sjain@maplenetworks.com>
To: <mpls@UU.NET>
Subject: mplsInterfaceConfTable in LSR MIB
Date: Thu, 17 Aug 2000 11:21:37 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0184_01C0083D.4EB6BD40"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0184_01C0083D.4EB6BD40
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi All,

I have some doubt on draft-ietf-mpls-lsr.mib.

Here "mplsInterfaceConfTable" has all the object IDs as read only. Is =
there any specific reason to make these parameters as read only?
=20
Is there any other mib which may allow some of these params like =
"mplsInterfaceLabelMinOut",
"mplsInterfaceLabelMaxOut", to configure?

Any comments??

-Sudhanshu Jain


------=_NextPart_000_0184_01C0083D.4EB6BD40
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4134.600" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi All,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I have&nbsp;some doubt&nbsp;on=20
draft-ietf-mpls-lsr.mib.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Here =
"mplsInterfaceConfTable"&nbsp;has&nbsp;all the=20
object IDs as read only. Is there any specific reason to make these =
parameters=20
as read only?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Is there any other mib which may allow =
some of=20
these params like "mplsInterfaceLabelMinOut",</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>"mplsInterfaceLabelMaxOut", to=20
configure?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Any comments??</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>-Sudhanshu Jain</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0184_01C0083D.4EB6BD40--



From owner-mpls@UU.NET  Thu Aug 17 14:29:29 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02160
	for <mpls-archive@lists.ietf.org>; Thu, 17 Aug 2000 14:29:28 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcqz09421;
	Thu, 17 Aug 2000 18:28:25 GMT
Received: by mail-control.mail.uu.net 
	id QQjcqz01594
	for mpls-outgoing; Thu, 17 Aug 2000 18:28:00 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjcqz01589
	for <mpls@mail-control.mail.uu.net>; Thu, 17 Aug 2000 18:27:53 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjcqz23605
	for <mpls@uu.net>; Thu, 17 Aug 2000 14:27:46 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjcqz29945
	for <mpls@uu.net>; Thu, 17 Aug 2000 18:27:45 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA16080
	for mpls@uu.net; Thu, 17 Aug 2000 14:27:44 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjcqz01560
	for <mpls@mail-control.mail.uu.net>; Thu, 17 Aug 2000 18:27:15 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjcqz21634
	for <mpls@UU.NET>; Thu, 17 Aug 2000 14:27:00 -0400 (EDT)
Received: from funnel.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQjcqz29287
	for <mpls@UU.NET>; Thu, 17 Aug 2000 18:26:45 GMT
Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.131.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA20459; Thu, 17 Aug 2000 14:26:36 -0400 (EDT)
Received: from tnadeau-pc02.cisco.com (ch2-dhcp134-170.cisco.com [161.44.134.170])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AAJ11377;
	Thu, 17 Aug 2000 14:26:33 -0400 (EDT)
Message-Id: <4.3.2.7.2.20000817141449.05475610@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 17 Aug 2000 14:16:34 -0400
To: "Sudhanshu Jain" <sjain@maplenetworks.com>, <mpls@UU.NET>
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Subject: Re: mplsInterfaceConfTable in LSR MIB
Cc: cheenu Srinivasan <csrinivasan@tachion.com>, arun@force10networks.com
In-Reply-To: <018701c00877$fca6e3a0$ef0aa8c0@maplenetworks.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_51813775==_.ALT"
Sender: owner-mpls@UU.NET
Precedence: bulk

--=====================_51813775==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed


         Hi Sudhanshu,

>I have some doubt on draft-ietf-mpls-lsr.mib.
>
>Here "mplsInterfaceConfTable" has all the object IDs as read only. Is 
>there any specific reason to make these parameters as read only?

         Yes, the reason is that RFC2233 interfaces should be created
by the system. The MPLS parameters are viewed as being attached
or augmenting those.

>Is there any other mib which may allow some of these params like 
>"mplsInterfaceLabelMinOut",
>"mplsInterfaceLabelMaxOut", to configure?

         IETF-LDP-MIB

         --Tom



--=====================_51813775==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Hi
Sudhanshu,<br>
<br>
<blockquote type=cite cite><font face="arial" size=2>I have some doubt on
draft-ietf-mpls-lsr.mib.</font><br>
&nbsp;<br>
<font face="arial" size=2>Here &quot;mplsInterfaceConfTable&quot; has all
the object IDs as read only. Is there any specific reason to make these
parameters as read only?</font></blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Yes, the
reason is that RFC2233 interfaces should be created <br>
by the system. The MPLS parameters are viewed as being attached<br>
or augmenting those.<br>
<br>
<blockquote type=cite cite><font face="arial" size=2>Is there any other
mib which may allow some of these params like
&quot;mplsInterfaceLabelMinOut&quot;,</font><br>
<font face="arial" size=2>&quot;mplsInterfaceLabelMaxOut&quot;, to
configure?</font></blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>IETF-LDP-MIB<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>--Tom<br>
<br>
<br>
</html>

--=====================_51813775==_.ALT--



From owner-mpls@UU.NET  Thu Aug 17 14:54:03 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02628
	for <mpls-archive@lists.ietf.org>; Thu, 17 Aug 2000 14:54:02 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcrb17864;
	Thu, 17 Aug 2000 18:52:56 GMT
Received: by mail-control.mail.uu.net 
	id QQjcrb02890
	for mpls-outgoing; Thu, 17 Aug 2000 18:52:21 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjcrb02885
	for <mpls@mail-control.mail.uu.net>; Thu, 17 Aug 2000 18:52:18 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjcrb26160
	for <mpls@UU.NET>; Thu, 17 Aug 2000 14:52:15 -0400 (EDT)
Received: from maplenetworks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: w082.z216112072.sjc-ca.dsl.cnc.net [216.112.72.82])
	id QQjcrb26977
	for <mpls@UU.NET>; Thu, 17 Aug 2000 18:52:14 GMT
Received: from prasuncomp (farhad_pc [192.168.10.239])
	by maplenetworks.com (8.9.3+Sun/8.9.3/jcm Maplenetworks hub 1.4) with SMTP id LAA07686;
	Thu, 17 Aug 2000 11:52:01 -0700 (PDT)
Message-ID: <01a601c0087c$a1e6d380$ef0aa8c0@maplenetworks.com>
From: "Sudhanshu Jain" <sjain@maplenetworks.com>
To: <mpls@UU.NET>, "Thomas D. Nadeau" <tnadeau@cisco.com>
Cc: "cheenu Srinivasan" <csrinivasan@tachion.com>, <arun@force10networks.com>
References: <4.3.2.7.2.20000817141449.05475610@bucket.cisco.com>
Subject: Re: mplsInterfaceConfTable in LSR MIB
Date: Thu, 17 Aug 2000 11:54:52 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_01A3_01C00841.F3D394C0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_01A3_01C00841.F3D394C0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


  ----- Original Message -----=20
  From: Thomas D. Nadeau=20
  To: Sudhanshu Jain ; mpls@UU.NET=20
  Cc: cheenu Srinivasan ; arun@force10networks.com=20
  Sent: Thursday, August 17, 2000 11:16 AM
  Subject: Re: mplsInterfaceConfTable in LSR MIB



          Hi Sudhanshu,


    I have some doubt on draft-ietf-mpls-lsr.mib.
    =20
    Here "mplsInterfaceConfTable" has all the object IDs as read only. =
Is there any specific reason to make these parameters as read only?

          Yes, the reason is that RFC2233 interfaces should be created=20
  by the system. The MPLS parameters are viewed as being attached
  or augmenting those.

Yes I under this part, as this is the reason we don;t have admin and =
oper status here.
    Is there any other mib which may allow some of these params like =
"mplsInterfaceLabelMinOut",
    "mplsInterfaceLabelMaxOut", to configure?

          IETF-LDP-MIB

But as far as these augmented parameters are concerned, I think they are =
specific to interface and are based on peer LSRs characteristics. And =
that interface may be running LDP or not.=20

Does this mean, IETF-LDP-MIB need to be supported by all the LSR =
irrespective of protocols supported on that LSR? IMHO, these type of =
parameters should be configurable via LSR mib, instaed of LDP MIB.


-Sudhanshu




------=_NextPart_000_01A3_01C00841.F3D394C0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4134.600" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=3Dtnadeau@cisco.com href=3D"mailto:tnadeau@cisco.com">Thomas =
D.=20
  Nadeau</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=3Dsjain@maplenetworks.com=20
  href=3D"mailto:sjain@maplenetworks.com">Sudhanshu Jain</A> ; <A=20
  title=3Dmpls@UU.NET href=3D"mailto:mpls@UU.NET">mpls@UU.NET</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A =
title=3Dcsrinivasan@tachion.com=20
  href=3D"mailto:csrinivasan@tachion.com">cheenu Srinivasan</A> ; <A=20
  title=3Darun@force10networks.com=20
  href=3D"mailto:arun@force10networks.com">arun@force10networks.com</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Thursday, August 17, 2000 =
11:16=20
  AM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Re: =
mplsInterfaceConfTable in=20
  LSR MIB</DIV>
  =
<DIV><BR></DIV><BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;</X-TAB>Hi=20
  Sudhanshu,<BR><BR>
  <BLOCKQUOTE cite type=3D"cite"><FONT face=3Darial size=3D2>I have some =
doubt on=20
    draft-ietf-mpls-lsr.mib.</FONT><BR>&nbsp;<BR><FONT face=3Darial =
size=3D2>Here=20
    "mplsInterfaceConfTable" has all the object IDs as read only. Is =
there any=20
    specific reason to make these parameters as read =
only?</FONT></BLOCKQUOTE>
  =
<DIV><BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>Y=
es,=20
  the reason is that RFC2233 interfaces should be created <BR>by the =
system. The=20
  MPLS parameters are viewed as being attached<BR>or augmenting=20
those.<BR></DIV></BLOCKQUOTE>
<DIV><FONT face=3DArial>
<DIV><FONT face=3DArial size=3D2>Yes I under this part, as this is the =
reason we=20
don;t have admin and oper status here.</FONT></DIV><FONT=20
size=3D2></FONT></FONT></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <BLOCKQUOTE cite type=3D"cite"><FONT face=3Darial size=3D2>Is there =
any other mib=20
    which may allow some of these params like=20
    "mplsInterfaceLabelMinOut",</FONT><BR><FONT face=3Darial=20
    size=3D2>"mplsInterfaceLabelMaxOut", to =
configure?</FONT></BLOCKQUOTE>
  <DIV><FONT face=3DArial size=3D2></FONT><FONT face=3DArial=20
  =
size=3D2></FONT><BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;</X-TAB>IETF-LDP-MIB<BR></DIV></BLOCKQUOTE>
<DIV><FONT face=3DArial size=3D2>But as far as these augmented =
parameters are=20
concerned, I think they are&nbsp;specific to interface and are based on =
peer=20
LSRs characteristics. </FONT><FONT face=3DArial size=3D2>And that =
interface may be=20
running LDP or not. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Does this mean, IETF-LDP-MIB need to be =
supported=20
by all the LSR irrespective of protocols supported on that LSR? IMHO, =
these type=20
of parameters should be configurable via LSR mib, instaed of LDP=20
MIB.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>-Sudhanshu</DIV>
<DIV><BR><BR></DIV></FONT></BODY></HTML>

------=_NextPart_000_01A3_01C00841.F3D394C0--



From owner-mpls@UU.NET  Thu Aug 17 15:08:48 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02864
	for <mpls-archive@lists.ietf.org>; Thu, 17 Aug 2000 15:08:48 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcrc08937;
	Thu, 17 Aug 2000 19:07:30 GMT
Received: by mail-control.mail.uu.net 
	id QQjcrc15469
	for mpls-outgoing; Thu, 17 Aug 2000 19:07:00 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjcrc15457
	for <mpls@mail-control.mail.uu.net>; Thu, 17 Aug 2000 19:06:49 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjcrc29280
	for <mpls@uu.net>; Thu, 17 Aug 2000 15:06:40 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjcrc28290
	for <mpls@uu.net>; Thu, 17 Aug 2000 19:06:39 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA22285
	for mpls@uu.net; Thu, 17 Aug 2000 15:06:39 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjcrc15320
	for <mpls@mail-control.mail.uu.net>; Thu, 17 Aug 2000 19:06:07 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjcrc00562
	for <mpls@UU.NET>; Thu, 17 Aug 2000 15:05:49 -0400 (EDT)
Received: from funnel.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQjcrc07524
	for <mpls@UU.NET>; Thu, 17 Aug 2000 19:05:48 GMT
Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.131.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA26836; Thu, 17 Aug 2000 15:05:40 -0400 (EDT)
Received: from tnadeau-pc02.cisco.com (ch2-dhcp134-170.cisco.com [161.44.134.170])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AAJ11751;
	Thu, 17 Aug 2000 15:05:38 -0400 (EDT)
Message-Id: <4.3.2.7.2.20000817145112.0546ab80@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 17 Aug 2000 14:55:35 -0400
To: "Sudhanshu Jain" <sjain@maplenetworks.com>, <mpls@UU.NET>
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Subject: Re: mplsInterfaceConfTable in LSR MIB
Cc: "cheenu Srinivasan" <csrinivasan@tachion.com>, <arun@force10networks.com>
In-Reply-To: <01a601c0087c$a1e6d380$ef0aa8c0@maplenetworks.com>
References: <4.3.2.7.2.20000817141449.05475610@bucket.cisco.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_54155697==_.ALT"
Sender: owner-mpls@UU.NET
Precedence: bulk

--=====================_54155697==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed



>But as far as these augmented parameters are concerned, I think they are 
>specific to interface and are based
>on peer LSRs characteristics. And that interface may be running LDP or not.
>
>Does this mean, IETF-LDP-MIB need to be supported by all the LSR 
>irrespective of protocols supported on that LSR?

         Only if you want to configure those LDP parameters.

>IMHO, these type of parameters should be configurable via LSR mib, instaed 
>of LDP MIB.

         The consensus was that the LSR MIB reflect the label
ranges which were configured by the other various distribution
protocols.

         --Tom


--=====================_54155697==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<font face="arial"><br>
<br>
</font><blockquote type=cite cite><font face="arial" size=2>But as far as
these augmented parameters are concerned, I think they are specific to
interface and are based <br>
on peer LSRs characteristics. And that interface may be running LDP or
not. </font><br>
&nbsp;<br>
<font face="arial" size=2>Does this mean, IETF-LDP-MIB need to be
supported by all the LSR irrespective of protocols supported on that
LSR?</font></blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Only if
you want to configure those LDP parameters.<br>
<br>
<blockquote type=cite cite><font face="arial" size=2>IMHO, these type of
parameters should be configurable via LSR mib, instaed of LDP
MIB.</font></blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>The
consensus was that the LSR MIB reflect the label <br>
ranges which were configured by the other various distribution<br>
protocols.<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>--Tom<br>
<br>
</html>

--=====================_54155697==_.ALT--



From owner-mpls@UU.NET  Thu Aug 17 15:43:31 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03561
	for <mpls-archive@lists.ietf.org>; Thu, 17 Aug 2000 15:43:31 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcre05853;
	Thu, 17 Aug 2000 19:42:21 GMT
Received: by mail-control.mail.uu.net 
	id QQjcre17786
	for mpls-outgoing; Thu, 17 Aug 2000 19:41:47 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjcre17780
	for <mpls@mail-control.mail.uu.net>; Thu, 17 Aug 2000 19:41:45 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjcre06698
	for <MPLS@UU.NET>; Thu, 17 Aug 2000 15:41:27 -0400 (EDT)
Received: from dnsmx2pya.telcordia.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: dnsmx2pya.telcordia.com [128.96.20.32])
	id QQjcre04717
	for <MPLS@UU.NET>; Thu, 17 Aug 2000 19:40:43 GMT
Received: from notes950.cc.telcordia.com (notes950.cc.telcordia.com [128.96.244.1])
	by dnsmx2pya.telcordia.com (8.9.3/8.9.3) with SMTP id PAA08859
	for <MPLS@UU.NET>; Thu, 17 Aug 2000 15:40:40 -0400 (EDT)
Received: by notes950.cc.telcordia.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 8525693E.006C1652 ; Thu, 17 Aug 2000 15:40:36 -0400
X-Lotus-FromDomain: TELCORDIA
From: "Robert Streijl" <rstreijl@telcordia.com>
To: MPLS@UU.NET
Message-ID: <8525693E.006C14DB.00@notes950.cc.telcordia.com>
Date: Thu, 17 Aug 2000 15:39:44 -0400
Subject: Questions on Solving Congestion in MPLS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-mpls@UU.NET
Precedence: bulk



Hi,

I have some questions on a couple of relate things.
The main question is: In case of TE, and there is congestion in the network, how
will traffic be send over a new LSP to prevent any discarding of packets/frames?

I did some searching and came up with the following:
1) In case of TE, you will not run into congestion problems
2) Congestion is really associated to QoS, and can be solved by e.g. Explicit
Congestion Notification (ECN) which currently is experimental and not deployed.
It is also included in the IP header, so really a layer 3 service.
3) Fast Rerouting, in the case of link failures and router failures will use a
new route, by attaching a new label to all packets with a label that would go
over the link or to the router that failed, and pushing the packets belonging to
other LSPs on the label stack.

My first question is if these observations are correct, and my second question
is: In the case of fast rerouting, how is decided to use that new label and go
over another route? Is this dynamically decided by the routing protocol, and
when, or is this a manual operation by an admin that sets a default route with a
label, in case other routes go down?

I hope the questions have the proper granularity and are clear. If not, please
let me know...
Thanks very much in advance.

Kind Regards,
Robert




From owner-mpls@UU.NET  Thu Aug 17 16:21:57 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04048
	for <mpls-archive@lists.ietf.org>; Thu, 17 Aug 2000 16:21:57 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcrh21602;
	Thu, 17 Aug 2000 20:20:54 GMT
Received: by mail-control.mail.uu.net 
	id QQjcrh02060
	for mpls-outgoing; Thu, 17 Aug 2000 20:20:09 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjcrh02053
	for <mpls@mail-control.mail.uu.net>; Thu, 17 Aug 2000 20:20:07 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjcrh14263
	for <mpls@uu.net>; Thu, 17 Aug 2000 16:20:06 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjcrh20651
	for <mpls@uu.net>; Thu, 17 Aug 2000 20:19:35 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA04014
	for mpls@uu.net; Thu, 17 Aug 2000 16:19:35 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjcrh02022
	for <mpls@mail-control.mail.uu.net>; Thu, 17 Aug 2000 20:19:27 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjcrh14146
	for <MPLS@UU.NET>; Thu, 17 Aug 2000 16:19:22 -0400 (EDT)
Received: from procyon.pmc-sierra.bc.ca by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1])
	id QQjcrh20496
	for <MPLS@UU.NET>; Thu, 17 Aug 2000 20:19:22 GMT
Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183])
	by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id NAA26200;
	Thu, 17 Aug 2000 13:19:12 -0700 (PDT)
Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21)
	id <QPVGQWKB>; Thu, 17 Aug 2000 13:22:08 -0700
Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B4072B@nt-exchange-bby.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'Robert Streijl'" <rstreijl@telcordia.com>, MPLS@UU.NET
Subject: RE: Questions on Solving Congestion in MPLS
Date: Thu, 17 Aug 2000 13:22:06 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Robert,

>-----Original Message-----
>From: Robert Sterol [mailto:rstreijl@telcordia.com]
>Sent: Thursday, August 17, 2000 3:40 PM
>To: MPLS@UU.NET
>Subject: Questions on Solving Congestion in MPLS
>
>
>
>
>Hi,
>
>I have some questions on a couple of relate things.
>The main question is: In case of TE, and there is congestion 
>in the network, how
>will traffic be send over a new LSP to prevent any discarding 
>of packets/frames?
>
>I did some searching and came up with the following:
>1) In case of TE, you will not run into congestion problems

It depends on the network policy and the extent of TE implementation. If the
network policy is to drop packets when all the routes are congested, and if
TE is implemented in all edge routers, then you won't probably see any
persistant congestion. Otherwise you may see.

>2) Congestion is really associated to QoS, and can be solved 
>by e.g. Explicit
>Congestion Notification (ECN) which currently is experimental 
>and not deployed.
>It is also included in the IP header, so really a layer 3 service.

ECN can help reduce congestion in case of well-behaved sources. But network
operators can't rely entirely on user behaviors, so they need to implement
other methods such as RED, TE , etc too.

>3) Fast Rerouting, in the case of link failures and router 
>failures will use a
>new route, by attaching a new label to all packets with a 
>label that would go
>over the link or to the router that failed, and pushing the 
>packets belonging to
>other LSPs on the label stack.

The tunneling method that you described is one of the rerouting methods.
There are other moethods too.

>
>My first question is if these observations are correct, and my 
>second question
>is: In the case of fast rerouting, how is decided to use that 
>new label and go
>over another route? Is this dynamically decided by the routing 
>protocol, and
>when, or is this a manual operation by an admin that sets a 
>default route with a
>label, in case other routes go down?

There are basically 2 methods:

1) offline (pre-computation) -> can be manual or automatic
2) on-line (instant computation)-> is automatic


Regards,
-Shahram

>
>I hope the questions have the proper granularity and are 
>clear. If not, please
>let me know...
>Thanks very much in advance.
>
>Kind Regards,
>Robert
>
>



From owner-mpls@UU.NET  Thu Aug 17 16:42:27 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04313
	for <mpls-archive@lists.ietf.org>; Thu, 17 Aug 2000 16:42:27 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcri19322;
	Thu, 17 Aug 2000 20:40:46 GMT
Received: by mail-control.mail.uu.net 
	id QQjcri03178
	for mpls-outgoing; Thu, 17 Aug 2000 20:40:26 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjcri03173
	for <mpls@mail-control.mail.uu.net>; Thu, 17 Aug 2000 20:40:22 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjcri18979
	for <MPLS@UU.NET>; Thu, 17 Aug 2000 16:40:09 -0400 (EDT)
Received: from smtp-out1.bellatlantic.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtp-out1.bellatlantic.net [199.45.39.156])
	id QQjcri05372
	for <MPLS@UU.NET>; Thu, 17 Aug 2000 20:40:09 GMT
Received: from metallica (client-151-198-146-30.nnj.dialup.bellatlantic.net [151.198.146.30])
	by smtp-out1.bellatlantic.net (8.9.1/8.9.1) with SMTP id QAA06013;
	Thu, 17 Aug 2000 16:39:40 -0400 (EDT)
Message-ID: <00de01c0088b$484917c0$3002a8c0@tf.ispsoft.com>
From: "raghu arni" <arni@caip.rutgers.edu>
To: "Shahram Davari" <Shahram_Davari@pmc-sierra.com>,
        "'Robert Streijl'" <rstreijl@telcordia.com>, <MPLS@UU.NET>
References: <336ECDAFDF7DD311B9E30090277AEE4101B4072B@nt-exchange-bby.pmc-sierra.bc.ca>
Subject: Re: Questions on Solving Congestion in MPLS
Date: Thu, 17 Aug 2000 16:39:12 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Talking about offline and online...Are there any offline tools that are
being used in the market today? I heard of wandl..Are there any others..??

Thx,
A



> Robert,
>
> >-----Original Message-----
> >From: Robert Sterol [mailto:rstreijl@telcordia.com]
> >Sent: Thursday, August 17, 2000 3:40 PM
> >To: MPLS@UU.NET
> >Subject: Questions on Solving Congestion in MPLS
> >
> >
> >
> >
> >Hi,
> >
> >I have some questions on a couple of relate things.
> >The main question is: In case of TE, and there is congestion
> >in the network, how
> >will traffic be send over a new LSP to prevent any discarding
> >of packets/frames?
> >
> >I did some searching and came up with the following:
> >1) In case of TE, you will not run into congestion problems
>
> It depends on the network policy and the extent of TE implementation. If
the
> network policy is to drop packets when all the routes are congested, and
if
> TE is implemented in all edge routers, then you won't probably see any
> persistant congestion. Otherwise you may see.
>
> >2) Congestion is really associated to QoS, and can be solved
> >by e.g. Explicit
> >Congestion Notification (ECN) which currently is experimental
> >and not deployed.
> >It is also included in the IP header, so really a layer 3 service.
>
> ECN can help reduce congestion in case of well-behaved sources. But
network
> operators can't rely entirely on user behaviors, so they need to implement
> other methods such as RED, TE , etc too.
>
> >3) Fast Rerouting, in the case of link failures and router
> >failures will use a
> >new route, by attaching a new label to all packets with a
> >label that would go
> >over the link or to the router that failed, and pushing the
> >packets belonging to
> >other LSPs on the label stack.
>
> The tunneling method that you described is one of the rerouting methods.
> There are other moethods too.
>
> >
> >My first question is if these observations are correct, and my
> >second question
> >is: In the case of fast rerouting, how is decided to use that
> >new label and go
> >over another route? Is this dynamically decided by the routing
> >protocol, and
> >when, or is this a manual operation by an admin that sets a
> >default route with a
> >label, in case other routes go down?
>
> There are basically 2 methods:
>
> 1) offline (pre-computation) -> can be manual or automatic
> 2) on-line (instant computation)-> is automatic
>
>
> Regards,
> -Shahram
>
> >
> >I hope the questions have the proper granularity and are
> >clear. If not, please
> >let me know...
> >Thanks very much in advance.
> >
> >Kind Regards,
> >Robert
> >
> >
>
>



From owner-mpls@UU.NET  Thu Aug 17 17:14:05 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04799
	for <mpls-archive@lists.ietf.org>; Thu, 17 Aug 2000 17:14:04 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcrk00327;
	Thu, 17 Aug 2000 21:12:59 GMT
Received: by mail-control.mail.uu.net 
	id QQjcrk17182
	for mpls-outgoing; Thu, 17 Aug 2000 21:12:26 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjcrk17177
	for <mpls@mail-control.mail.uu.net>; Thu, 17 Aug 2000 21:12:17 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjcrk25463
	for <MPLS@UU.NET>; Thu, 17 Aug 2000 17:12:03 -0400 (EDT)
Received: from mail.makesys.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail.makesys.com [204.30.100.64])
	id QQjcrk13337
	for <MPLS@UU.NET>; Thu, 17 Aug 2000 21:12:02 GMT
Received: from makesys.com (mlclient15 [204.30.100.108])
	by mail.makesys.com (8.10.1/8.10.1) with ESMTP id e7HLBnW18434;
	Thu, 17 Aug 2000 17:11:49 -0400 (EDT)
Message-ID: <399C5515.86F016BB@makesys.com>
Date: Thu, 17 Aug 2000 17:11:49 -0400
From: Rob Rice <robrice@makesys.com>
Organization: Make Systems, Inc.
X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: raghu arni <arni@caip.rutgers.edu>
CC: Shahram Davari <Shahram_Davari@pmc-sierra.com>,
        "'Robert Streijl'" <rstreijl@telcordia.com>, MPLS@UU.NET
Subject: Re: Questions on Solving Congestion in MPLS
References: <336ECDAFDF7DD311B9E30090277AEE4101B4072B@nt-exchange-bby.pmc-sierra.bc.ca> <00de01c0088b$484917c0$3002a8c0@tf.ispsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Raghu,

Make Systems is developing an offline MPLS TE tool scheduled to ship in
October. I can send you details if you are interested.

Rob Rice
Product Manager, Network Engineering Tools
Make Systems, Inc.
919-461-2445 x226
www.makesys.com



raghu arni wrote:

> Talking about offline and online...Are there any offline tools that are
> being used in the market today? I heard of wandl..Are there any others..??
>
> Thx,
> A
>
> > Robert,
> >
> > >-----Original Message-----
> > >From: Robert Sterol [mailto:rstreijl@telcordia.com]
> > >Sent: Thursday, August 17, 2000 3:40 PM
> > >To: MPLS@UU.NET
> > >Subject: Questions on Solving Congestion in MPLS
> > >
> > >
> > >
> > >
> > >Hi,
> > >
> > >I have some questions on a couple of relate things.
> > >The main question is: In case of TE, and there is congestion
> > >in the network, how
> > >will traffic be send over a new LSP to prevent any discarding
> > >of packets/frames?
> > >
> > >I did some searching and came up with the following:
> > >1) In case of TE, you will not run into congestion problems
> >
> > It depends on the network policy and the extent of TE implementation. If
> the
> > network policy is to drop packets when all the routes are congested, and
> if
> > TE is implemented in all edge routers, then you won't probably see any
> > persistant congestion. Otherwise you may see.
> >
> > >2) Congestion is really associated to QoS, and can be solved
> > >by e.g. Explicit
> > >Congestion Notification (ECN) which currently is experimental
> > >and not deployed.
> > >It is also included in the IP header, so really a layer 3 service.
> >
> > ECN can help reduce congestion in case of well-behaved sources. But
> network
> > operators can't rely entirely on user behaviors, so they need to implement
> > other methods such as RED, TE , etc too.
> >
> > >3) Fast Rerouting, in the case of link failures and router
> > >failures will use a
> > >new route, by attaching a new label to all packets with a
> > >label that would go
> > >over the link or to the router that failed, and pushing the
> > >packets belonging to
> > >other LSPs on the label stack.
> >
> > The tunneling method that you described is one of the rerouting methods.
> > There are other moethods too.
> >
> > >
> > >My first question is if these observations are correct, and my
> > >second question
> > >is: In the case of fast rerouting, how is decided to use that
> > >new label and go
> > >over another route? Is this dynamically decided by the routing
> > >protocol, and
> > >when, or is this a manual operation by an admin that sets a
> > >default route with a
> > >label, in case other routes go down?
> >
> > There are basically 2 methods:
> >
> > 1) offline (pre-computation) -> can be manual or automatic
> > 2) on-line (instant computation)-> is automatic
> >
> >
> > Regards,
> > -Shahram
> >
> > >
> > >I hope the questions have the proper granularity and are
> > >clear. If not, please
> > >let me know...
> > >Thanks very much in advance.
> > >
> > >Kind Regards,
> > >Robert
> > >
> > >
> >
> >



From owner-mpls@UU.NET  Thu Aug 17 17:23:33 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04954
	for <mpls-archive@lists.ietf.org>; Thu, 17 Aug 2000 17:23:33 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcrl20877;
	Thu, 17 Aug 2000 21:22:22 GMT
Received: by mail-control.mail.uu.net 
	id QQjcrl17884
	for mpls-outgoing; Thu, 17 Aug 2000 21:21:48 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjcrl17846
	for <mpls@mail-control.mail.uu.net>; Thu, 17 Aug 2000 21:21:33 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjcrl26449
	for <mpls@UU.NET>; Thu, 17 Aug 2000 17:21:30 -0400 (EDT)
Received: from ix.eng.level3.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: gdffw1.denver1.level3.net [209.244.1.161])
	id QQjcrl06224
	for <mpls@UU.NET>; Thu, 17 Aug 2000 21:21:30 GMT
Received: from level3.net (IDENT:luca@localhost [127.0.0.1])
	by ix.eng.level3.net (8.9.3/8.9.3) with ESMTP id PAA04154;
	Thu, 17 Aug 2000 15:21:06 -0600
Message-ID: <399C5742.E5B12E58@level3.net>
Date: Thu, 17 Aug 2000 21:21:06 +0000
From: Luca Martini <luca@level3.net>
Organization: Level 3 Communications
X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.14 i686)
X-Accept-Language: it,fr-CA,fr-FR,en-US
MIME-Version: 1.0
To: seenu@samsung.co.kr
CC: mpls@UU.NET, ybae@cisco.com
Subject: Re: (Reply) Re: mpls-ethernet
References: <H0000e6501a35f98.0965638729.secsw0@MHS>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

seenu@samsung.co.kr wrote:
> 
> The draft-martini-l2circuit-trans-mpls-02.txt has proposed the use of new Virtual Circuit FEC TLV element for label distribution.
> Is it necessary? If so, why has it not been included in the standard mpls draft?
> 
> regards
> seenu

not quite . I am defining a way to transport ethernet over MPLS.
Not MPLS over ethernet.

The standard MPLS LDP specification allows for the creation of new FEC
TLVs.
The existing FEC TLVs are defined for IP , this is not IP , and we
believed it would be better to define a new FEC TLV.


Luca



-- 
Just say no to summer. Ski all year !
Luca Martini Senior Network Engineer, Level 3 Communications -
Broomfield, CO
luca@level3.net | VE2WKR/W0 | Phone 720-888-1225 | pager
page-luca@level3.net


From owner-mpls@UU.NET  Thu Aug 17 17:45:17 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05208
	for <mpls-archive@lists.ietf.org>; Thu, 17 Aug 2000 17:45:17 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcrm21581;
	Thu, 17 Aug 2000 21:44:04 GMT
Received: by mail-control.mail.uu.net 
	id QQjcrm19727
	for mpls-outgoing; Thu, 17 Aug 2000 21:43:31 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjcrm19704
	for <mpls@mail-control.mail.uu.net>; Thu, 17 Aug 2000 21:43:16 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjcrm00949
	for <mpls@UU.NET>; Thu, 17 Aug 2000 17:42:59 -0400 (EDT)
Received: from maplenetworks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: w082.z216112072.sjc-ca.dsl.cnc.net [216.112.72.82])
	id QQjcrm05216
	for <mpls@UU.NET>; Thu, 17 Aug 2000 21:42:58 GMT
Received: from prasuncomp (farhad_pc [192.168.10.239])
	by maplenetworks.com (8.9.3+Sun/8.9.3/jcm Maplenetworks hub 1.4) with SMTP id OAA10395;
	Thu, 17 Aug 2000 14:42:47 -0700 (PDT)
Message-ID: <007201c00894$7a2067e0$ef0aa8c0@maplenetworks.com>
From: "Sudhanshu Jain" <sjain@maplenetworks.com>
To: <mpls@UU.NET>, "Thomas D. Nadeau" <tnadeau@cisco.com>
Cc: "cheenu Srinivasan" <csrinivasan@tachion.com>, <arun@force10networks.com>
References: <4.3.2.7.2.20000817141449.05475610@bucket.cisco.com> <4.3.2.7.2.20000817145112.0546ab80@bucket.cisco.com>
Subject: Re: mplsInterfaceConfTable in LSR MIB
Date: Thu, 17 Aug 2000 14:45:35 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_006F_01C00859.CD860D80"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_006F_01C00859.CD860D80
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Tom,

Thanks for the responses.=20

I understand due to backward compatibility ( with ATM or FR mibs) we =
might have avoided these prams to be configured at a common place like =
LSR MIB, and we added in LDP MIB.

Now in case of RSVP interface, is there any mib which talks about these =
kind of parameters.=20

Don't you think these params are independent of the distribution =
protocol and should be based on encapsulation protocol ( ATM, FR, SHIM =
header ......)


Regards,
-Sudhanshu
  ----- Original Message -----=20
  From: Thomas D. Nadeau=20
  To: Sudhanshu Jain ; mpls@UU.NET=20
  Cc: cheenu Srinivasan ; arun@force10networks.com=20
  Sent: Thursday, August 17, 2000 11:55 AM
  Subject: Re: mplsInterfaceConfTable in LSR MIB





    But as far as these augmented parameters are concerned, I think they =
are specific to interface and are based=20
    on peer LSRs characteristics. And that interface may be running LDP =
or not.=20
    =20
    Does this mean, IETF-LDP-MIB need to be supported by all the LSR =
irrespective of protocols supported on that LSR?

          Only if you want to configure those LDP parameters.


    IMHO, these type of parameters should be configurable via LSR mib, =
instaed of LDP MIB.

          The consensus was that the LSR MIB reflect the label=20
  ranges which were configured by the other various distribution
  protocols.

          --Tom



------=_NextPart_000_006F_01C00859.CD860D80
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4134.600" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2>Hi =
Tom,</FONT>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thanks for the responses. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I understand due to backward =
compatibility ( with=20
ATM or FR mibs) we might have avoided these prams to be configured at a =
common=20
place like LSR MIB, and we added in LDP MIB.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Now in case of RSVP interface, is there =
any mib=20
which talks about these kind of parameters. </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>Don't you think these params are independent of the distribution =
protocol=20
and should be based on encapsulation protocol ( ATM, FR, SHIM header=20
......)</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Regards,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>-Sudhanshu</FONT></DIV></FONT></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=3Dtnadeau@cisco.com href=3D"mailto:tnadeau@cisco.com">Thomas =
D.=20
  Nadeau</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=3Dsjain@maplenetworks.com=20
  href=3D"mailto:sjain@maplenetworks.com">Sudhanshu Jain</A> ; <A=20
  title=3Dmpls@UU.NET href=3D"mailto:mpls@UU.NET">mpls@UU.NET</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A =
title=3Dcsrinivasan@tachion.com=20
  href=3D"mailto:csrinivasan@tachion.com">cheenu Srinivasan</A> ; <A=20
  title=3Darun@force10networks.com=20
  href=3D"mailto:arun@force10networks.com">arun@force10networks.com</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Thursday, August 17, 2000 =
11:55=20
  AM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Re: =
mplsInterfaceConfTable in=20
  LSR MIB</DIV>
  <DIV><BR></DIV><FONT face=3Darial><BR><BR></FONT>
  <BLOCKQUOTE cite type=3D"cite"><FONT face=3Darial size=3D2>But as far =
as these=20
    augmented parameters are concerned, I think they are specific to =
interface=20
    and are based <BR>on peer LSRs characteristics. And that interface =
may be=20
    running LDP or not. </FONT><BR>&nbsp;<BR><FONT face=3Darial =
size=3D2>Does this=20
    mean, IETF-LDP-MIB need to be supported by all the LSR irrespective =
of=20
    protocols supported on that=20
  =
LSR?</FONT></BLOCKQUOTE><BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;</X-TAB>Only=20
  if you want to configure those LDP parameters.<BR><BR>
  <BLOCKQUOTE cite type=3D"cite"><FONT face=3Darial size=3D2>IMHO, these =
type of=20
    parameters should be configurable via LSR mib, instaed of LDP=20
  =
MIB.</FONT></BLOCKQUOTE><BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;</X-TAB>The=20
  consensus was that the LSR MIB reflect the label <BR>ranges which were =

  configured by the other various=20
  =
distribution<BR>protocols.<BR><BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;</X-TAB>--Tom<BR><BR></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_006F_01C00859.CD860D80--



From owner-mpls@UU.NET  Thu Aug 17 18:34:15 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05785
	for <mpls-archive@lists.ietf.org>; Thu, 17 Aug 2000 18:34:15 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcrq07363;
	Thu, 17 Aug 2000 22:33:03 GMT
Received: by mail-control.mail.uu.net 
	id QQjcrq07123
	for mpls-outgoing; Thu, 17 Aug 2000 22:32:31 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjcrq07103
	for <mpls@mail-control.mail.uu.net>; Thu, 17 Aug 2000 22:32:15 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjcrq08269
	for <mpls@UU.NET>; Thu, 17 Aug 2000 18:31:59 -0400 (EDT)
Received: from fortress.fnc.fujitsu.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: fortress.fnc.fujitsu.com [204.253.82.1])
	id QQjcrq21231
	for <mpls@UU.NET>; Thu, 17 Aug 2000 22:31:44 GMT
Received: from rchsemx2.fnc.fujitsu.com (rchsemx2.fnc.fujitsu.com [167.254.105.13]) by fortress.fnc.fujitsu.com (8.8.7/FNC/ITG-2.0.1) with ESMTP id RAA20320 for <mpls@UU.NET>; Thu, 17 Aug 2000 17:31:39 -0500 (CDT)
Received: by rchsemx2.fnc.fujitsu.com with Internet Mail Service (5.5.2650.21)
	id <RD5D6KBF>; Thu, 17 Aug 2000 17:31:30 -0500
Message-ID: <F8B312027514D21197BC0000F81E25A30977C21E@fnc03.fnc.fujitsu.com>
From: "Dawkins, Spencer" <Spencer.DAWKINS@fnc.fujitsu.com>
To: "'IETF MPLS mailing list'" <mpls@UU.NET>
Subject: LinkSummary in draft-lang-mpls-lmp-01.txt missing fields?
Date: Thu, 17 Aug 2000 14:25:35 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

The text in Section 6.0 of this draft says

   "The LinkSummary message contains the primary 
   and backup CCIds, the IP address for the link (binding the CCIds to 
   the link IP addresses), and the local and remote LinkIds for each 
   component link and their associated priorities."

but I don't see the backup CCIds in the LinkSummary message described in
8.5.1:

 The format of the LinkSummary 
   message is as follows: 
    
   <LinkSummary Message> ::= <Common Header> <LinkSummary> 
    
   The LinkSummary Object has the following format: 
    
    0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                          MessageId                            | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                     Interface IP Address                      | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                          NumWorking                           | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                        NumProtection                          | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                                                               | 
   //                 (working channel subobjects)                // 
   |                                                               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                                                               | 
   //               (protection channel subobjects)               // 
   |                                                               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

and the Common Header looks like

   In addition to the standard IP header, all LMP control-channel 
   messages have the following common header: 
    
    0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   | Vers  |    Flags      |    Msg Type   |   (Reserved)          | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                      Control Channel Id                       | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Am I missing something obvious?

Spencer


From owner-mpls@UU.NET  Thu Aug 17 19:26:41 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06227
	for <mpls-archive@lists.ietf.org>; Thu, 17 Aug 2000 19:26:40 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcrt07613;
	Thu, 17 Aug 2000 23:25:24 GMT
Received: by mail-control.mail.uu.net 
	id QQjcrt23423
	for mpls-outgoing; Thu, 17 Aug 2000 23:24:50 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjcrt23407
	for <mpls@mail-control.mail.uu.net>; Thu, 17 Aug 2000 23:24:46 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjcrt14286
	for <mpls@uu.net>; Thu, 17 Aug 2000 19:24:17 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjcrt23218
	for <mpls@uu.net>; Thu, 17 Aug 2000 23:24:16 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id TAA26016
	for mpls@uu.net; Thu, 17 Aug 2000 19:24:16 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjcrt23342
	for <mpls@mail-control.mail.uu.net>; Thu, 17 Aug 2000 23:23:56 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjcrt14111
	for <mpls@UU.NET>; Thu, 17 Aug 2000 19:23:12 -0400 (EDT)
Received: from brixcorp2.brixnet.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: brixcorp2.brixnet.com [216.91.233.5])
	id QQjcrt22542
	for <mpls@UU.NET>; Thu, 17 Aug 2000 23:23:12 GMT
Received: by brixcorp2.brixnet.com with Internet Mail Service (5.5.2650.21)
	id <QAT4TK8W>; Thu, 17 Aug 2000 19:23:12 -0400
Message-ID: <07B0D4912B83D31188F300A0C9F62EBB2AEDDC@brixcorp2.brixnet.com>
From: "Cucchiara, Joan" <JCucchiara@Brixnet.com>
To: "'Thomas D. Nadeau'" <tnadeau@cisco.com>,
        Sudhanshu Jain
	 <sjain@maplenetworks.com>, mpls@UU.NET
Cc: cheenu Srinivasan <csrinivasan@tachion.com>, arun@force10networks.com
Subject: RE: mplsInterfaceConfTable in LSR MIB
Date: Thu, 17 Aug 2000 19:23:11 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk


-----Original Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
> Sent: Thursday, August 17, 2000 2:17 PM
> To: Sudhanshu Jain; mpls@UU.NET
> Cc: cheenu Srinivasan; arun@force10networks.com
> Subject: Re: mplsInterfaceConfTable in LSR MIB
>
>        Hi Sudhanshu,
>
>
>> I have some doubt on draft-ietf-mpls-lsr.mib.
>> 
>> Here "mplsInterfaceConfTable" has all the object IDs as read only. Is
there any specific reason to make these 
>> parameters as read only?
>
>        Yes, the reason is that RFC2233 interfaces should be created 
> by the system. The MPLS parameters are viewed as being attached
> or augmenting those.

However, the ifTable and ifXTable do have
read-write (e.g. ifAdminStatus) objects and thus, 
it is possible to have a read-write objects  
in the mplsInterfaceConfTable.

Sudhanshu, there has only been one MIB for MPLS protocols so far which 
is the LDP MIB.  What it takes MIB-wise to configure other 
MPLS protocols (CR-LDP and MPLS-RSVP and maybe other new protocols) still
needs to
be addressed.  Trying to put in additional objects which
may be common to all/most MPLS protocols in the LSR MIB without these
other protocol MIBs to base it on, would probably be error-prone in my
opinion.  
(I'm not speaking of the changes in the objects
you suggest, but just to make a point in general).

I anticipate that there will be useful feedback on what is already in LSR
MIB which will
certainly be valuable, particularly with the XC Table, and
I would like to see what has been defined already in the LSR MIB
get some deployment experience, and ALSO see these other MPLS protocol MIBs
be developed.  At that point, revisiting the LSR MIB could be done. 

>
>
>> Is there any other mib which may allow some of these params like
"mplsInterfaceLabelMinOut",
>> "mplsInterfaceLabelMaxOut", to configure?
>
>        IETF-LDP-MIB

In the LDP MIB, one can configure label ranges, for example (400-800) and
(1000-2000) on
an interface. Assuming that LDP was the only MPLS protocol on that interface
and 
it was configured with the label ranges given in the previous sentence, 
the value of mplsInterfaceLabelMinOut would be 400 and the value of 
mplsInterfaceLabelMaxOut would be 2000.  This would not show
the gap in labels (801-999).  This may or may not be important, but wanted
to give an
example. 

  Thanks, Joan

>
>        --Tom



From owner-mpls@UU.NET  Fri Aug 18 03:51:00 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24776
	for <mpls-archive@lists.ietf.org>; Fri, 18 Aug 2000 03:50:59 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjctb15918;
	Fri, 18 Aug 2000 07:49:23 GMT
Received: by mail-control.mail.uu.net 
	id QQjctb02749
	for mpls-outgoing; Fri, 18 Aug 2000 07:48:52 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjctb02744
	for <mpls@mail-control.mail.uu.net>; Fri, 18 Aug 2000 07:48:51 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjctb10636
	for <mpls@uu.net>; Fri, 18 Aug 2000 03:48:48 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjctb15324
	for <mpls@uu.net>; Fri, 18 Aug 2000 07:48:18 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id DAA23327
	for mpls@uu.net; Fri, 18 Aug 2000 03:48:17 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjctb02731
	for <mpls@mail-control.mail.uu.net>; Fri, 18 Aug 2000 07:48:04 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjctb06155
	for <mpls@uu.net>; Fri, 18 Aug 2000 03:47:59 -0400 (EDT)
Received: from sigma.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sigma.cisco.com [171.69.63.142])
	id QQjctb14867
	for <mpls@uu.net>; Fri, 18 Aug 2000 07:47:28 GMT
Received: from andreawlap (sj-dial-4-17.cisco.com [171.68.181.146])
	by sigma.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id AAA07715
	for <mpls@uu.net>; Fri, 18 Aug 2000 00:47:21 -0700 (PDT)
From: "Andrea Westerinen" <andreaw@cisco.com>
To: <mpls@UU.NET>
Subject: Policy Terminology Draft
Date: Fri, 18 Aug 2000 00:51:05 -0700
Message-ID: <GGEOLLMKEOKMFKADFNHOGECBCFAA.andreaw@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

The Policy Framework WG has created an I-D to try to disambiguate policy
terminology across all IETF Work Groups.  This draft is located at:
http://www.ietf.org/internet-drafts/draft-ietf-policy-terminology-00.txt

In creating the draft, the team tried to look across all RFCs and WGs to
gain an understanding of policy and its applicability, and consolidate
definitions.  At the Pittsburgh Policy Framework session, it was recommended
that this draft be forwarded to all work groups where it may be applicable.
(If you receive multiple copies, my apologies.)

Please look the draft over, and if you have feedback, please reply to me
and/or to the policy mail list (policy@raleigh.ibm.com).  Some questions to
be considered are ... Are there definitions that should be updated?  Are
there additional terms that should be defined?

For the current terms in the draft, please try to use these terms
consistently.  Our goal is to take this draft through the standards process
and have it serve a function similar to RFC2828.

Thanks.
Andrea Westerinen
Policy Terminology Draft Editor



From owner-mpls@UU.NET  Fri Aug 18 08:18:40 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26751
	for <mpls-archive@lists.ietf.org>; Fri, 18 Aug 2000 08:18:40 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjctt07700;
	Fri, 18 Aug 2000 12:15:28 GMT
Received: by mail-control.mail.uu.net 
	id QQjcts16482
	for mpls-outgoing; Fri, 18 Aug 2000 12:14:56 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjcts16477
	for <mpls@mail-control.mail.uu.net>; Fri, 18 Aug 2000 12:14:54 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjcts10365
	for <MPLS@UU.NET>; Fri, 18 Aug 2000 08:14:46 -0400 (EDT)
Received: from hermes.research.kpn.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: hermes.research.kpn.com [139.63.192.8])
	id QQjcts07003
	for <MPLS@UU.NET>; Fri, 18 Aug 2000 12:14:30 GMT
Received: from l04.research.kpn.com (l04.research.kpn.com [139.63.192.204])
 by research.kpn.com (PMDF V5.2-31 #42699)
 with ESMTP id <01JT49QWJY8Q0009T9@research.kpn.com> for MPLS@UU.NET; Fri,
 18 Aug 2000 14:14:29 +0200
Received: by l04.research.kpn.com with Internet Mail Service (5.5.2650.21)
	id <PQ1DXA6W>; Fri, 18 Aug 2000 14:14:28 +0100
Content-return: allowed
Date: Fri, 18 Aug 2000 14:14:27 +0100
From: "Metz, E.T." <E.T.Metz@kpn.com>
Subject: RE: Questions on Solving Congestion in MPLS
To: "'Robert Streijl'" <rstreijl@telcordia.com>
Cc: MPLS@UU.NET, "'Shahram Davari'" <Shahram_Davari@pmc-sierra.com>
Message-id: <59063B5B4D98D311BC0D0001FA7E45220316A3EB@l04.research.kpn.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain;	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Robert,

> -----Original Message-----
> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
> Sent: donderdag 17 augustus 2000 21:22
> To: 'Robert Streijl'; MPLS@UU.NET
> Subject: RE: Questions on Solving Congestion in MPLS
> 
> 
> Robert,
> 
> >-----Original Message-----
> >From: Robert Sterol [mailto:rstreijl@telcordia.com]
> >Sent: Thursday, August 17, 2000 3:40 PM
> >To: MPLS@UU.NET
> >Subject: Questions on Solving Congestion in MPLS
> >
> >
> >
> >
> >Hi,
> >
> >I have some questions on a couple of relate things.
> >The main question is: In case of TE, and there is congestion 
> >in the network, how
> >will traffic be send over a new LSP to prevent any discarding 
> >of packets/frames?
> >

It seems your targeting at some load-sensitive load-balancing mechanism. I
think OMP (optimised multi-path) described by Curtis Villamizar would fit
this best. However, I have not heard of any implementation of OMP yet. 

In any other case, i.e. not using OMP, I don't think traffic will be put on
other LSPs. So the congestion remains until you re-compute the TE LSPs. If
you would want to that based on load, the only solution at this moment, as
far as I know, is to use off-line tools that take into account your network
topology (and capacity), and traffic load on the links in the network.

> >I did some searching and came up with the following:
> >1) In case of TE, you will not run into congestion problems
> 
> It depends on the network policy and the extent of TE 
> implementation. If the
> network policy is to drop packets when all the routes are 
> congested, and if
> TE is implemented in all edge routers, then you won't probably see any
> persistant congestion. Otherwise you may see.
> 

As stated already, TE can help lessen a congestion problem. TE alone,
however, will not prevent all congestion problems. Your network should be
dimensioned/engineered properly as well, if this is done wrong, TE won't
help you at all.

< ... snip ... >

> 
> >
> >My first question is if these observations are correct, and my 
> >second question
> >is: In the case of fast rerouting, how is decided to use that 
> >new label and go
> >over another route? Is this dynamically decided by the routing 
> >protocol, and
> >when, or is this a manual operation by an admin that sets a 
> >default route with a
> >label, in case other routes go down?
> 
> There are basically 2 methods:
> 
> 1) offline (pre-computation) -> can be manual or automatic
> 2) on-line (instant computation)-> is automatic
> 

There are indeed two ways to *compute* the alternative path, or any path for
that matter (as described above). The actual switch-over (from "working" to
"protection" LSP) occurs automatically. The decision to switch over is made
by the router at which both LSPs start, and could be based on several
criteria and information from several different sources (e.g. routing
protocol, hello mechanism, I/F down etc.).

cheers,
	Eduard

> 
> Regards,
> -Shahram
> 
> >
> >I hope the questions have the proper granularity and are 
> >clear. If not, please
> >let me know...
> >Thanks very much in advance.
> >
> >Kind Regards,
> >Robert
> >
> >
> 


From owner-mpls@UU.NET  Fri Aug 18 09:04:00 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27255
	for <mpls-archive@lists.ietf.org>; Fri, 18 Aug 2000 09:04:00 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjctw06846;
	Fri, 18 Aug 2000 13:02:06 GMT
Received: by mail-control.mail.uu.net 
	id QQjctw24341
	for mpls-outgoing; Fri, 18 Aug 2000 13:01:32 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjctw24028
	for <mpls@mail-control.mail.uu.net>; Fri, 18 Aug 2000 13:01:15 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjctw16413
	for <mpls@uu.net>; Fri, 18 Aug 2000 09:01:00 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjctw14333
	for <mpls@uu.net>; Fri, 18 Aug 2000 13:00:59 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA09750
	for mpls@uu.net; Fri, 18 Aug 2000 09:00:59 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjctw23010
	for <mpls@mail-control.mail.uu.net>; Fri, 18 Aug 2000 13:00:34 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjctw16320;
	Fri, 18 Aug 2000 09:00:24 -0400 (EDT)
Received: from funnel.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQjctw13938;
	Fri, 18 Aug 2000 13:00:23 GMT
Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.131.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA06575; Fri, 18 Aug 2000 09:00:17 -0400 (EDT)
Received: from tnadeau-pc02.cisco.com ([161.44.204.102])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AAJ15597;
	Fri, 18 Aug 2000 09:00:13 -0400 (EDT)
Message-Id: <4.3.2.7.2.20000818084503.054b7830@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 18 Aug 2000 08:50:23 -0400
To: Jim Boyle <jboyle@Level3.net>, te-wg@UU.NET, mpls@UU.NET
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Subject: Re: consensus to make draft-kompella-mpls-te-mib-00.txt a TEWG
  item?
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk


         Hi Jim,

>As for Kireeti's mib, it was mentioned in the interim meeting as a fine 
>example
>of a mib that real operational networks are actually using and that it has 
>a good
>set of operational information needed to monitor and manage TE-based 
>networks.
>His mib is operationally focused.

         His MIB is operationally focused, but it fails to cover many of the
scenarios which a *standard* TE MIB should support, and will need to be
modified heavily in the future to effectively be able to manage the things
that the MPLS-TE-MIB can manage today. This will effectively duplicate all 
of the
hard work done by folks in the MPLS WG over the past 2 years. I would also
argue that it is focused to support a SMALL subset of MPLS features, in 
particular,
those which are only supported by Juniper switches. It also assumes a 
particular
view of TE tunnels which his product only supports. The MPLS TE MIB does not.
Last I checked, there were many other LSR vendors out there deploying MPLS!
Furthermore, its structure is poor as far as MIBs go. Has anyone actually 
looked
over this MIB? It contains things like the hop table as an OCTET STRING. 
Yea, sure,
it can be modified to be more MIB-correct, but I would argue that doing so 
would
require him to add something like the Hop table which is already in the 
MPLS-TE-MIB,
so it would in the end, look "more complicated" like the MPLS-TE-MIB anyway.

         To comment about the operational deployment of the MPLS MIBs, I 
was cut off
at the meeting before I could explain that there are several deployments of 
the MPLS
LSR/TE MIBs out there now. All seem to work fine, and when they have not,
the implementors have been courteous enough to supply their comments to the 
MPLS
WG mailing list so that we could make the MPLS-TE-MIB better. There is nothing
academic about the MPLS-TE-MIB.

         Finally, if everyone is so concerned with operational deployment,
hasn't anyone considered the fact that two MIBs present an operational pain
for those implementing NMS systems and for those who are implementing
the LSRs? This seems why in the past, there have not been two MIBs deployed
by the IETF to manage the same thing! It means twice the work for those who
wish to implement both, and means totally confusing those who are trying
to manage these systems. Hmmm, which MIB do I use? Oh, this is a vendor X box,
I should use TE-TE-MIB. Oh, this is vendor X v2.3.4, I should use MPLS-TE-MIB.
Totally confusing.  This is why the IETF has deployed a single MIB to
manage a single feature.

>The MPLS WG TE mib seems very focused on configuration.  One might also 
>argue that it could be cumbersome to implement solely to get the benefits 
>of an added perf type table, which by itself can be represented as in 
>Kireeti's draft.  So clearly, they currently address different roles, and 
>as such, appear to have little overlap.

         That is not true. Operational statistics are available in the 
MPLS-TE-MIB,
LSR-MIB and RFC2233 Interfaces MIBs. The MPLS MIBs were all designed to work
together and with the ifMIB. Furthermore, the few features which were not
included in the MPLS-TE-MIB which were in the other draft, can easily be
incorporated, and would have been a long time ago if Kireeti had pointed out
the fact that we had missed them. The MPLS-TE-MIB authors have no beef with
adding or modifying the TE MIB if the WGs think that it needs to be modified.
We also have no objection to working with folks to make certain parts of the
MPLS-TE-MIB optional for those who think that it is somehow too large.
However, we will not know about these concerns unless folks post them
to the WG mailing lists. I am still wondering why Kireeti has not proposed his
specific changes to the MPLS-WG's mailing list.

>Should Kireeti's draft
>a) be accepted as a TE WG item at this time?

         NO.

>b) not be accepted as a TE WG item at this time?

         YES. 1) too confusing having two MIBs to manage the same thing, 2) 
too limited.

>It'd be nice to limit the distro to <te-wg@uu.net>, unless there is 
>objection, to limit sorting through
>duplicate messages.

         Some folks might only be subscribed to the MPLS WG mailing list, 
and will
not be aware of the discussion. I think that we should distribute to both.

         --Tom



From owner-mpls@UU.NET  Fri Aug 18 09:52:16 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28363
	for <mpls-archive@lists.ietf.org>; Fri, 18 Aug 2000 09:52:15 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjctz11898;
	Fri, 18 Aug 2000 13:52:14 GMT
Received: by mail-control.mail.uu.net 
	id QQjctz08176
	for mpls-outgoing; Fri, 18 Aug 2000 13:51:35 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjctz08160
	for <mpls@mail-control.mail.uu.net>; Fri, 18 Aug 2000 13:51:27 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjctz17900
	for <mpls@uu.net>; Fri, 18 Aug 2000 09:51:02 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88])
	id QQjctz17426
	for <mpls@uu.net>; Fri, 18 Aug 2000 13:51:02 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id GAA12006
	for <mpls@uu.net>; Fri, 18 Aug 2000 06:51:19 -0700 (PDT)
Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA09311 for mpls@uu.net; Fri, 18 Aug 2000 09:50:59 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjcsm15219
	for <mpls@mail-control.mail.uu.net>; Fri, 18 Aug 2000 04:12:49 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjcsm16331;
	Fri, 18 Aug 2000 00:12:45 -0400 (EDT)
Received: from hme0.s0092.idc1.oss.level3.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: gdffw1.denver1.level3.net [209.244.1.161])
	id QQjcsm05032;
	Fri, 18 Aug 2000 04:12:15 GMT
Received: from vmboyle1.Level3.com ([10.6.205.121])
	by hme0.s0092.idc1.oss.level3.com (8.8.8+Sun/8.8.8) with ESMTP id WAA28216;
	Thu, 17 Aug 2000 22:12:09 -0600 (MDT)
Message-Id: <4.3.1.0.20000817220828.00bd16b0@10.1.0.131>
X-Sender: jboyle@10.1.0.131
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Thu, 17 Aug 2000 22:19:19 -0600
To: te-wg@UU.NET
From: Jim Boyle <jboyle@Level3.net>
Subject: consensus to make draft-kompella-mpls-te-mib-00.txt a TEWG
  item?
Cc: mpls@UU.NET
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

On July 27 "Cucchiara, Joan" <JCucchiara@Brixnet.com> wrote:
|
|Lastly, is the TE working group going to be developing MIBs and/or PIBs?
|In my opinion this is not clear from the working group's charter.
|
|  Thank you, Joan


It isn't an explicit deliverable in the charter, except that in general the 
TEWG is to "develop ... specify... techniques.. for TE in the Internet"

The interim meeting sort of focused in on
o) why would one do TE
o) what are some of the issues with TE today
o) what measurements are needed to effectively do TE

Mibs fall square in the last one above.  Perhaps a clear re-charter is in 
order on the TE, however.

As for Kireeti's mib, it was mentioned in the interim meeting as a fine 
example of a mib that real operational networks are actually using and that 
it has a good set of operational information needed to monitor and manage 
TE-based networks.  His mib is operationally focused.

The MPLS WG TE mib seems very focused on configuration.  One might also 
argue that it could be cumbersome to implement solely to get the benefits 
of an added perf type table, which by itself can be represented as in 
Kireeti's draft.  So clearly, they currently address different roles, and 
as such, appear to have little overlap.

There was (as usual on Mibs) a bit of apathy in the TE meeting in 
pittsburgh, however it was voiced loudly that standardization of a simple 
straightforward mib is a good thing and Kireeti's draft was likely the most 
appropriate vehicle for this.

So, with that said - I'd like to see what the consensus of the list is.

Should Kireeti's draft
a) be accepted as a TE WG item at this time?
b) not be accepted as a TE WG item at this time?

It'd be nice to limit the distro to <te-wg@uu.net>, unless there is 
objection, to limit sorting through duplicate messages.


thanks,

Jim



From owner-mpls@UU.NET  Fri Aug 18 09:52:33 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28374
	for <mpls-archive@lists.ietf.org>; Fri, 18 Aug 2000 09:52:33 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjctz18624;
	Fri, 18 Aug 2000 13:52:32 GMT
Received: by mail-control.mail.uu.net 
	id QQjctz08204
	for mpls-outgoing; Fri, 18 Aug 2000 13:51:55 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjctz08182
	for <mpls@mail-control.mail.uu.net>; Fri, 18 Aug 2000 13:51:38 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjctz25338
	for <mpls@uu.net>; Fri, 18 Aug 2000 09:51:36 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11])
	id QQjctz11331
	for <mpls@uu.net>; Fri, 18 Aug 2000 13:51:35 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id GAA04506
	for <mpls@uu.net>; Fri, 18 Aug 2000 06:51:52 -0700 (PDT)
Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA09319 for mpls@uu.net; Fri, 18 Aug 2000 09:51:33 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjctv20459
	for <mpls@mail-control.mail.uu.net>; Fri, 18 Aug 2000 12:51:26 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjctv08521
	for <mpls@UU.NET>; Fri, 18 Aug 2000 08:51:11 -0400 (EDT)
Received: from dnsmx2pya.telcordia.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: dnsmx2pya.telcordia.com [128.96.20.32])
	id QQjctv08072
	for <mpls@UU.NET>; Fri, 18 Aug 2000 12:51:05 GMT
Received: from notes949.cc.telcordia.com (notes949a.cc.telcordia.com [128.96.246.8])
	by dnsmx2pya.telcordia.com (8.9.3/8.9.3) with SMTP id IAA18659
	for <mpls@UU.NET>; Fri, 18 Aug 2000 08:51:02 -0400 (EDT)
Received: by notes949.cc.telcordia.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 8525693F.00468D3C ; Fri, 18 Aug 2000 08:50:36 -0400
X-Lotus-FromDomain: TELCORDIA
From: "Ellen Chang" <echang@telcordia.com>
To: mpls@UU.NET
Message-ID: <8525693F.00468AE5.00@notes949.cc.telcordia.com>
Date: Fri, 18 Aug 2000 08:49:47 -0400
Subject: mpls LDP question
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-mpls@UU.NET
Precedence: bulk



Hi,

Is there any document indicates the values for the Message ID field? I could not
find from the LDP spec.


Thank you for your help
Ellen




From owner-mpls@UU.NET  Fri Aug 18 09:52:57 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28392
	for <mpls-archive@lists.ietf.org>; Fri, 18 Aug 2000 09:52:56 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjctz12718;
	Fri, 18 Aug 2000 13:52:56 GMT
Received: by mail-control.mail.uu.net 
	id QQjctz08210
	for mpls-outgoing; Fri, 18 Aug 2000 13:51:57 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjctz08192
	for <mpls@mail-control.mail.uu.net>; Fri, 18 Aug 2000 13:51:48 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjctz17968
	for <mpls@uu.net>; Fri, 18 Aug 2000 09:51:35 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11])
	id QQjctz11114
	for <mpls@uu.net>; Fri, 18 Aug 2000 13:51:19 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id GAA04330
	for <mpls@uu.net>; Fri, 18 Aug 2000 06:51:36 -0700 (PDT)
Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA09315 for mpls@uu.net; Fri, 18 Aug 2000 09:51:17 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjctd16074
	for <mpls@mail-control.mail.uu.net>; Fri, 18 Aug 2000 08:15:00 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjctc13505
	for <mpls@uu.net>; Fri, 18 Aug 2000 04:14:57 -0400 (EDT)
Received: from web9201.mail.yahoo.com by wodc7mr2.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: [216.136.129.34])
	id QQjctc00724
	for <mpls@uu.net>; Fri, 18 Aug 2000 08:14:56 GMT
Message-ID: <20000818081455.3600.qmail@web9201.mail.yahoo.com>
Received: from [209.245.143.9] by web9201.mail.yahoo.com; Fri, 18 Aug 2000 01:14:55 PDT
Date: Fri, 18 Aug 2000 01:14:55 -0700 (PDT)
From: Vishal M <vishal_study@yahoo.com>
Subject: LSP setup time and delay
To: mpls@UU.NET
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk


Hello,

Suppose an IP packet is to sent over a MPLS network.
As I understand the protocol, different components at
the ingres LSR (also called LER) interact in the 
following way:

1. MPLS Signaling Plane (CR-LDP/RSVP) queries the
Routing Plane (IGP Extensions) to get the Explicit 
Path to reach the destination (assuming nothing
in the tables initially).

2. Signaling Plane uses RSVP or CR-LDP to reserve
resources along the explicit path. Label mapping
is performed at the intermediatory LSRs.

3. After the path is set up i.e. LSP is established 
from the source to the destination, the incoming 
packet is forwarded and the rest of the packets follow
the same path.

Questions:

Q1. In the process mentioned above (and if it is the
right sequence), there might be a noticable delay 
between the time the packet arrived at LER and
the time when the LSP is established and actual
traffic starts flowing.

This could lead to two problems:
a. Delay at the LER. If we are dealing with mission 
critical applications, is this delay acceptable ?
b. Memory crunch at the LER (considering OC-192 i/f).

We could have pre-configured tunnels or LSPs to 
circumvent this problem. Are tunnels the way to go to
resolve this ? Is there any other solution (assuming 
this is really a problem !) ?

Q2. I'm not very sure of the Step #3. Is the first 
packet routed ?
I mean, does the first packet go along with the
Resource Resv request OR does it have to wait till the

entire path is established ?

I apologize if this is a very basic question, but
I have trouble understanding this.

Thanks,
Vishal.




__________________________________________________
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/



From owner-mpls@UU.NET  Fri Aug 18 10:08:25 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28706
	for <mpls-archive@lists.ietf.org>; Fri, 18 Aug 2000 10:08:24 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcua24547;
	Fri, 18 Aug 2000 14:08:24 GMT
Received: by mail-control.mail.uu.net 
	id QQjcua21944
	for mpls-outgoing; Fri, 18 Aug 2000 14:07:59 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjcua21927
	for <mpls@mail-control.mail.uu.net>; Fri, 18 Aug 2000 14:07:49 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjcua28604
	for <mpls@UU.NET>; Fri, 18 Aug 2000 10:07:48 -0400 (EDT)
Received: from mailrelay.laurelnetworks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: laurelnetworks.com [206.67.234.84])
	id QQjcua29694
	for <mpls@UU.NET>; Fri, 18 Aug 2000 14:07:17 GMT
Received: from localhost.laurelnetworks.com (IDENT:root@jleu-laptop.laurelnetworks.com [192.168.0.110])
	by mailrelay.laurelnetworks.com (8.9.3/8.9.3) with ESMTP id KAA08942;
	Fri, 18 Aug 2000 10:07:17 -0400
Received: (from jleu@localhost)
	by localhost.laurelnetworks.com (8.9.3/8.9.3) id KAA01190;
	Fri, 18 Aug 2000 10:07:17 -0400
Date: Fri, 18 Aug 2000 10:07:16 -0400
From: "James R. Leu" <jleu@laurelnetworks.com>
To: Vishal M <vishal_study@yahoo.com>
Cc: mpls@UU.NET
Subject: Re: LSP setup time and delay
Message-ID: <20000818100716.A897@laurelnetworks.com>
Reply-To: jleu@laurelnetworks.com
References: <20000818081455.3600.qmail@web9201.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <20000818081455.3600.qmail@web9201.mail.yahoo.com>; from vishal_study@yahoo.com on Fri, Aug 18, 2000 at 01:14:55AM -0700
Organization: Laurel Networks
Sender: owner-mpls@UU.NET
Precedence: bulk

On Fri, Aug 18, 2000 at 01:14:55AM -0700, Vishal M wrote:
> 
> Hello,

LSP setup is not data driven.  The signalling protocols should have setup the
LSP long before the arrival of data.

> Suppose an IP packet is to sent over a MPLS network.
> As I understand the protocol, different components at
> the ingres LSR (also called LER) interact in the 
> following way:
> 
> 1. MPLS Signaling Plane (CR-LDP/RSVP) queries the
> Routing Plane (IGP Extensions) to get the Explicit 
> Path to reach the destination (assuming nothing
> in the tables initially).
> 
> 2. Signaling Plane uses RSVP or CR-LDP to reserve
> resources along the explicit path. Label mapping
> is performed at the intermediatory LSRs.
> 
> 3. After the path is set up i.e. LSP is established 
> from the source to the destination, the incoming 
> packet is forwarded and the rest of the packets follow
> the same path.
> 
> Questions:
> 
> Q1. In the process mentioned above (and if it is the
> right sequence), there might be a noticable delay 
> between the time the packet arrived at LER and
> the time when the LSP is established and actual
> traffic starts flowing.
> 
> This could lead to two problems:
> a. Delay at the LER. If we are dealing with mission 
> critical applications, is this delay acceptable ?
> b. Memory crunch at the LER (considering OC-192 i/f).
> 
> We could have pre-configured tunnels or LSPs to 
> circumvent this problem. Are tunnels the way to go to
> resolve this ? Is there any other solution (assuming 
> this is really a problem !) ?
> 
> Q2. I'm not very sure of the Step #3. Is the first 
> packet routed ?
> I mean, does the first packet go along with the
> Resource Resv request OR does it have to wait till the
> 
> entire path is established ?
> 
> I apologize if this is a very basic question, but
> I have trouble understanding this.
> 
> Thanks,
> Vishal.
> 
> 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Send instant messages & get email alerts with Yahoo! Messenger.
> http://im.yahoo.com/

-- 
James R. Leu
Software Engineer
Laurel Networks, Inc
jleu@laurelnetworks.com


From owner-mpls@UU.NET  Fri Aug 18 10:18:34 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28883
	for <mpls-archive@lists.ietf.org>; Fri, 18 Aug 2000 10:18:33 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcub02299;
	Fri, 18 Aug 2000 14:18:33 GMT
Received: by mail-control.mail.uu.net 
	id QQjcub23275
	for mpls-outgoing; Fri, 18 Aug 2000 14:18:13 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjcub23270
	for <mpls@mail-control.mail.uu.net>; Fri, 18 Aug 2000 14:18:06 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjcub22722
	for <mpls@UU.NET>; Fri, 18 Aug 2000 10:16:50 -0400 (EDT)
Received: from mailrelay.laurelnetworks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: laurelnetworks.com [206.67.234.84])
	id QQjcub06710
	for <mpls@UU.NET>; Fri, 18 Aug 2000 14:16:50 GMT
Received: from localhost.laurelnetworks.com (IDENT:root@jleu-laptop.laurelnetworks.com [192.168.0.110])
	by mailrelay.laurelnetworks.com (8.9.3/8.9.3) with ESMTP id KAA09566;
	Fri, 18 Aug 2000 10:16:48 -0400
Received: (from jleu@localhost)
	by localhost.laurelnetworks.com (8.9.3/8.9.3) id KAA01210;
	Fri, 18 Aug 2000 10:16:48 -0400
Date: Fri, 18 Aug 2000 10:16:48 -0400
From: "James R. Leu" <jleu@laurelnetworks.com>
To: Ellen Chang <echang@telcordia.com>
Cc: mpls@UU.NET
Subject: Re: mpls LDP question
Message-ID: <20000818101648.B897@laurelnetworks.com>
Reply-To: jleu@laurelnetworks.com
References: <8525693F.00468AE5.00@notes949.cc.telcordia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <8525693F.00468AE5.00@notes949.cc.telcordia.com>; from echang@telcordia.com on Fri, Aug 18, 2000 at 08:49:47AM -0400
Organization: Laurel Networks
Sender: owner-mpls@UU.NET
Precedence: bulk

On Fri, Aug 18, 2000 at 08:49:47AM -0400, Ellen Chang wrote:
> 
> 
> Hi,
> 
> Is there any document indicates the values for the Message ID field? I could not
> find from the LDP spec.

Ellen,

Look at section "3.5. LDP Messages".  The 32 bit value is determined by the
sending LSR (an implementation MAY decide to simply incrementing the Message 
ID for every message).  The sender should keep track of the Message Id
it uses in messages that may result in a response (of some sort).

Jim

> 
> Thank you for your help
> Ellen
> 

-- 
James R. Leu
Software Engineer
Laurel Networks, Inc
jleu@laurelnetworks.com


From owner-mpls@UU.NET  Fri Aug 18 10:22:32 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28967
	for <mpls-archive@lists.ietf.org>; Fri, 18 Aug 2000 10:22:31 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcub05439;
	Fri, 18 Aug 2000 14:22:31 GMT
Received: by mail-control.mail.uu.net 
	id QQjcub24171
	for mpls-outgoing; Fri, 18 Aug 2000 14:22:12 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjcub24134
	for <mpls@mail-control.mail.uu.net>; Fri, 18 Aug 2000 14:22:04 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjcub01503
	for <mpls@uu.net>; Fri, 18 Aug 2000 10:22:00 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjcub10340
	for <mpls@uu.net>; Fri, 18 Aug 2000 14:21:45 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA21069
	for mpls@uu.net; Fri, 18 Aug 2000 10:20:56 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjcub23645
	for <mpls@mail-control.mail.uu.net>; Fri, 18 Aug 2000 14:20:27 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjcub23274
	for <mpls@UU.NET>; Fri, 18 Aug 2000 10:20:09 -0400 (EDT)
Received: from procyon.pmc-sierra.bc.ca by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1])
	id QQjcub03379
	for <mpls@UU.NET>; Fri, 18 Aug 2000 14:19:53 GMT
Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183])
	by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id HAA07395;
	Fri, 18 Aug 2000 07:19:47 -0700 (PDT)
Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21)
	id <QPVGQ8ZL>; Fri, 18 Aug 2000 07:22:44 -0700
Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B40731@nt-exchange-bby.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'Vishal M'" <vishal_study@yahoo.com>, mpls@UU.NET
Subject: RE: LSP setup time and delay
Date: Fri, 18 Aug 2000 07:22:40 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Vishal,

What you are describing is called "data driven label assignment". This is
explained in framework document, and requires L3 forwarding until the LSP is
setup. Due to its problems it has not been pursued further by MPLS WG
(however, some implementations exist). Control driven label assignment is
the one most of the people are working on.

Regards,
-Shahram

>-----Original Message-----
>From: Vishal M [mailto:vishal_study@yahoo.com]
>Sent: Friday, August 18, 2000 4:15 AM
>To: mpls@UU.NET
>Subject: LSP setup time and delay
>
>
>
>Hello,
>
>Suppose an IP packet is to sent over a MPLS network.
>As I understand the protocol, different components at
>the ingres LSR (also called LER) interact in the 
>following way:
>
>1. MPLS Signaling Plane (CR-LDP/RSVP) queries the
>Routing Plane (IGP Extensions) to get the Explicit 
>Path to reach the destination (assuming nothing
>in the tables initially).
>
>2. Signaling Plane uses RSVP or CR-LDP to reserve
>resources along the explicit path. Label mapping
>is performed at the intermediatory LSRs.
>
>3. After the path is set up i.e. LSP is established 
>from the source to the destination, the incoming 
>packet is forwarded and the rest of the packets follow
>the same path.
>
>Questions:
>
>Q1. In the process mentioned above (and if it is the
>right sequence), there might be a noticable delay 
>between the time the packet arrived at LER and
>the time when the LSP is established and actual
>traffic starts flowing.
>
>This could lead to two problems:
>a. Delay at the LER. If we are dealing with mission 
>critical applications, is this delay acceptable ?
>b. Memory crunch at the LER (considering OC-192 i/f).
>
>We could have pre-configured tunnels or LSPs to 
>circumvent this problem. Are tunnels the way to go to
>resolve this ? Is there any other solution (assuming 
>this is really a problem !) ?
>
>Q2. I'm not very sure of the Step #3. Is the first 
>packet routed ?
>I mean, does the first packet go along with the
>Resource Resv request OR does it have to wait till the
>
>entire path is established ?
>
>I apologize if this is a very basic question, but
>I have trouble understanding this.
>
>Thanks,
>Vishal.
>
>
>
>
>__________________________________________________
>Do You Yahoo!?
>Send instant messages & get email alerts with Yahoo! Messenger.
>http://im.yahoo.com/
>



From owner-mpls@UU.NET  Fri Aug 18 10:24:28 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28998
	for <mpls-archive@lists.ietf.org>; Fri, 18 Aug 2000 10:24:27 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcub07242;
	Fri, 18 Aug 2000 14:24:27 GMT
Received: by mail-control.mail.uu.net 
	id QQjcub24506
	for mpls-outgoing; Fri, 18 Aug 2000 14:23:59 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjcub24488
	for <mpls@mail-control.mail.uu.net>; Fri, 18 Aug 2000 14:23:52 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjcub23860
	for <mpls@uu.net>; Fri, 18 Aug 2000 10:23:29 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjcub11768
	for <mpls@uu.net>; Fri, 18 Aug 2000 14:23:28 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA21556
	for mpls@uu.net; Fri, 18 Aug 2000 10:23:27 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjcub24241
	for <mpls@mail-control.mail.uu.net>; Fri, 18 Aug 2000 14:22:53 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjcub23663;
	Fri, 18 Aug 2000 10:22:25 -0400 (EDT)
Received: from hawk.CrescentNetworks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.177.194.54])
	id QQjcub10610;
	Fri, 18 Aug 2000 14:22:09 GMT
Received: from crescentnetworks.com (langille.in.crescentnets.com [192.168.29.105])
	by hawk.CrescentNetworks.com (8.9.3/8.9.3) with ESMTP id KAA16302;
	Fri, 18 Aug 2000 10:22:06 -0400 (EDT)
Message-ID: <399D47E2.FCBEDC@crescentnetworks.com>
Date: Fri, 18 Aug 2000 10:27:46 -0400
From: Paul Langille <langille@CrescentNetworks.com>
Organization: Crescent Networks
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jim Boyle <jboyle@level3.net>
CC: te-wg@UU.NET, mpls@UU.NET
Subject: Re: consensus to make draft-kompella-mpls-te-mib-00.txt a TEWGitem?
References: <4.3.1.0.20000817220828.00bd16b0@10.1.0.131>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


Jim Boyle wrote:

<snip>

>
> So, with that said - I'd like to see what the consensus of the list is.
>
> Should Kireeti's draft
> a) be accepted as a TE WG item at this time?
> b) not be accepted as a TE WG item at this time?
>

    I vote for "b". I don't think this MIB is quite ready for 'prime time'.
There are a few issues that (in my humble opinion) need to be addressed.

    1) I don't understand why the 'interesting' objects in Kireeti's MIB cannot
be folded into the TE-MIB. A lot of the objects are duplicates. I would like to
implement just one MIB. What are the pros and cons of merging these two drafts?
(I feel you need a pretty strong argument to justify the duplication.)

    2) What is the real 'purpose' of Kireeti's MIB. I would like to see a model
or some other draft that gives a better description of the objects in the MIB
(i.e. it needs reference clauses on many of the objects). I think a lot of the
objects in the MIB need clearer definition. Most MIBs tend to be a fallout of
an existing draft. (For example the TE-MIB is based on CR-LDP and RSVP
Tunnels.) Defining functionality via a MIB is typically a difficult process.
Diffserv ran into this problem when they started the Diffserv-MIB. To clearly
understand the specific objects Diffserv needed the model draft. (I am not
saying that we need a model draft but I feel this draft needs some sort of
reference. Without this reference we will spin for a long time on the object
definitions.)

        Paul
--
Paul Langille                e-mail: langille@crescentnetworks.com
Crescent Networks            phone: (978) 244-9002 x244
201 Riverneck Road           fax: (978) 244-9211
Chelmsford, MA 01824




From owner-mpls@UU.NET  Fri Aug 18 10:50:36 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29554
	for <mpls-archive@lists.ietf.org>; Fri, 18 Aug 2000 10:50:35 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcud01927;
	Fri, 18 Aug 2000 14:50:35 GMT
Received: by mail-control.mail.uu.net 
	id QQjcud27572
	for mpls-outgoing; Fri, 18 Aug 2000 14:50:00 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjcud27549
	for <mpls@mail-control.mail.uu.net>; Fri, 18 Aug 2000 14:49:51 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjcud28542
	for <mpls@UU.NET>; Fri, 18 Aug 2000 10:49:26 -0400 (EDT)
From: Tim.Cook@go.ecitele.com
Received: from mizar.ftl.telematics.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailhost.telematics.com [147.137.1.7])
	id QQjcud25355
	for <mpls@UU.NET>; Fri, 18 Aug 2000 14:49:26 GMT
Received: from ussmtp01.ftl.telematics.com (ussmtp01 [147.137.15.41])
	by mizar.ftl.telematics.com (8.9.1/8.9.1) with SMTP id KAA00304;
	Fri, 18 Aug 2000 10:48:07 -0400 (EDT)
Received: by ussmtp01.ftl.telematics.com(Lotus SMTP MTA v4.6.2  (693.3 8-11-1998))  id 8525693F.00514489 ; Fri, 18 Aug 2000 10:47:39 -0400
X-Lotus-FromDomain: ECI TELECOM
To: Shahram Davari <Shahram_Davari@pmc-sierra.com>
cc: "'Vishal M'" <vishal_study@yahoo.com>, mpls@UU.NET
Message-ID: <8525693F.005143BA.00@ussmtp01.ftl.telematics.com>
Date: Fri, 18 Aug 2000 10:48:33 -0400
Subject: RE: LSP setup time and delay
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-mpls@UU.NET
Precedence: bulk



Does this mean that there is no L3 forwarding between two LSRs (all traffic
is labeled)?




Shahram Davari <Shahram_Davari@pmc-sierra.com> on 08/18/2000 10:22:40 AM
                                                              
                                                              
                                                              
 To:      "'Vishal M'" <vishal_study@yahoo.com>, mpls@UU.NET  
                                                              
 cc:      (bcc: Tim Cook/Fort Lauderdale/ECI Telecom)         
                                                              
                                                              
                                                              
 Subject: RE: LSP setup time and delay                        
                                                              








Vishal,

What you are describing is called "data driven label assignment". This is
explained in framework document, and requires L3 forwarding until the LSP
is
setup. Due to its problems it has not been pursued further by MPLS WG
(however, some implementations exist). Control driven label assignment is
the one most of the people are working on.

Regards,
-Shahram

>-----Original Message-----
>From: Vishal M [mailto:vishal_study@yahoo.com]
>Sent: Friday, August 18, 2000 4:15 AM
>To: mpls@UU.NET
>Subject: LSP setup time and delay
>
>
>
>Hello,
>
>Suppose an IP packet is to sent over a MPLS network.
>As I understand the protocol, different components at
>the ingres LSR (also called LER) interact in the
>following way:
>
>1. MPLS Signaling Plane (CR-LDP/RSVP) queries the
>Routing Plane (IGP Extensions) to get the Explicit
>Path to reach the destination (assuming nothing
>in the tables initially).
>
>2. Signaling Plane uses RSVP or CR-LDP to reserve
>resources along the explicit path. Label mapping
>is performed at the intermediatory LSRs.
>
>3. After the path is set up i.e. LSP is established
>from the source to the destination, the incoming
>packet is forwarded and the rest of the packets follow
>the same path.
>
>Questions:
>
>Q1. In the process mentioned above (and if it is the
>right sequence), there might be a noticable delay
>between the time the packet arrived at LER and
>the time when the LSP is established and actual
>traffic starts flowing.
>
>This could lead to two problems:
>a. Delay at the LER. If we are dealing with mission
>critical applications, is this delay acceptable ?
>b. Memory crunch at the LER (considering OC-192 i/f).
>
>We could have pre-configured tunnels or LSPs to
>circumvent this problem. Are tunnels the way to go to
>resolve this ? Is there any other solution (assuming
>this is really a problem !) ?
>
>Q2. I'm not very sure of the Step #3. Is the first
>packet routed ?
>I mean, does the first packet go along with the
>Resource Resv request OR does it have to wait till the
>
>entire path is established ?
>
>I apologize if this is a very basic question, but
>I have trouble understanding this.
>
>Thanks,
>Vishal.
>
>
>
>
>__________________________________________________
>Do You Yahoo!?
>Send instant messages & get email alerts with Yahoo! Messenger.
>http://im.yahoo.com/
>






From owner-mpls@UU.NET  Fri Aug 18 10:54:36 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29674
	for <mpls-archive@lists.ietf.org>; Fri, 18 Aug 2000 10:54:35 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcud05467;
	Fri, 18 Aug 2000 14:54:36 GMT
Received: by mail-control.mail.uu.net 
	id QQjcud28152
	for mpls-outgoing; Fri, 18 Aug 2000 14:54:02 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjcud28119
	for <mpls@mail-control.mail.uu.net>; Fri, 18 Aug 2000 14:53:44 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjcud07965
	for <mpls@uu.net>; Fri, 18 Aug 2000 10:53:43 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjcud04511
	for <mpls@uu.net>; Fri, 18 Aug 2000 14:53:27 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA26466
	for mpls@uu.net; Fri, 18 Aug 2000 10:53:27 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjcud27978
	for <mpls@mail-control.mail.uu.net>; Fri, 18 Aug 2000 14:52:44 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjcud07763;
	Fri, 18 Aug 2000 10:52:37 -0400 (EDT)
Received: from funnel.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQjcud03631;
	Fri, 18 Aug 2000 14:52:22 GMT
Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.131.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA20417; Fri, 18 Aug 2000 10:52:21 -0400 (EDT)
Received: from tnadeau-pc02.cisco.com ([161.44.204.102])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AAJ16498;
	Fri, 18 Aug 2000 10:52:19 -0400 (EDT)
Message-Id: <4.3.2.7.2.20000818103207.04dad230@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 18 Aug 2000 10:42:22 -0400
To: Randy Bush <randy@psg.com>, Paul Langille <langille@CrescentNetworks.com>
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Subject: Re: consensus to make draft-kompella-mpls-te-mib-00.txt a
  TEWGitem?
Cc: te-wg@UU.NET, mpls@UU.NET
In-Reply-To: <E13PnJI-0007gW-00@rip.psg.com>
References: <4.3.1.0.20000817220828.00bd16b0@10.1.0.131>
 <399D47E2.FCBEDC@crescentnetworks.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk


> > 1) I don't understand why the 'interesting' objects in Kireeti's MIB cannot
> > be folded into the TE-MIB.
>
>there are two kinds of designs, union and intersection.  the former is the
>union of everyone's laundry lists, the latter the minimal intersection.
>conversations between the two tend to go like
>   user: the X is far too complex, we only need F
>   union: you want F, we will add F
>   user: but we don't want the weight of A, B, C, D, E, and G through Z
>   union: what do you think X is missing?
>   user: it's not so much what it's missing, its all that other stuff it has
>   ...

         There are several flaws with this argument.

         0) This can be accomplished by adjusting the conformance
                 statement of the existing MIBs. The MPLS-TE-MIB authors
                 are perfectly willing to work with you guys to define
                 how this should be done.

         1) There will be a duplication of work. The so-called minimalist
                 MIB will still have to support generic TE functionallity,
                 which is already defined by the MPLS-TE-MIB. Why re-invent
                 the wheel?

         2) Because it is a so-called minimalist design, it only incorporates
                 the minimalist design of one particular implementation.
                 This is because it is essentially a proprietary MIB.

         3) When does one stop using the so-called minimal one and start
                 using the MPLS-TE-MIB? When one wants to inter-operate? If
                 you are really concerned with operational functionality,
                 then this reason alone would tell you to NOT have 2 MIBs.

> > 2) What is the real 'purpose' of Kireeti's MIB.
>
>finding out where router R will send traffic T in a nice simple way that
>operational people tend to use.

         That is very subjective. The MPLS-TE-MIB does this in a nice
         and simple way too and works for all implementations, not just
         the ones which have currently implemented Kireeti's products. 
There
         are several folks who have or who are implementing the MPLS-TE-MIB,
         and these folks have not found it to be overly cumbersome to
         implement or to use.

         --Tom




From owner-mpls@UU.NET  Fri Aug 18 11:28:02 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00429
	for <mpls-archive@lists.ietf.org>; Fri, 18 Aug 2000 11:28:02 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcuf00285;
	Fri, 18 Aug 2000 15:28:03 GMT
Received: by mail-control.mail.uu.net 
	id QQjcuf14047
	for mpls-outgoing; Fri, 18 Aug 2000 15:27:24 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjcuf14040
	for <mpls@mail-control.mail.uu.net>; Fri, 18 Aug 2000 15:27:23 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjcuf05719
	for <mpls@uu.net>; Fri, 18 Aug 2000 11:27:09 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjcuf23315
	for <mpls@uu.net>; Fri, 18 Aug 2000 15:27:09 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA01273
	for mpls@uu.net; Fri, 18 Aug 2000 11:27:08 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjcuf13897
	for <mpls@mail-control.mail.uu.net>; Fri, 18 Aug 2000 15:26:32 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjcuf05586
	for <mpls@UU.NET>; Fri, 18 Aug 2000 11:26:20 -0400 (EDT)
Received: from procyon.pmc-sierra.bc.ca by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1])
	id QQjcuf22683
	for <mpls@UU.NET>; Fri, 18 Aug 2000 15:26:20 GMT
Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183])
	by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id IAA20804;
	Fri, 18 Aug 2000 08:25:39 -0700 (PDT)
Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21)
	id <QPVGQ9SB>; Fri, 18 Aug 2000 08:28:37 -0700
Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B40736@nt-exchange-bby.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'Tim.Cook@go.ecitele.com'" <Tim.Cook@go.ecitele.com>,
        Shahram Davari
	 <Shahram_Davari@pmc-sierra.com>
Cc: "'Vishal M'" <vishal_study@yahoo.com>, mpls@UU.NET
Subject: RE: LSP setup time and delay
Date: Fri, 18 Aug 2000 08:28:32 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Tim,

No. Control packets are L3 forwarded. Also in data driven method, the
packets are initially L3 forwarded and then switched to L2 forwarding when
LSP is setup.

-Shahram

>-----Original Message-----
>From: Tim.Cook@go.ecitele.com [mailto:Tim.Cook@go.ecitele.com]
>Sent: Friday, August 18, 2000 10:49 AM
>To: Shahram Davari
>Cc: 'Vishal M'; mpls@UU.NET
>Subject: RE: LSP setup time and delay
>
>
>
>
>Does this mean that there is no L3 forwarding between two LSRs 
>(all traffic
>is labeled)?
>
>
>
>
>Shahram Davari <Shahram_Davari@pmc-sierra.com> on 08/18/2000 
>10:22:40 AM
>                                                              
>                                                              
>                                                              
> To:      "'Vishal M'" <vishal_study@yahoo.com>, mpls@UU.NET  
>                                                              
> cc:      (bcc: Tim Cook/Fort Lauderdale/ECI Telecom)         
>                                                              
>                                                              
>                                                              
> Subject: RE: LSP setup time and delay                        
>                                                              
>
>
>
>
>
>
>
>
>Vishal,
>
>What you are describing is called "data driven label 
>assignment". This is
>explained in framework document, and requires L3 forwarding 
>until the LSP
>is
>setup. Due to its problems it has not been pursued further by MPLS WG
>(however, some implementations exist). Control driven label 
>assignment is
>the one most of the people are working on.
>
>Regards,
>-Shahram
>
>>-----Original Message-----
>>From: Vishal M [mailto:vishal_study@yahoo.com]
>>Sent: Friday, August 18, 2000 4:15 AM
>>To: mpls@UU.NET
>>Subject: LSP setup time and delay
>>
>>
>>
>>Hello,
>>
>>Suppose an IP packet is to sent over a MPLS network.
>>As I understand the protocol, different components at
>>the ingres LSR (also called LER) interact in the
>>following way:
>>
>>1. MPLS Signaling Plane (CR-LDP/RSVP) queries the
>>Routing Plane (IGP Extensions) to get the Explicit
>>Path to reach the destination (assuming nothing
>>in the tables initially).
>>
>>2. Signaling Plane uses RSVP or CR-LDP to reserve
>>resources along the explicit path. Label mapping
>>is performed at the intermediatory LSRs.
>>
>>3. After the path is set up i.e. LSP is established
>>from the source to the destination, the incoming
>>packet is forwarded and the rest of the packets follow
>>the same path.
>>
>>Questions:
>>
>>Q1. In the process mentioned above (and if it is the
>>right sequence), there might be a noticable delay
>>between the time the packet arrived at LER and
>>the time when the LSP is established and actual
>>traffic starts flowing.
>>
>>This could lead to two problems:
>>a. Delay at the LER. If we are dealing with mission
>>critical applications, is this delay acceptable ?
>>b. Memory crunch at the LER (considering OC-192 i/f).
>>
>>We could have pre-configured tunnels or LSPs to
>>circumvent this problem. Are tunnels the way to go to
>>resolve this ? Is there any other solution (assuming
>>this is really a problem !) ?
>>
>>Q2. I'm not very sure of the Step #3. Is the first
>>packet routed ?
>>I mean, does the first packet go along with the
>>Resource Resv request OR does it have to wait till the
>>
>>entire path is established ?
>>
>>I apologize if this is a very basic question, but
>>I have trouble understanding this.
>>
>>Thanks,
>>Vishal.
>>
>>
>>
>>
>>__________________________________________________
>>Do You Yahoo!?
>>Send instant messages & get email alerts with Yahoo! Messenger.
>>http://im.yahoo.com/
>>
>
>
>
>



From owner-mpls@UU.NET  Fri Aug 18 11:30:58 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00478
	for <mpls-archive@lists.ietf.org>; Fri, 18 Aug 2000 11:30:57 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcug26168;
	Fri, 18 Aug 2000 15:30:58 GMT
Received: by mail-control.mail.uu.net 
	id QQjcug14592
	for mpls-outgoing; Fri, 18 Aug 2000 15:30:37 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjcug14486
	for <mpls@mail-control.mail.uu.net>; Fri, 18 Aug 2000 15:30:25 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjcug15142
	for <mpls@uu.net>; Fri, 18 Aug 2000 11:30:11 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjcug25515
	for <mpls@uu.net>; Fri, 18 Aug 2000 15:30:10 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA01937
	for mpls@uu.net; Fri, 18 Aug 2000 11:30:09 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjcuf14331
	for <mpls@mail-control.mail.uu.net>; Fri, 18 Aug 2000 15:29:32 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjcuf14932;
	Fri, 18 Aug 2000 11:29:24 -0400 (EDT)
Received: from tnnt3.tachion.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [198.139.117.130])
	id QQjcuf24851;
	Fri, 18 Aug 2000 15:29:24 GMT
Received: by TNNT3 with Internet Mail Service (5.5.2650.21)
	id <RB4DD0VH>; Fri, 18 Aug 2000 11:33:05 -0400
Message-ID: <A64EB7AC0201D411B864009027DC856C054D8B@TNNT3>
From: Cheenu Srinivasan <csrinivasan@tachion.com>
To: te-wg@UU.NET, mpls@UU.NET
Cc: "'Jim Boyle'" <jboyle@Level3.net>
Subject: RE: consensus to make draft-kompella-mpls-te-mib-00.txt a TEWG it
	em?
Date: Fri, 18 Aug 2000 11:32:56 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C00929.99FE94A2"
Sender: owner-mpls@UU.NET
Precedence: bulk

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_01C00929.99FE94A2
Content-Type: text/plain;
	charset="iso-8859-1"

Jim Boyle wrote:
> 
> Should Kireeti's draft
> a) be accepted as a TE WG item at this time?
> b) not be accepted as a TE WG item at this time?

Kireeti's MIB doesn't address numerous issues that would be necessary in a
standard TE MIB. It supports a very limited model of TE using MPLS (specific
to Juniper's switches). And, to put it bluntly, its quite badly designed
stylistically as well. Its not a good idea to forget to "keep things as
simple
as possible but no simpler" or we would end up with 

There already exists, and has existed for quite a while, a TE MIB in the
mplswg. This MIB is generic and has evolved to incorporate the comments of
the mplswg. Also, it has been deployed in several switches. And, there are
very good operational and implementation reasons

So, Kireeti's draft should not be a working group document. If there is any
functionality that is needed in the existing TE MIB, based on WG consensus,
it can be added and that is the best course of action at this point.

>It'd be nice to limit the distro to <te-wg@uu.net>, unless there is 
>objection, to limit sorting through duplicate messages.

Many people with an interest in this thread may not be subscribed to the
TE list. Let's keep the discussion on both lists.

Thanks,
Cheenu


------_=_NextPart_001_01C00929.99FE94A2
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2650.12">
<TITLE>RE: consensus to make draft-kompella-mpls-te-mib-00.txt a TEWG item?</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Jim Boyle wrote:</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Should Kireeti's draft</FONT>
<BR><FONT SIZE=2>&gt; a) be accepted as a TE WG item at this time?</FONT>
<BR><FONT SIZE=2>&gt; b) not be accepted as a TE WG item at this time?</FONT>
</P>

<P><FONT SIZE=2>Kireeti's MIB doesn't address numerous issues that would be necessary in a</FONT>
<BR><FONT SIZE=2>standard TE MIB. It supports a very limited model of TE using MPLS (specific</FONT>
<BR><FONT SIZE=2>to Juniper's switches). And, to put it bluntly, its quite badly designed</FONT>
<BR><FONT SIZE=2>stylistically as well. Its not a good idea to forget to &quot;keep things as simple</FONT>
<BR><FONT SIZE=2>as possible but no simpler&quot; or we would end up with </FONT>
</P>

<P><FONT SIZE=2>There already exists, and has existed for quite a while, a TE MIB in the</FONT>
<BR><FONT SIZE=2>mplswg. This MIB is generic and has evolved to incorporate the comments of</FONT>
<BR><FONT SIZE=2>the mplswg. Also, it has been deployed in several switches. And, there are</FONT>
<BR><FONT SIZE=2>very good operational and implementation reasons</FONT>
</P>

<P><FONT SIZE=2>So, Kireeti's draft should not be a working group document. If there is any</FONT>
<BR><FONT SIZE=2>functionality that is needed in the existing TE MIB, based on WG consensus,</FONT>
<BR><FONT SIZE=2>it can be added and that is the best course of action at this point.</FONT>
</P>

<P><FONT SIZE=2>&gt;It'd be nice to limit the distro to &lt;te-wg@uu.net&gt;, unless there is </FONT>
<BR><FONT SIZE=2>&gt;objection, to limit sorting through duplicate messages.</FONT>
</P>

<P><FONT SIZE=2>Many people with an interest in this thread may not be subscribed to the</FONT>
<BR><FONT SIZE=2>TE list. Let's keep the discussion on both lists.</FONT>
</P>

<P><FONT SIZE=2>Thanks,</FONT>
<BR><FONT SIZE=2>Cheenu</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C00929.99FE94A2--



From owner-mpls@UU.NET  Fri Aug 18 11:32:49 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00576
	for <mpls-archive@lists.ietf.org>; Fri, 18 Aug 2000 11:32:48 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcug28088;
	Fri, 18 Aug 2000 15:32:50 GMT
Received: by mail-control.mail.uu.net 
	id QQjcug15044
	for mpls-outgoing; Fri, 18 Aug 2000 15:32:31 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjcug15019
	for <mpls@mail-control.mail.uu.net>; Fri, 18 Aug 2000 15:32:23 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjcug15560
	for <mpls@UU.NET>; Fri, 18 Aug 2000 11:32:17 -0400 (EDT)
Received: from ennovatenetworks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ennovatenetworks.com [208.227.99.254])
	id QQjcug03662
	for <mpls@UU.NET>; Fri, 18 Aug 2000 15:32:02 GMT
Received: from tworster (dhcp114.tst.ennovatenetworks.com [10.1.3.114])
	by ennovatenetworks.com (8.8.7/8.8.7) with SMTP id LAA21336;
	Fri, 18 Aug 2000 11:31:30 -0400 (EDT)
	(envelope-from tom@ennovatenetworks.com)
From: "tom worster" <tom@ennovatenetworks.com>
To: <jleu@laurelnetworks.com>
Cc: <mpls@UU.NET>
Subject: RE: LSP setup time and delay
Date: Fri, 18 Aug 2000 11:32:27 -0400
Message-ID: <000c01c00929$842d14f0$7203010a@ennovatenetworks.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <20000818100716.A897@laurelnetworks.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

From: James R. Leu
> 
> LSP setup is not data driven.  The signalling protocols 
> should have setup the
> LSP long before the arrival of data.

i hadn't noticed that mpls specified this. i though it was
up to the application (e.g. te) to decide when to set up an 
lsp.

c u
tom


From owner-mpls@UU.NET  Fri Aug 18 11:38:30 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00728
	for <mpls-archive@lists.ietf.org>; Fri, 18 Aug 2000 11:38:30 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcug02405;
	Fri, 18 Aug 2000 15:38:31 GMT
Received: by mail-control.mail.uu.net 
	id QQjcug15745
	for mpls-outgoing; Fri, 18 Aug 2000 15:38:11 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjcug15735
	for <mpls@mail-control.mail.uu.net>; Fri, 18 Aug 2000 15:38:07 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjcug07664;
	Fri, 18 Aug 2000 11:37:35 -0400 (EDT)
Received: from icarian.ZAFFIRE.COM by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ATHM-64-232-xxx-132.home.net [64.232.69.132] (may be forged))
	id QQjcug01657;
	Fri, 18 Aug 2000 15:37:35 GMT
Received: by ICARIAN with Internet Mail Service (5.5.2650.21)
	id <QX14ZMMP>; Fri, 18 Aug 2000 08:45:34 -0700
Message-ID: <4D3F9F2BEC58D4118FCE009027B0A66213615D@ICARIAN>
From: Eric Gray <EGray@zaffire.com>
To: "'Thomas D. Nadeau'" <tnadeau@cisco.com>, Randy Bush <randy@psg.com>,
        Paul Langille <langille@CrescentNetworks.com>
Cc: te-wg@UU.NET, mpls@UU.NET
Subject: RE: consensus to make draft-kompella-mpls-te-mib-00.txt a TEWGite
	m?
Date: Fri, 18 Aug 2000 08:45:25 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Randy, et al -

	What Tom has been saying makes a lot of sense.

	If operators want only to deal with a simplified 
MIB - containing (for instance) only those read-only
objects that they need, then the TE working group should
define a subset of the TE-MIB that applies to their needs.
The it falls to the authors of the TE-MIB to make sure it
contains (or continues to contain) all of the objects in
that subset - even if that means adding some to the MIB.

	That way, you don't end up having to support 2 MIBs
with significant overlap and the operators are ensured 
that they can manage their networks in the way that they
would like to.

	This also seems to be an appropriate division of
labor.

	Thanks!

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
> Sent: Friday, August 18, 2000 7:42 AM
> To: Randy Bush; Paul Langille
> Cc: te-wg@UU.NET; mpls@UU.NET
> Subject: Re: consensus to make draft-kompella-mpls-te-mib-00.txt a
> TEWGitem?
> 
> 
> 
> > > 1) I don't understand why the 'interesting' objects in 
> Kireeti's MIB cannot
> > > be folded into the TE-MIB.
> >
> >there are two kinds of designs, union and intersection.  the 
> former is the
> >union of everyone's laundry lists, the latter the minimal 
> intersection.
> >conversations between the two tend to go like
> >   user: the X is far too complex, we only need F
> >   union: you want F, we will add F
> >   user: but we don't want the weight of A, B, C, D, E, and 
> G through Z
> >   union: what do you think X is missing?
> >   user: it's not so much what it's missing, its all that 
> other stuff it has
> >   ...
> 
>          There are several flaws with this argument.
> 
>          0) This can be accomplished by adjusting the conformance
>                  statement of the existing MIBs. The 
> MPLS-TE-MIB authors
>                  are perfectly willing to work with you guys to define
>                  how this should be done.
> 
>          1) There will be a duplication of work. The 
> so-called minimalist
>                  MIB will still have to support generic TE 
> functionallity,
>                  which is already defined by the MPLS-TE-MIB. 
> Why re-invent
>                  the wheel?
> 
>          2) Because it is a so-called minimalist design, it 
> only incorporates
>                  the minimalist design of one particular 
> implementation.
>                  This is because it is essentially a proprietary MIB.
> 
>          3) When does one stop using the so-called minimal 
> one and start
>                  using the MPLS-TE-MIB? When one wants to 
> inter-operate? If
>                  you are really concerned with operational 
> functionality,
>                  then this reason alone would tell you to NOT 
> have 2 MIBs.
> 
> > > 2) What is the real 'purpose' of Kireeti's MIB.
> >
> >finding out where router R will send traffic T in a nice 
> simple way that
> >operational people tend to use.
> 
>          That is very subjective. The MPLS-TE-MIB does this in a nice
>          and simple way too and works for all 
> implementations, not just
>          the ones which have currently implemented Kireeti's 
> products. 
> There
>          are several folks who have or who are implementing 
> the MPLS-TE-MIB,
>          and these folks have not found it to be overly cumbersome to
>          implement or to use.
> 
>          --Tom
> 
> 


From owner-mpls@UU.NET  Fri Aug 18 12:41:14 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01942
	for <mpls-archive@lists.ietf.org>; Fri, 18 Aug 2000 12:41:14 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcuk17444;
	Fri, 18 Aug 2000 16:41:13 GMT
Received: by mail-control.mail.uu.net 
	id QQjcuk03905
	for mpls-outgoing; Fri, 18 Aug 2000 16:40:51 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjcuk03893
	for <mpls@mail-control.mail.uu.net>; Fri, 18 Aug 2000 16:40:44 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjcuk27829
	for <mpls@UU.NET>; Fri, 18 Aug 2000 12:40:41 -0400 (EDT)
Received: from hermes.research.kpn.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: hermes.research.kpn.com [139.63.192.8])
	id QQjcuk16611
	for <mpls@UU.NET>; Fri, 18 Aug 2000 16:40:10 GMT
Received: from l04.research.kpn.com (l04.research.kpn.com [139.63.192.204])
 by research.kpn.com (PMDF V5.2-31 #42699)
 with ESMTP id <01JT4J194YMQ000AMK@research.kpn.com> for mpls@UU.NET; Fri,
 18 Aug 2000 18:40:08 +0200
Received: by l04.research.kpn.com with Internet Mail Service (5.5.2650.21)
	id <PQ1DXCK7>; Fri, 18 Aug 2000 18:40:07 +0100
Content-return: allowed
Date: Fri, 18 Aug 2000 18:40:07 +0100
From: "Metz, E.T." <E.T.Metz@kpn.com>
Subject: RE: LSP setup time and delay
To: "'Shahram Davari'" <Shahram_Davari@pmc-sierra.com>,
        "'Tim.Cook@go.ecitele.com'" <Tim.Cook@go.ecitele.com>
Cc: "'Vishal M'" <vishal_study@yahoo.com>, mpls@UU.NET
Message-id: <59063B5B4D98D311BC0D0001FA7E45220316A3F1@l04.research.kpn.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain;	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

In addition: not *all* regular traffic is labeled *always*. This depends on
the application, and how the FECs are defined.

cheers,
	Eduard

> -----Original Message-----
> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
> Sent: vrijdag 18 augustus 2000 16:29
> To: 'Tim.Cook@go.ecitele.com'; Shahram Davari
> Cc: 'Vishal M'; mpls@UU.NET
> Subject: RE: LSP setup time and delay
> 
> 
> Tim,
> 
> No. Control packets are L3 forwarded. Also in data driven method, the
> packets are initially L3 forwarded and then switched to L2 
> forwarding when
> LSP is setup.
> 
> -Shahram
> 
> >-----Original Message-----
> >From: Tim.Cook@go.ecitele.com [mailto:Tim.Cook@go.ecitele.com]
> >Sent: Friday, August 18, 2000 10:49 AM
> >To: Shahram Davari
> >Cc: 'Vishal M'; mpls@UU.NET
> >Subject: RE: LSP setup time and delay
> >
> >
> >
> >
> >Does this mean that there is no L3 forwarding between two LSRs 
> >(all traffic
> >is labeled)?
> >
> >
> >
> >
> >Shahram Davari <Shahram_Davari@pmc-sierra.com> on 08/18/2000 
> >10:22:40 AM
> >                                                              
> >                                                              
> >                                                              
> > To:      "'Vishal M'" <vishal_study@yahoo.com>, mpls@UU.NET  
> >                                                              
> > cc:      (bcc: Tim Cook/Fort Lauderdale/ECI Telecom)         
> >                                                              
> >                                                              
> >                                                              
> > Subject: RE: LSP setup time and delay                        
> >                                                              
> >
> >
> >
> >
> >
> >
> >
> >
> >Vishal,
> >
> >What you are describing is called "data driven label 
> >assignment". This is
> >explained in framework document, and requires L3 forwarding 
> >until the LSP
> >is
> >setup. Due to its problems it has not been pursued further by MPLS WG
> >(however, some implementations exist). Control driven label 
> >assignment is
> >the one most of the people are working on.
> >
> >Regards,
> >-Shahram
> >
> >>-----Original Message-----
> >>From: Vishal M [mailto:vishal_study@yahoo.com]
> >>Sent: Friday, August 18, 2000 4:15 AM
> >>To: mpls@UU.NET
> >>Subject: LSP setup time and delay
> >>
> >>
> >>
> >>Hello,
> >>
> >>Suppose an IP packet is to sent over a MPLS network.
> >>As I understand the protocol, different components at
> >>the ingres LSR (also called LER) interact in the
> >>following way:
> >>
> >>1. MPLS Signaling Plane (CR-LDP/RSVP) queries the
> >>Routing Plane (IGP Extensions) to get the Explicit
> >>Path to reach the destination (assuming nothing
> >>in the tables initially).
> >>
> >>2. Signaling Plane uses RSVP or CR-LDP to reserve
> >>resources along the explicit path. Label mapping
> >>is performed at the intermediatory LSRs.
> >>
> >>3. After the path is set up i.e. LSP is established
> >>from the source to the destination, the incoming
> >>packet is forwarded and the rest of the packets follow
> >>the same path.
> >>
> >>Questions:
> >>
> >>Q1. In the process mentioned above (and if it is the
> >>right sequence), there might be a noticable delay
> >>between the time the packet arrived at LER and
> >>the time when the LSP is established and actual
> >>traffic starts flowing.
> >>
> >>This could lead to two problems:
> >>a. Delay at the LER. If we are dealing with mission
> >>critical applications, is this delay acceptable ?
> >>b. Memory crunch at the LER (considering OC-192 i/f).
> >>
> >>We could have pre-configured tunnels or LSPs to
> >>circumvent this problem. Are tunnels the way to go to
> >>resolve this ? Is there any other solution (assuming
> >>this is really a problem !) ?
> >>
> >>Q2. I'm not very sure of the Step #3. Is the first
> >>packet routed ?
> >>I mean, does the first packet go along with the
> >>Resource Resv request OR does it have to wait till the
> >>
> >>entire path is established ?
> >>
> >>I apologize if this is a very basic question, but
> >>I have trouble understanding this.
> >>
> >>Thanks,
> >>Vishal.
> >>
> >>
> >>
> >>
> >>__________________________________________________
> >>Do You Yahoo!?
> >>Send instant messages & get email alerts with Yahoo! Messenger.
> >>http://im.yahoo.com/
> >>
> >
> >
> >
> >
> 


From owner-mpls@UU.NET  Fri Aug 18 13:32:45 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03144
	for <mpls-archive@lists.ietf.org>; Fri, 18 Aug 2000 13:32:45 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcuo08509;
	Fri, 18 Aug 2000 17:32:44 GMT
Received: by mail-control.mail.uu.net 
	id QQjcuo20853
	for mpls-outgoing; Fri, 18 Aug 2000 17:32:22 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjcuo20839
	for <mpls@mail-control.mail.uu.net>; Fri, 18 Aug 2000 17:32:12 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjcuo06937
	for <mpls@uu.net>; Fri, 18 Aug 2000 13:32:08 -0400 (EDT)
Received: from smtpproxy1.mitre.org by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mbunix.mitre.org [129.83.20.100])
	id QQjcuo07679
	for <mpls@uu.net>; Fri, 18 Aug 2000 17:31:53 GMT
Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58])
	by smtpproxy1.mitre.org (8.9.3/8.9.3) with ESMTP id NAA24920
	for <mpls@uu.net>; Fri, 18 Aug 2000 13:31:52 -0400 (EDT)
Received: from MAILHUB2 (mailhub2.mitre.org [129.83.221.18])
	by smtpsrv1.mitre.org (8.9.3/8.9.3) with ESMTP id NAA08013
	for <mpls@uu.net>; Fri, 18 Aug 2000 13:29:25 -0400 (EDT)
Received: from m27772-pc.mitre.org (128.29.145.23) by mailhub2.mitre.org with SMTP
        id 4238300; Fri, 18 Aug 2000 13:31:49 EST
Message-ID: <399D75CB.7934B07F@mitre.org>
Date: Fri, 18 Aug 2000 13:43:40 -0400
From: Jeff Bush <jbush@mitre.org>
Organization: The MITRE Corporation
X-Mailer: Mozilla 4.73 [en]C-20000509M  (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: general MPLS questions
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hello:

My colleagues and I have some questions on on MPLS that are more of a
generic nature - as we are getting more knowledgeable about the
subject.  Your comments would be most appreciated. We apologize if some
topics have already been discussed on the list.

1.  Is there any issue with MTU conflicts as shims are added to the
original packet?

2.  Is it true (as some ISP folks have stated) that MPLS VPNs are not
scalable?

3.  Is MPLS currently providing traffic engineering only - using TOS
bits.  Are there deployments out there that provide QoS (voice over
data) using MPLS (without ATM, say)?

4. Does LDP create a huge state machine and potentially clog the network
(especially if the one or more LSPs are disturbed or disconnected)? 

5. If there are more than one LDP used in a hybrid environment, could
there be conflicts regarding LSPs? 

6. Does variable length header processing cause high latency?

7. How does MPLS gets deployed in the "last mile" - between the egress
router and the end-system - say on the LAN?

8. What are the overhead issues of MPLS with respect to path computation
as against node processing?

9. Say you have a path (LSP) established between four LSRs, A, B, C, and
D.  Then when packets are being transmitted on this LSP, C fails.  What
happens then?  We would be trying to establish another LSP by sending
LDP packets to D from B.  Or should this be A which established the LSP
first?  And, what happens to the packets in transit?

10. Is it true that MPLS is good for the network backbone only?



From owner-mpls@UU.NET  Fri Aug 18 13:38:01 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03291
	for <mpls-archive@lists.ietf.org>; Fri, 18 Aug 2000 13:38:01 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcuo13005;
	Fri, 18 Aug 2000 17:38:01 GMT
Received: by mail-control.mail.uu.net 
	id QQjcuo21161
	for mpls-outgoing; Fri, 18 Aug 2000 17:37:32 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjcuo21144
	for <mpls@mail-control.mail.uu.net>; Fri, 18 Aug 2000 17:37:24 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjcuo27986;
	Fri, 18 Aug 2000 13:36:56 -0400 (EDT)
Received: from mx1out.umbc.edu by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mx1out.umbc.edu [130.85.253.51])
	id QQjcuo11784;
	Fri, 18 Aug 2000 17:36:26 GMT
Received: from gl.umbc.edu (vijay@irix1.gl.umbc.edu [130.85.60.8])
	by mx1out.umbc.edu (8.9.3/8.9.3) with ESMTP id NAA04004;
	Fri, 18 Aug 2000 13:36:24 -0400 (EDT)
Received: from localhost (vijay@localhost)
	by gl.umbc.edu (8.9.0/8.9.0) with ESMTP id NAA3586386;
	Fri, 18 Aug 2000 13:36:22 -0400 (EDT)
X-Authentication-Warning: irix1.gl.umbc.edu: vijay owned process doing -bs
Date: Fri, 18 Aug 2000 13:36:22 -0400
From: Vijay Gill <vijay@umbc.edu>
X-Sender: vijay@irix1.gl.umbc.edu
To: Paul Langille <langille@CrescentNetworks.com>
cc: Jim Boyle <jboyle@level3.net>, te-wg@UU.NET, mpls@UU.NET
Subject: Re: consensus to make draft-kompella-mpls-te-mib-00.txt a TEWGitem?
In-Reply-To: <399D47E2.FCBEDC@crescentnetworks.com>
Message-ID: <Pine.SGI.4.21L.01.0008181327580.3659402-100000@irix1.gl.umbc.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

On Fri, 18 Aug 2000, Paul Langille wrote:

> > a) be accepted as a TE WG item at this time?
> > b) not be accepted as a TE WG item at this time?

>     I vote for "b". I don't think this MIB is quite ready for 'prime time'.
> There are a few issues that (in my humble opinion) need to be addressed.

Define prime time. We have networks to run. Now. Networks cannot be put on
hold till prime time.

>     1) I don't understand why the 'interesting' objects in Kireeti's
> MIB cannot be folded into the TE-MIB. A lot of the objects are
> duplicates. I would like to implement just one MIB. What are the pros
> and cons of merging these two drafts? (I feel you need a pretty strong
> argument to justify the duplication.)

1 - There is a set of features that we (the operators) need.

2 - There is a set of features that some people who mostly tend to be
    vendors think we (the operators) need.

3 - There is a set of features that some people who mostly tend to be
    vendors think we (the operators) might need.

#3 is a superset of #2 and #2 is a superset of #1.

Do not give us features you think we need, rather, give us features we
need. And this way, we will be all one big happy family.

The general trend in the IETF has been towards feature bloat. Bigger,
better, more.  And as an end result, we've ended up overkill, overdesign,
and endless bickerings.


>     2) What is the real 'purpose' of Kireeti's MIB. I would like to
> see a model or some other draft that gives a better description of the
> objects in the MIB


The real purpose of the MIB is to allow some set of operators using TE to
run their networks properly and hopefully, make some money while they're
at it.

> (i.e. it needs reference clauses on many of the objects). I think a
> lot of the objects in the MIB need clearer definition. Most MIBs tend
> to be a fallout of an existing draft. (For example the TE-MIB is based
> on CR-LDP and RSVP Tunnels.) Defining functionality via a MIB is
> typically a difficult process. Diffserv ran into this problem when
> they started the Diffserv-MIB. To clearly understand the specific
> objects Diffserv needed the model draft. (I am not saying that we need

As yes, Diffserv. Perhaps not the best example to bring up here.

/vijay




From owner-mpls@UU.NET  Fri Aug 18 13:43:04 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03432
	for <mpls-archive@lists.ietf.org>; Fri, 18 Aug 2000 13:43:04 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcuo17493;
	Fri, 18 Aug 2000 17:43:03 GMT
Received: by mail-control.mail.uu.net 
	id QQjcuo21583
	for mpls-outgoing; Fri, 18 Aug 2000 17:42:30 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjcuo21574
	for <mpls@mail-control.mail.uu.net>; Fri, 18 Aug 2000 17:42:29 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjcuo08748;
	Fri, 18 Aug 2000 13:42:19 -0400 (EDT)
Received: from mx2out.umbc.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mx2out.umbc.edu [130.85.253.52])
	id QQjcuo09335;
	Fri, 18 Aug 2000 17:42:19 GMT
Received: from gl.umbc.edu (vijay@irix1.gl.umbc.edu [130.85.60.8])
	by mx2out.umbc.edu (8.9.3/8.9.3) with ESMTP id NAA12514;
	Fri, 18 Aug 2000 13:42:17 -0400 (EDT)
Received: from localhost (vijay@localhost)
	by gl.umbc.edu (8.9.0/8.9.0) with ESMTP id NAA3511703;
	Fri, 18 Aug 2000 13:42:17 -0400 (EDT)
X-Authentication-Warning: irix1.gl.umbc.edu: vijay owned process doing -bs
Date: Fri, 18 Aug 2000 13:42:16 -0400
From: Vijay Gill <vijay@umbc.edu>
X-Sender: vijay@irix1.gl.umbc.edu
To: "Thomas D. Nadeau" <tnadeau@cisco.com>
cc: Randy Bush <randy@psg.com>, te-wg@UU.NET, mpls@UU.NET
Subject: Re: consensus to make draft-kompella-mpls-te-mib-00.txt a  TEWGitem?
In-Reply-To: <4.3.2.7.2.20000818103207.04dad230@bucket.cisco.com>
Message-ID: <Pine.SGI.4.21L.01.0008181338050.3659402-100000@irix1.gl.umbc.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

On Fri, 18 Aug 2000, Thomas D. Nadeau wrote:

> 
>          2) Because it is a so-called minimalist design, it only incorporates
>                  the minimalist design of one particular implementation.
>                  This is because it is essentially a proprietary MIB.

The design basis of the MIB was based upon network operators needs.

1) What we want

2) What you think we want

There are very subtle differences between those two statements.


>          3) When does one stop using the so-called minimal one and start
>                  using the MPLS-TE-MIB? When one wants to inter-operate? If
>                  you are really concerned with operational functionality,
>                  then this reason alone would tell you to NOT have 2 MIBs.

So we propose using the kireeti MIB as the basis. The kireeti MIB is based
in reality of operational need, which is a fine place to start from, I
assure you.

/vijay




From owner-mpls@UU.NET  Fri Aug 18 14:17:49 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04044
	for <mpls-archive@lists.ietf.org>; Fri, 18 Aug 2000 14:17:49 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcur13394;
	Fri, 18 Aug 2000 18:17:47 GMT
Received: by mail-control.mail.uu.net 
	id QQjcur06776
	for mpls-outgoing; Fri, 18 Aug 2000 18:17:11 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjcur06760
	for <mpls@mail-control.mail.uu.net>; Fri, 18 Aug 2000 18:16:57 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjcur15516
	for <mpls@uu.net>; Fri, 18 Aug 2000 14:16:52 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11])
	id QQjcur12246
	for <mpls@uu.net>; Fri, 18 Aug 2000 18:16:21 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id LAA14475
	for <mpls@uu.net>; Fri, 18 Aug 2000 11:16:38 -0700 (PDT)
Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id OAA10176 for mpls@uu.net; Fri, 18 Aug 2000 14:16:19 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjcuq06070
	for <mpls@mail-control.mail.uu.net>; Fri, 18 Aug 2000 18:11:30 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjcuq04070
	for <mpls@UU.NET>; Fri, 18 Aug 2000 14:11:07 -0400 (EDT)
Received: from web9203.mail.yahoo.com by wodc7mr2.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: [216.136.129.36])
	id QQjcuq08417
	for <mpls@UU.NET>; Fri, 18 Aug 2000 18:11:06 GMT
Message-ID: <20000818181104.10864.qmail@web9203.mail.yahoo.com>
Received: from [171.71.221.161] by web9203.mail.yahoo.com; Fri, 18 Aug 2000 11:11:04 PDT
Date: Fri, 18 Aug 2000 11:11:04 -0700 (PDT)
From: Vishal M <vishal_study@yahoo.com>
Subject: RE: LSP setup time and delay
To: Shahram Davari <Shahram_Davari@pmc-sierra.com>,
        "'Tim.Cook@go.ecitele.com'" <Tim.Cook@go.ecitele.com>
Cc: "'Vishal M'" <vishal_study@yahoo.com>, mpls@UU.NET
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk


Hi Shahram,

Thanks for reply. Some more doubts:

1. If the LSP setup is not data-driven, how
   many LSPs are established on the ingress LSR (LER)
   when LER initializes ?

2. Wouldn't this lead to a lot of manual intervention
   in pre-establishing these LSPs ? 

3. What happens if LER gets an IP packet for which
   there is no pre-established LSP (and assuming
   that the IP packet belongs to a mission-critical
   application) ? 
   How do we ensure QoS in this case ? 
   
Thanks,
Vishal.

--- Shahram Davari <Shahram_Davari@pmc-sierra.com>
wrote:
> Tim,
> 
> No. Control packets are L3 forwarded. Also in data
> driven method, the
> packets are initially L3 forwarded and then switched
> to L2 forwarding when
> LSP is setup.
> 
> -Shahram
> 
> >-----Original Message-----
> >From: Tim.Cook@go.ecitele.com
> [mailto:Tim.Cook@go.ecitele.com]
> >Sent: Friday, August 18, 2000 10:49 AM
> >To: Shahram Davari
> >Cc: 'Vishal M'; mpls@UU.NET
> >Subject: RE: LSP setup time and delay
> >
> >
> >
> >
> >Does this mean that there is no L3 forwarding
> between two LSRs 
> >(all traffic
> >is labeled)?
> >
> >
> >
> >
> >Shahram Davari <Shahram_Davari@pmc-sierra.com> on
> 08/18/2000 
> >10:22:40 AM
> >                                                   
>           
> >                                                   
>           
> >                                                   
>           
> > To:      "'Vishal M'" <vishal_study@yahoo.com>,
> mpls@UU.NET  
> >                                                   
>           
> > cc:      (bcc: Tim Cook/Fort Lauderdale/ECI
> Telecom)         
> >                                                   
>           
> >                                                   
>           
> >                                                   
>           
> > Subject: RE: LSP setup time and delay             
>           
> >                                                   
>           
> >
> >
> >
> >
> >
> >
> >
> >
> >Vishal,
> >
> >What you are describing is called "data driven
> label 
> >assignment". This is
> >explained in framework document, and requires L3
> forwarding 
> >until the LSP
> >is
> >setup. Due to its problems it has not been pursued
> further by MPLS WG
> >(however, some implementations exist). Control
> driven label 
> >assignment is
> >the one most of the people are working on.
> >
> >Regards,
> >-Shahram
> >
> >>-----Original Message-----
> >>From: Vishal M [mailto:vishal_study@yahoo.com]
> >>Sent: Friday, August 18, 2000 4:15 AM
> >>To: mpls@UU.NET
> >>Subject: LSP setup time and delay
> >>
> >>
> >>
> >>Hello,
> >>
> >>Suppose an IP packet is to sent over a MPLS
> network.
> >>As I understand the protocol, different components
> at
> >>the ingres LSR (also called LER) interact in the
> >>following way:
> >>
> >>1. MPLS Signaling Plane (CR-LDP/RSVP) queries the
> >>Routing Plane (IGP Extensions) to get the Explicit
> >>Path to reach the destination (assuming nothing
> >>in the tables initially).
> >>
> >>2. Signaling Plane uses RSVP or CR-LDP to reserve
> >>resources along the explicit path. Label mapping
> >>is performed at the intermediatory LSRs.
> >>
> >>3. After the path is set up i.e. LSP is
> established
> >>from the source to the destination, the incoming
> >>packet is forwarded and the rest of the packets
> follow
> >>the same path.
> >>
> >>Questions:
> >>
> >>Q1. In the process mentioned above (and if it is
> the
> >>right sequence), there might be a noticable delay
> >>between the time the packet arrived at LER and
> >>the time when the LSP is established and actual
> >>traffic starts flowing.
> >>
> >>This could lead to two problems:
> >>a. Delay at the LER. If we are dealing with
> mission
> >>critical applications, is this delay acceptable ?
> >>b. Memory crunch at the LER (considering OC-192
> i/f).
> >>
> >>We could have pre-configured tunnels or LSPs to
> >>circumvent this problem. Are tunnels the way to go
> to
> >>resolve this ? Is there any other solution
> (assuming
> >>this is really a problem !) ?
> >>
> >>Q2. I'm not very sure of the Step #3. Is the first
> >>packet routed ?
> >>I mean, does the first packet go along with the
> >>Resource Resv request OR does it have to wait till
> the
> >>
> >>entire path is established ?
> >>
> >>I apologize if this is a very basic question, but
> >>I have trouble understanding this.
> >>
> >>Thanks,
> >>Vishal.
> >>
> >>
> >>


__________________________________________________
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/



From owner-mpls@UU.NET  Fri Aug 18 14:20:19 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04121
	for <mpls-archive@lists.ietf.org>; Fri, 18 Aug 2000 14:20:19 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcur15675;
	Fri, 18 Aug 2000 18:20:17 GMT
Received: by mail-control.mail.uu.net 
	id QQjcur07000
	for mpls-outgoing; Fri, 18 Aug 2000 18:19:43 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjcur06984
	for <mpls@mail-control.mail.uu.net>; Fri, 18 Aug 2000 18:19:32 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjcur16064
	for <mpls@uu.net>; Fri, 18 Aug 2000 14:19:17 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjcur28668
	for <mpls@uu.net>; Fri, 18 Aug 2000 18:19:17 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA28848
	for mpls@uu.net; Fri, 18 Aug 2000 14:19:16 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjcur06903
	for <mpls@mail-control.mail.uu.net>; Fri, 18 Aug 2000 18:18:39 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjcur05276;
	Fri, 18 Aug 2000 14:17:19 -0400 (EDT)
Received: from funnel.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQjcur24712;
	Fri, 18 Aug 2000 18:17:03 GMT
Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.131.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA16619; Fri, 18 Aug 2000 14:17:03 -0400 (EDT)
Received: from tnadeau-pc02.cisco.com ([161.44.204.102])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AAJ18417;
	Fri, 18 Aug 2000 14:17:00 -0400 (EDT)
Message-Id: <4.3.2.7.2.20000818135125.04dc7920@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 18 Aug 2000 14:06:38 -0400
To: Vijay Gill <vijay@umbc.edu>
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Subject: Re: consensus to make draft-kompella-mpls-te-mib-00.txt a 
  TEWGitem?
Cc: Randy Bush <randy@psg.com>, te-wg@UU.NET, mpls@UU.NET
In-Reply-To: <Pine.SGI.4.21L.01.0008181338050.3659402-100000@irix1.gl.um
 bc.edu>
References: <4.3.2.7.2.20000818103207.04dad230@bucket.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk


>The design basis of the MIB was based upon network operators needs.
>
>1) What we want
>
>2) What you think we want
>
>There are very subtle differences between those two statements.

         Yes, there is a subtle difference and it is really who "we"
is defined as. To you "we" is defined as the small set of operators
who are currently are using Juniper switches, and of course, those folks
love Kireeti's MIB. It is not however, the model necessarily used
for managing the other LSRs that are out there. There are many others
who use the MPLS-TE-MIB and MPLS-LSR-MIBs for managing their switches/routers.
I have said it once, and I will say it again, if you want to use Juniper's
proprietary MIB to manage your LSRs, then go ahead. If you want to use a
standard MIB to manage the rest of the LSRs in the world, then
use those MIBs which are being defined by the MPLS WG. If the standard
MIB does not suit your needs, then by all means, join in the discussion
of defining it.

> >          3) When does one stop using the so-called minimal one and start
> >                  using the MPLS-TE-MIB? When one wants to inter-operate? If
> >                  you are really concerned with operational functionality,
> >                  then this reason alone would tell you to NOT have 2 MIBs.
>
>So we propose using the kireeti MIB as the basis. The kireeti MIB is based
>in reality of operational need, which is a fine place to start from, I
>assure you.

         What I will assure you of is that the Kireeti-MIB is based on the
reality of the Juniper implementation. This is not the reality of what the
rest of the world uses. Furthermore, it does not necessarily contain the
operational reality of MPLS features that other LSR vendors are currently
deploying due to its incomplete nature.

         --Tom





From owner-mpls@UU.NET  Fri Aug 18 14:32:24 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04459
	for <mpls-archive@lists.ietf.org>; Fri, 18 Aug 2000 14:32:23 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcus24966;
	Fri, 18 Aug 2000 18:32:22 GMT
Received: by mail-control.mail.uu.net 
	id QQjcus08181
	for mpls-outgoing; Fri, 18 Aug 2000 18:32:04 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjcus08161
	for <mpls@mail-control.mail.uu.net>; Fri, 18 Aug 2000 18:31:48 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjcus07855
	for <mpls@uu.net>; Fri, 18 Aug 2000 14:31:00 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88])
	id QQjcus19241
	for <mpls@uu.net>; Fri, 18 Aug 2000 18:31:00 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id LAA08707
	for <mpls@uu.net>; Fri, 18 Aug 2000 11:31:17 -0700 (PDT)
Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id OAA10220 for mpls@uu.net; Fri, 18 Aug 2000 14:30:58 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjcuq06070
	for <mpls@mail-control.mail.uu.net>; Fri, 18 Aug 2000 18:11:30 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjcuq04070
	for <mpls@UU.NET>; Fri, 18 Aug 2000 14:11:07 -0400 (EDT)
Received: from web9203.mail.yahoo.com by wodc7mr2.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: [216.136.129.36])
	id QQjcuq08417
	for <mpls@UU.NET>; Fri, 18 Aug 2000 18:11:06 GMT
Message-ID: <20000818181104.10864.qmail@web9203.mail.yahoo.com>
Received: from [171.71.221.161] by web9203.mail.yahoo.com; Fri, 18 Aug 2000 11:11:04 PDT
Date: Fri, 18 Aug 2000 11:11:04 -0700 (PDT)
From: Vishal M <vishal_study@yahoo.com>
Subject: RE: LSP setup time and delay
To: Shahram Davari <Shahram_Davari@pmc-sierra.com>,
        "'Tim.Cook@go.ecitele.com'" <Tim.Cook@go.ecitele.com>
Cc: "'Vishal M'" <vishal_study@yahoo.com>, mpls@UU.NET
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk


Hi Shahram,

Thanks for reply. Some more doubts:

1. If the LSP setup is not data-driven, how
   many LSPs are established on the ingress LSR (LER)
   when LER initializes ?

2. Wouldn't this lead to a lot of manual intervention
   in pre-establishing these LSPs ? 

3. What happens if LER gets an IP packet for which
   there is no pre-established LSP (and assuming
   that the IP packet belongs to a mission-critical
   application) ? 
   How do we ensure QoS in this case ? 
   
Thanks,
Vishal.

--- Shahram Davari <Shahram_Davari@pmc-sierra.com>
wrote:
> Tim,
> 
> No. Control packets are L3 forwarded. Also in data
> driven method, the
> packets are initially L3 forwarded and then switched
> to L2 forwarding when
> LSP is setup.
> 
> -Shahram
> 
> >-----Original Message-----
> >From: Tim.Cook@go.ecitele.com
> [mailto:Tim.Cook@go.ecitele.com]
> >Sent: Friday, August 18, 2000 10:49 AM
> >To: Shahram Davari
> >Cc: 'Vishal M'; mpls@UU.NET
> >Subject: RE: LSP setup time and delay
> >
> >
> >
> >
> >Does this mean that there is no L3 forwarding
> between two LSRs 
> >(all traffic
> >is labeled)?
> >
> >
> >
> >
> >Shahram Davari <Shahram_Davari@pmc-sierra.com> on
> 08/18/2000 
> >10:22:40 AM
> >                                                   
>           
> >                                                   
>           
> >                                                   
>           
> > To:      "'Vishal M'" <vishal_study@yahoo.com>,
> mpls@UU.NET  
> >                                                   
>           
> > cc:      (bcc: Tim Cook/Fort Lauderdale/ECI
> Telecom)         
> >                                                   
>           
> >                                                   
>           
> >                                                   
>           
> > Subject: RE: LSP setup time and delay             
>           
> >                                                   
>           
> >
> >
> >
> >
> >
> >
> >
> >
> >Vishal,
> >
> >What you are describing is called "data driven
> label 
> >assignment". This is
> >explained in framework document, and requires L3
> forwarding 
> >until the LSP
> >is
> >setup. Due to its problems it has not been pursued
> further by MPLS WG
> >(however, some implementations exist). Control
> driven label 
> >assignment is
> >the one most of the people are working on.
> >
> >Regards,
> >-Shahram
> >
> >>-----Original Message-----
> >>From: Vishal M [mailto:vishal_study@yahoo.com]
> >>Sent: Friday, August 18, 2000 4:15 AM
> >>To: mpls@UU.NET
> >>Subject: LSP setup time and delay
> >>
> >>
> >>
> >>Hello,
> >>
> >>Suppose an IP packet is to sent over a MPLS
> network.
> >>As I understand the protocol, different components
> at
> >>the ingres LSR (also called LER) interact in the
> >>following way:
> >>
> >>1. MPLS Signaling Plane (CR-LDP/RSVP) queries the
> >>Routing Plane (IGP Extensions) to get the Explicit
> >>Path to reach the destination (assuming nothing
> >>in the tables initially).
> >>
> >>2. Signaling Plane uses RSVP or CR-LDP to reserve
> >>resources along the explicit path. Label mapping
> >>is performed at the intermediatory LSRs.
> >>
> >>3. After the path is set up i.e. LSP is
> established
> >>from the source to the destination, the incoming
> >>packet is forwarded and the rest of the packets
> follow
> >>the same path.
> >>
> >>Questions:
> >>
> >>Q1. In the process mentioned above (and if it is
> the
> >>right sequence), there might be a noticable delay
> >>between the time the packet arrived at LER and
> >>the time when the LSP is established and actual
> >>traffic starts flowing.
> >>
> >>This could lead to two problems:
> >>a. Delay at the LER. If we are dealing with
> mission
> >>critical applications, is this delay acceptable ?
> >>b. Memory crunch at the LER (considering OC-192
> i/f).
> >>
> >>We could have pre-configured tunnels or LSPs to
> >>circumvent this problem. Are tunnels the way to go
> to
> >>resolve this ? Is there any other solution
> (assuming
> >>this is really a problem !) ?
> >>
> >>Q2. I'm not very sure of the Step #3. Is the first
> >>packet routed ?
> >>I mean, does the first packet go along with the
> >>Resource Resv request OR does it have to wait till
> the
> >>
> >>entire path is established ?
> >>
> >>I apologize if this is a very basic question, but
> >>I have trouble understanding this.
> >>
> >>Thanks,
> >>Vishal.
> >>
> >>
> >>


__________________________________________________
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/



From owner-mpls@UU.NET  Fri Aug 18 14:47:36 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04717
	for <mpls-archive@lists.ietf.org>; Fri, 18 Aug 2000 14:47:36 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcut17867;
	Fri, 18 Aug 2000 18:47:34 GMT
Received: by mail-control.mail.uu.net 
	id QQjcut09636
	for mpls-outgoing; Fri, 18 Aug 2000 18:47:03 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjcut09630
	for <mpls@mail-control.mail.uu.net>; Fri, 18 Aug 2000 18:46:58 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjcut21181
	for <mpls@uu.net>; Fri, 18 Aug 2000 14:46:40 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjcut16218
	for <mpls@uu.net>; Fri, 18 Aug 2000 18:46:40 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA04534
	for mpls@uu.net; Fri, 18 Aug 2000 14:46:39 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjcut09582
	for <mpls@mail-control.mail.uu.net>; Fri, 18 Aug 2000 18:46:21 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjcut21087
	for <mpls@UU.NET>; Fri, 18 Aug 2000 14:46:15 -0400 (EDT)
Received: from procyon.pmc-sierra.bc.ca by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1])
	id QQjcut04772
	for <mpls@UU.NET>; Fri, 18 Aug 2000 18:46:14 GMT
Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183])
	by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id LAA03593;
	Fri, 18 Aug 2000 11:44:40 -0700 (PDT)
Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21)
	id <QPVGRCB3>; Fri, 18 Aug 2000 11:47:38 -0700
Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B40739@nt-exchange-bby.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'Vishal M'" <vishal_study@yahoo.com>,
        Shahram Davari
	 <Shahram_Davari@pmc-sierra.com>,
        "'Tim.Cook@go.ecitele.com'"
	 <Tim.Cook@go.ecitele.com>
Cc: mpls@UU.NET
Subject: RE: LSP setup time and delay
Date: Fri, 18 Aug 2000 11:47:32 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Vishal,

>-----Original Message-----
>From: Vishal M [mailto:vishal_study@yahoo.com]
>Sent: Friday, August 18, 2000 2:11 PM
>To: Shahram Davari; 'Tim.Cook@go.ecitele.com'
>Cc: 'Vishal M'; mpls@UU.NET
>Subject: RE: LSP setup time and delay
>
>
>
>Hi Shahram,
>
>Thanks for reply. Some more doubts:
>
>1. If the LSP setup is not data-driven, how
>   many LSPs are established on the ingress LSR (LER)
>   when LER initializes ?

It depends on the network policy and requests that are signaled. In many
cases (such as in a Diffserv network) you probably need at least one LSP per
egress LSR.

>
>2. Wouldn't this lead to a lot of manual intervention
>   in pre-establishing these LSPs ?

Not really. You just need to specify the ingress LSR, the egress LSR, the
FEC and the required QoS (such as BW) for the required LSP, and the TE
software will find and establish the path for you. 
 
>
>3. What happens if LER gets an IP packet for which
>   there is no pre-established LSP (and assuming
>   that the IP packet belongs to a mission-critical
>   application) ? 
>   How do we ensure QoS in this case ? 

If after the packet classification it is found that the packet does not map
to any LSP, then this is up to the network policy, it may send it as L3
packet or may drop it. It is up to the network provider to assign all
required FECs to proper LSPs at the edge.

The best method is for the mission-critical application to signal its
required QoS. The network will use this information to establish the
required LSP. If such an LSP can't be found then the request will be
rejected. In other words admission control is the best method to make sure
that the mission-critical packets receive their required QoS.

Regards,
-Shahram 

>   
>Thanks,
>Vishal.
>
>--- Shahram Davari <Shahram_Davari@pmc-sierra.com>
>wrote:
>> Tim,
>> 
>> No. Control packets are L3 forwarded. Also in data
>> driven method, the
>> packets are initially L3 forwarded and then switched
>> to L2 forwarding when
>> LSP is setup.
>> 
>> -Shahram
>> 
>> >-----Original Message-----
>> >From: Tim.Cook@go.ecitele.com
>> [mailto:Tim.Cook@go.ecitele.com]
>> >Sent: Friday, August 18, 2000 10:49 AM
>> >To: Shahram Davari
>> >Cc: 'Vishal M'; mpls@UU.NET
>> >Subject: RE: LSP setup time and delay
>> >
>> >
>> >
>> >
>> >Does this mean that there is no L3 forwarding
>> between two LSRs 
>> >(all traffic
>> >is labeled)?
>> >
>> >
>> >
>> >
>> >Shahram Davari <Shahram_Davari@pmc-sierra.com> on
>> 08/18/2000 
>> >10:22:40 AM
>> >                                                   
>>           
>> >                                                   
>>           
>> >                                                   
>>           
>> > To:      "'Vishal M'" <vishal_study@yahoo.com>,
>> mpls@UU.NET  
>> >                                                   
>>           
>> > cc:      (bcc: Tim Cook/Fort Lauderdale/ECI
>> Telecom)         
>> >                                                   
>>           
>> >                                                   
>>           
>> >                                                   
>>           
>> > Subject: RE: LSP setup time and delay             
>>           
>> >                                                   
>>           
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >Vishal,
>> >
>> >What you are describing is called "data driven
>> label 
>> >assignment". This is
>> >explained in framework document, and requires L3
>> forwarding 
>> >until the LSP
>> >is
>> >setup. Due to its problems it has not been pursued
>> further by MPLS WG
>> >(however, some implementations exist). Control
>> driven label 
>> >assignment is
>> >the one most of the people are working on.
>> >
>> >Regards,
>> >-Shahram
>> >
>> >>-----Original Message-----
>> >>From: Vishal M [mailto:vishal_study@yahoo.com]
>> >>Sent: Friday, August 18, 2000 4:15 AM
>> >>To: mpls@UU.NET
>> >>Subject: LSP setup time and delay
>> >>
>> >>
>> >>
>> >>Hello,
>> >>
>> >>Suppose an IP packet is to sent over a MPLS
>> network.
>> >>As I understand the protocol, different components
>> at
>> >>the ingres LSR (also called LER) interact in the
>> >>following way:
>> >>
>> >>1. MPLS Signaling Plane (CR-LDP/RSVP) queries the
>> >>Routing Plane (IGP Extensions) to get the Explicit
>> >>Path to reach the destination (assuming nothing
>> >>in the tables initially).
>> >>
>> >>2. Signaling Plane uses RSVP or CR-LDP to reserve
>> >>resources along the explicit path. Label mapping
>> >>is performed at the intermediatory LSRs.
>> >>
>> >>3. After the path is set up i.e. LSP is
>> established
>> >>from the source to the destination, the incoming
>> >>packet is forwarded and the rest of the packets
>> follow
>> >>the same path.
>> >>
>> >>Questions:
>> >>
>> >>Q1. In the process mentioned above (and if it is
>> the
>> >>right sequence), there might be a noticable delay
>> >>between the time the packet arrived at LER and
>> >>the time when the LSP is established and actual
>> >>traffic starts flowing.
>> >>
>> >>This could lead to two problems:
>> >>a. Delay at the LER. If we are dealing with
>> mission
>> >>critical applications, is this delay acceptable ?
>> >>b. Memory crunch at the LER (considering OC-192
>> i/f).
>> >>
>> >>We could have pre-configured tunnels or LSPs to
>> >>circumvent this problem. Are tunnels the way to go
>> to
>> >>resolve this ? Is there any other solution
>> (assuming
>> >>this is really a problem !) ?
>> >>
>> >>Q2. I'm not very sure of the Step #3. Is the first
>> >>packet routed ?
>> >>I mean, does the first packet go along with the
>> >>Resource Resv request OR does it have to wait till
>> the
>> >>
>> >>entire path is established ?
>> >>
>> >>I apologize if this is a very basic question, but
>> >>I have trouble understanding this.
>> >>
>> >>Thanks,
>> >>Vishal.
>> >>
>> >>
>> >>
>
>
>__________________________________________________
>Do You Yahoo!?
>Send instant messages & get email alerts with Yahoo! Messenger.
>http://im.yahoo.com/
>



From owner-mpls@UU.NET  Fri Aug 18 14:49:27 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04750
	for <mpls-archive@lists.ietf.org>; Fri, 18 Aug 2000 14:49:26 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcut07368;
	Fri, 18 Aug 2000 18:49:21 GMT
Received: by mail-control.mail.uu.net 
	id QQjcut09782
	for mpls-outgoing; Fri, 18 Aug 2000 18:48:44 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjcut09751
	for <mpls@mail-control.mail.uu.net>; Fri, 18 Aug 2000 18:48:29 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjcut10690;
	Fri, 18 Aug 2000 14:48:17 -0400 (EDT)
Received: from NOD.RESTON.MCI.NET by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [166.60.6.38])
	id QQjcut06385;
	Fri, 18 Aug 2000 18:48:17 GMT
Received: from BONI ([166.60.14.48])
 by shoe.reston.mci.net (PMDF V5.2-32 #40475)
 with SMTP id <01JT4AXSD1VW9LVBET@shoe.reston.mci.net>; Fri,
 18 Aug 2000 14:48:16 EST
Date: Fri, 18 Aug 2000 14:47:53 -0500
From: Ron Bonica <rbonica@mci.net>
Subject: RE: consensus to make draft-kompella-mpls-te-mib-00.txt a TEWGitem?
In-reply-to: <4.3.2.7.2.20000818135125.04dc7920@bucket.cisco.com>
To: "Thomas D. Nadeau" <tnadeau@cisco.com>, Vijay Gill <vijay@umbc.edu>
Cc: Randy Bush <randy@psg.com>, te-wg@UU.NET, mpls@UU.NET
Message-id: <NBBBJGONOLIJDDNHNNBEIEJOEEAA.rbonica@mci.net>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7BIT

>          What I will assure you of is that the Kireeti-MIB is based on the
> reality of the Juniper implementation. This is not the reality of what the
> rest of the world uses. Furthermore, it does not necessarily contain the
> operational reality of MPLS features that other LSR vendors are currently
> deploying due to its incomplete nature.
>

Tom,

I am an operator with MPLS deployed in my network. For fault management
purposes, I need to know the following:

	-> which LSPs are broken
	-> which LSPs are sub-optimally routed
	-> which LSPs have reset

Using Kireeti's MIB, I can answer these questions by polling the following
items:

	-> mplsLspState
	-> mplsPathType
	-> mplsLspLastPathChange

This is pretty simple.

Couldn't this level of abstraction be applied to any MPLS implementation?

Please re-orient me if I am missing some very fundamental issue.

                           Ron




From owner-mpls@UU.NET  Fri Aug 18 15:04:29 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05141
	for <mpls-archive@lists.ietf.org>; Fri, 18 Aug 2000 15:04:28 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcuu10519;
	Fri, 18 Aug 2000 19:04:26 GMT
Received: by mail-control.mail.uu.net 
	id QQjcuu22668
	for mpls-outgoing; Fri, 18 Aug 2000 19:03:51 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjcuu22563
	for <mpls@mail-control.mail.uu.net>; Fri, 18 Aug 2000 19:03:47 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjcuu13788
	for <mpls@uu.net>; Fri, 18 Aug 2000 15:03:36 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjcuu09878
	for <mpls@uu.net>; Fri, 18 Aug 2000 19:03:35 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA08014
	for mpls@uu.net; Fri, 18 Aug 2000 15:03:34 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjcuu20449
	for <mpls@mail-control.mail.uu.net>; Fri, 18 Aug 2000 19:03:19 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjcuu24505;
	Fri, 18 Aug 2000 15:03:09 -0400 (EDT)
Received: from funnel.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQjcuu09621;
	Fri, 18 Aug 2000 19:03:09 GMT
Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.131.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA22824; Fri, 18 Aug 2000 15:03:08 -0400 (EDT)
Received: from tnadeau-pc02.cisco.com ([161.44.204.102])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AAJ18979;
	Fri, 18 Aug 2000 15:03:06 -0400 (EDT)
Message-Id: <4.3.2.7.2.20000818144930.054b7a50@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 18 Aug 2000 14:52:26 -0400
To: Ron Bonica <rbonica@MCI.NET>, Vijay Gill <vijay@umbc.edu>
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Subject: RE: consensus to make draft-kompella-mpls-te-mib-00.txt a
  TEWGitem?
Cc: Randy Bush <randy@psg.com>, te-wg@UU.NET, mpls@UU.NET
In-Reply-To: <NBBBJGONOLIJDDNHNNBEIEJOEEAA.rbonica@mci.net>
References: <4.3.2.7.2.20000818135125.04dc7920@bucket.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk


         Hi Ron,

>I am an operator with MPLS deployed in my network. For fault management
>purposes, I need to know the following:
>
>         -> which LSPs are broken
>         -> which LSPs are sub-optimally routed
>         -> which LSPs have reset
>
>Using Kireeti's MIB, I can answer these questions by polling the following
>items:
>
>         -> mplsLspState
>         -> mplsPathType
>         -> mplsLspLastPathChange
>
>This is pretty simple.
>
>Couldn't this level of abstraction be applied to any MPLS implementation?

         Yes. These were precisely some of the salient features
from Kireeti's MIB which we were trying to incorporate into
the MPLS-TE-MIB. However, we need Kireeti's and the TE WG's
help to make sure that these are really the things that people
need added. FYI, these attributes can be easily added to the
mplsTunnelTable in the MPLS-TE-MIB. It may also be favorable to
add traps for these state changes rather than polling.

>Please re-orient me if I am missing some very fundamental issue.

         Nope. Makes perfect sense to me.

         --Tom




From owner-mpls@UU.NET  Fri Aug 18 16:56:16 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07672
	for <mpls-archive@lists.ietf.org>; Fri, 18 Aug 2000 16:56:16 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcvb01336;
	Fri, 18 Aug 2000 20:56:07 GMT
Received: by mail-control.mail.uu.net 
	id QQjcvb14116
	for mpls-outgoing; Fri, 18 Aug 2000 20:55:29 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjcvb14104
	for <mpls@mail-control.mail.uu.net>; Fri, 18 Aug 2000 20:55:18 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjcvb16532;
	Fri, 18 Aug 2000 16:55:13 -0400 (EDT)
Received: from mx2out.umbc.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mx2out.umbc.edu [130.85.253.52])
	id QQjcvb00610;
	Fri, 18 Aug 2000 20:54:58 GMT
Received: from gl.umbc.edu (vijay@irix1.gl.umbc.edu [130.85.60.8])
	by mx2out.umbc.edu (8.9.3/8.9.3) with ESMTP id QAA16511;
	Fri, 18 Aug 2000 16:54:52 -0400 (EDT)
Received: from localhost (vijay@localhost)
	by gl.umbc.edu (8.9.0/8.9.0) with ESMTP id QAA3682982;
	Fri, 18 Aug 2000 16:54:51 -0400 (EDT)
X-Authentication-Warning: irix1.gl.umbc.edu: vijay owned process doing -bs
Date: Fri, 18 Aug 2000 16:54:51 -0400
From: Vijay Gill <vijay@umbc.edu>
X-Sender: vijay@irix1.gl.umbc.edu
To: Cheenu Srinivasan <csrinivasan@tachion.com>
cc: te-wg@UU.NET, mpls@UU.NET, "'Jim Boyle'" <jboyle@Level3.net>
Subject: RE: consensus to make draft-kompella-mpls-te-mib-00.txt a TEWG it
 em?
In-Reply-To: <A64EB7AC0201D411B864009027DC856C054D8B@TNNT3>
Message-ID: <Pine.SGI.4.21L.01.0008181645490.3659402-100000@irix1.gl.umbc.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

On Fri, 18 Aug 2000, Cheenu Srinivasan wrote:

> Kireeti's MIB doesn't address numerous issues that would be necessary
> in a standard TE MIB. It supports a very limited model of TE using
> MPLS (specific to Juniper's switches). And, to put it bluntly, its
> quite badly designed stylistically as well. Its not a good idea to
> forget to "keep things as simple as possible but no simpler" or we
> would end up with

Perhaps we are forgetting what problem we are trying to solve here? It
supports a very limited and yet very operationally focused model. By a
very strange coincidence it is what the operators seem to be asking for.
Let us not forget that in the end, the worlds most intricate model of a
MIB that is all things to all people, is not useful if it cannot be used
to solve existing problems now, as opposed to what vendors _think_ will be
existing problems a year from now.

As for the badly designed style, I cannot even begin to comment on
that.  Perhaps a look at the CLNS vs IP design philosophy might be worth a
revisit. 

> There already exists, and has existed for quite a while, a TE MIB in the
> mplswg. This MIB is generic and has evolved to incorporate the comments of
> the mplswg. Also, it has been deployed in several switches. And, there are
> very good operational and implementation reasons

Yet strangely enough, for almost all purposes which I would need to run a
network, the simple and spare kireeti MIB suffices. Just because I can
solve some obscure corner case using the generic MIB does not mean I want
to build a large annoying backend to support solving that corner case.  
Operational reality is that 90% of most MIBS are never used and I do not
want to hold up my network waiting till all parties are happy with a
solution.

/vijay




From owner-mpls@UU.NET  Fri Aug 18 17:15:15 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08608
	for <mpls-archive@lists.ietf.org>; Fri, 18 Aug 2000 17:15:15 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcvd01405;
	Fri, 18 Aug 2000 21:15:15 GMT
Received: by mail-control.mail.uu.net 
	id QQjcvc27891
	for mpls-outgoing; Fri, 18 Aug 2000 21:14:37 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjcvc27871
	for <mpls@mail-control.mail.uu.net>; Fri, 18 Aug 2000 21:14:19 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjcvc19575;
	Fri, 18 Aug 2000 17:14:16 -0400 (EDT)
Received: from mx2out.umbc.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mx2out.umbc.edu [130.85.253.52])
	id QQjcvc29544;
	Fri, 18 Aug 2000 21:14:16 GMT
Received: from gl.umbc.edu (vijay@irix1.gl.umbc.edu [130.85.60.8])
	by mx2out.umbc.edu (8.9.3/8.9.3) with ESMTP id RAA16767;
	Fri, 18 Aug 2000 17:14:15 -0400 (EDT)
Received: from localhost (vijay@localhost)
	by gl.umbc.edu (8.9.0/8.9.0) with ESMTP id RAA3509546;
	Fri, 18 Aug 2000 17:14:14 -0400 (EDT)
X-Authentication-Warning: irix1.gl.umbc.edu: vijay owned process doing -bs
Date: Fri, 18 Aug 2000 17:14:14 -0400
From: Vijay Gill <vijay@umbc.edu>
X-Sender: vijay@irix1.gl.umbc.edu
To: "Thomas D. Nadeau" <tnadeau@cisco.com>
cc: Randy Bush <randy@psg.com>, te-wg@UU.NET, mpls@UU.NET
Subject: Re: consensus to make draft-kompella-mpls-te-mib-00.txt a   TEWGitem?
In-Reply-To: <4.3.2.7.2.20000818135125.04dc7920@bucket.cisco.com>
Message-ID: <Pine.SGI.4.21L.01.0008181712300.3659402-100000@irix1.gl.umbc.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

On Fri, 18 Aug 2000, Thomas D. Nadeau wrote:

> reality of the Juniper implementation. This is not the reality of what the
> rest of the world uses. Furthermore, it does not necessarily contain the
> operational reality of MPLS features that other LSR vendors are currently
> deploying due to its incomplete nature.

Ah yes, I see the disconnect now.

I am coming from the reality of the operators world, who have to use these
things on a daily basis to keep a network up and running vs the reality of
those vendors who think they know better than we what we want.


/vijay




From owner-mpls@UU.NET  Fri Aug 18 17:21:26 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08739
	for <mpls-archive@lists.ietf.org>; Fri, 18 Aug 2000 17:21:26 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcvd13123;
	Fri, 18 Aug 2000 21:21:26 GMT
Received: by mail-control.mail.uu.net 
	id QQjcvd28842
	for mpls-outgoing; Fri, 18 Aug 2000 21:21:10 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjcvd28815
	for <mpls@mail-control.mail.uu.net>; Fri, 18 Aug 2000 21:21:07 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjcvd07371
	for <mpls@uu.net>; Fri, 18 Aug 2000 17:20:39 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjcvd25721
	for <mpls@uu.net>; Fri, 18 Aug 2000 21:20:39 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA27129
	for mpls@uu.net; Fri, 18 Aug 2000 17:20:38 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjcvd28690
	for <mpls@mail-control.mail.uu.net>; Fri, 18 Aug 2000 21:20:19 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjcvd20611;
	Fri, 18 Aug 2000 17:20:16 -0400 (EDT)
Received: from tnnt3.tachion.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [198.139.117.130])
	id QQjcvd10331;
	Fri, 18 Aug 2000 21:20:01 GMT
Received: by TNNT3 with Internet Mail Service (5.5.2650.21)
	id <RB4D1AKM>; Fri, 18 Aug 2000 17:23:42 -0400
Message-ID: <A64EB7AC0201D411B864009027DC856C054D8F@TNNT3>
From: Cheenu Srinivasan <csrinivasan@tachion.com>
To: "'Vijay Gill'" <vijay@umbc.edu>
Cc: te-wg@UU.NET, mpls@UU.NET
Subject: RE: consensus to make draft-kompella-mpls-te-mib-00.txt a TEWG it
	 em?
Date: Fri, 18 Aug 2000 17:23:36 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0095A.9582036A"
Sender: owner-mpls@UU.NET
Precedence: bulk

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_01C0095A.9582036A
Content-Type: text/plain;
	charset="iso-8859-1"

Vijay Gill wrote:
>
> On Fri, 18 Aug 2000, Cheenu Srinivasan wrote:
> 
> > Kireeti's MIB doesn't address numerous issues that would be 
> necessary
> > in a standard TE MIB. It supports a very limited model of TE using
> > MPLS (specific to Juniper's switches). And, to put it bluntly, its
> > quite badly designed stylistically as well. Its not a good idea to
> > forget to "keep things as simple as possible but no simpler" or we
> > would end up with
> 
> Perhaps we are forgetting what problem we are trying to solve here? It
> supports a very limited and yet very operationally focused model. By a
> very strange coincidence it is what the operators seem to be 
> asking for.
> Let us not forget that in the end, the worlds most intricate 
> model of a
> MIB that is all things to all people, is not useful if it 
> cannot be used
> to solve existing problems now, as opposed to what vendors 
> _think_ will be
> existing problems a year from now.

If all you are interested in is Juniper switches I understand your
viewpoint. However, the point of putting together a standard MIB
is to make it general enough to implement on other switches as well.

> As for the badly designed style, I cannot even begin to comment on
> that.  Perhaps a look at the CLNS vs IP design philosophy 
> might be worth a
> revisit. 

If simplicity (which in this context seems to be minimizing the number
of MIB objects) is all that is needed then we could reduce the whole
MIB to one single octet string. This is essentially the approach taken
in Kireeti's MIB.

> 
> > There already exists, and has existed for quite a while, a 
> TE MIB in the
> > mplswg. This MIB is generic and has evolved to incorporate 
> the comments of
> > the mplswg. Also, it has been deployed in several switches. 
> And, there are
> > very good operational and implementation reasons
> 
> Yet strangely enough, for almost all purposes which I would 
> need to run a
> network, the simple and spare kireeti MIB suffices. Just because I can
> solve some obscure corner case using the generic MIB does not mean I want
> to build a large annoying backend to support solving that corner case.  
> Operational reality is that 90% of most MIBS are never used and I do not
> want to hold up my network waiting till all parties are happy with a
> solution.

Like I said before, from the very narrow viewpoint of deploying a Juniper
network this is true. The existence of several implementations
of MPLS-TE-MIB means and the feedback we have received for close
to 2 years now does not agree with your conclusion about
implementation difficulty. Also, everyone (including you) has had ample
opportunity over this period of time to shape this MIB with their feedback
operationally or otherwise. And, the additional functionality that is
in the Kireeti MIB that is not in MPLS-TE-MIB can easily be added without
complicating the MIB any.

Cheenu


------_=_NextPart_001_01C0095A.9582036A
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2650.12">
<TITLE>RE: consensus to make draft-kompella-mpls-te-mib-00.txt a TEWG it em?</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Vijay Gill wrote:</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; On Fri, 18 Aug 2000, Cheenu Srinivasan wrote:</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Kireeti's MIB doesn't address numerous issues that would be </FONT>
<BR><FONT SIZE=2>&gt; necessary</FONT>
<BR><FONT SIZE=2>&gt; &gt; in a standard TE MIB. It supports a very limited model of TE using</FONT>
<BR><FONT SIZE=2>&gt; &gt; MPLS (specific to Juniper's switches). And, to put it bluntly, its</FONT>
<BR><FONT SIZE=2>&gt; &gt; quite badly designed stylistically as well. Its not a good idea to</FONT>
<BR><FONT SIZE=2>&gt; &gt; forget to &quot;keep things as simple as possible but no simpler&quot; or we</FONT>
<BR><FONT SIZE=2>&gt; &gt; would end up with</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Perhaps we are forgetting what problem we are trying to solve here? It</FONT>
<BR><FONT SIZE=2>&gt; supports a very limited and yet very operationally focused model. By a</FONT>
<BR><FONT SIZE=2>&gt; very strange coincidence it is what the operators seem to be </FONT>
<BR><FONT SIZE=2>&gt; asking for.</FONT>
<BR><FONT SIZE=2>&gt; Let us not forget that in the end, the worlds most intricate </FONT>
<BR><FONT SIZE=2>&gt; model of a</FONT>
<BR><FONT SIZE=2>&gt; MIB that is all things to all people, is not useful if it </FONT>
<BR><FONT SIZE=2>&gt; cannot be used</FONT>
<BR><FONT SIZE=2>&gt; to solve existing problems now, as opposed to what vendors </FONT>
<BR><FONT SIZE=2>&gt; _think_ will be</FONT>
<BR><FONT SIZE=2>&gt; existing problems a year from now.</FONT>
</P>

<P><FONT SIZE=2>If all you are interested in is Juniper switches I understand your</FONT>
<BR><FONT SIZE=2>viewpoint. However, the point of putting together a standard MIB</FONT>
<BR><FONT SIZE=2>is to make it general enough to implement on other switches as well.</FONT>
</P>

<P><FONT SIZE=2>&gt; As for the badly designed style, I cannot even begin to comment on</FONT>
<BR><FONT SIZE=2>&gt; that.&nbsp; Perhaps a look at the CLNS vs IP design philosophy </FONT>
<BR><FONT SIZE=2>&gt; might be worth a</FONT>
<BR><FONT SIZE=2>&gt; revisit. </FONT>
</P>

<P><FONT SIZE=2>If simplicity (which in this context seems to be minimizing the number</FONT>
<BR><FONT SIZE=2>of MIB objects) is all that is needed then we could reduce the whole</FONT>
<BR><FONT SIZE=2>MIB to one single octet string. This is essentially the approach taken</FONT>
<BR><FONT SIZE=2>in Kireeti's MIB.</FONT>
</P>

<P><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; There already exists, and has existed for quite a while, a </FONT>
<BR><FONT SIZE=2>&gt; TE MIB in the</FONT>
<BR><FONT SIZE=2>&gt; &gt; mplswg. This MIB is generic and has evolved to incorporate </FONT>
<BR><FONT SIZE=2>&gt; the comments of</FONT>
<BR><FONT SIZE=2>&gt; &gt; the mplswg. Also, it has been deployed in several switches. </FONT>
<BR><FONT SIZE=2>&gt; And, there are</FONT>
<BR><FONT SIZE=2>&gt; &gt; very good operational and implementation reasons</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Yet strangely enough, for almost all purposes which I would </FONT>
<BR><FONT SIZE=2>&gt; need to run a</FONT>
<BR><FONT SIZE=2>&gt; network, the simple and spare kireeti MIB suffices. Just because I can</FONT>
<BR><FONT SIZE=2>&gt; solve some obscure corner case using the generic MIB does not mean I want</FONT>
<BR><FONT SIZE=2>&gt; to build a large annoying backend to support solving that corner case.&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; Operational reality is that 90% of most MIBS are never used and I do not</FONT>
<BR><FONT SIZE=2>&gt; want to hold up my network waiting till all parties are happy with a</FONT>
<BR><FONT SIZE=2>&gt; solution.</FONT>
</P>

<P><FONT SIZE=2>Like I said before, from the very narrow viewpoint of deploying a Juniper</FONT>
<BR><FONT SIZE=2>network this is true. The existence of several implementations</FONT>
<BR><FONT SIZE=2>of MPLS-TE-MIB means and the feedback we have received for close</FONT>
<BR><FONT SIZE=2>to 2 years now does not agree with your conclusion about</FONT>
<BR><FONT SIZE=2>implementation difficulty. Also, everyone (including you) has had ample</FONT>
<BR><FONT SIZE=2>opportunity over this period of time to shape this MIB with their feedback</FONT>
<BR><FONT SIZE=2>operationally or otherwise. And, the additional functionality that is</FONT>
<BR><FONT SIZE=2>in the Kireeti MIB that is not in MPLS-TE-MIB can easily be added without</FONT>
<BR><FONT SIZE=2>complicating the MIB any.</FONT>
</P>

<P><FONT SIZE=2>Cheenu</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0095A.9582036A--



From owner-mpls@UU.NET  Fri Aug 18 17:26:28 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08843
	for <mpls-archive@lists.ietf.org>; Fri, 18 Aug 2000 17:26:27 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcvd21930;
	Fri, 18 Aug 2000 21:26:27 GMT
Received: by mail-control.mail.uu.net 
	id QQjcvd29310
	for mpls-outgoing; Fri, 18 Aug 2000 21:26:11 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjcvd29228
	for <mpls@mail-control.mail.uu.net>; Fri, 18 Aug 2000 21:25:59 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjcvd21340;
	Fri, 18 Aug 2000 17:25:54 -0400 (EDT)
Received: from mx1out.umbc.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mx1out.umbc.edu [130.85.253.51])
	id QQjcvd20809;
	Fri, 18 Aug 2000 21:25:54 GMT
Received: from gl.umbc.edu (vijay@irix1.gl.umbc.edu [130.85.60.8])
	by mx1out.umbc.edu (8.9.3/8.9.3) with ESMTP id RAA08839;
	Fri, 18 Aug 2000 17:25:53 -0400 (EDT)
Received: from localhost (vijay@localhost)
	by gl.umbc.edu (8.9.0/8.9.0) with ESMTP id RAA3753341;
	Fri, 18 Aug 2000 17:25:52 -0400 (EDT)
X-Authentication-Warning: irix1.gl.umbc.edu: vijay owned process doing -bs
Date: Fri, 18 Aug 2000 17:25:52 -0400
From: Vijay Gill <vijay@umbc.edu>
X-Sender: vijay@irix1.gl.umbc.edu
To: Cheenu Srinivasan <csrinivasan@tachion.com>
cc: te-wg@UU.NET, mpls@UU.NET
Subject: RE: consensus to make draft-kompella-mpls-te-mib-00.txt a TEWG it 
 em?
In-Reply-To: <A64EB7AC0201D411B864009027DC856C054D8F@TNNT3>
Message-ID: <Pine.SGI.4.21L.01.0008181721490.3659402-100000@irix1.gl.umbc.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

On Fri, 18 Aug 2000, Cheenu Srinivasan wrote:

> If all you are interested in is Juniper switches I understand your
> viewpoint. However, the point of putting together a standard MIB
> is to make it general enough to implement on other switches as well.

That I do not argue with.  In fact, we would very much like to have this
on all LSRs, such that we can switch out the front ends without having to
change the backends out.  What we would like is that the kireeti MIB be
standardized with the specical JNX bits generalized. The MIB is a good
match to how networks are being operated today, and as such, should form a
good basis for a standard MIB implemented across all platforms.

/vijay




From owner-mpls@UU.NET  Fri Aug 18 21:01:33 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12234
	for <mpls-archive@lists.ietf.org>; Fri, 18 Aug 2000 21:01:32 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcvs05741;
	Sat, 19 Aug 2000 01:01:32 GMT
Received: by mail-control.mail.uu.net 
	id QQjcvs25083
	for mpls-outgoing; Sat, 19 Aug 2000 01:00:57 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjcvs24803
	for <mpls@mail-control.mail.uu.net>; Sat, 19 Aug 2000 01:00:42 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjcvs05904
	for <mpls@uu.net>; Fri, 18 Aug 2000 21:00:16 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjcvs04852
	for <mpls@uu.net>; Sat, 19 Aug 2000 01:00:15 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id VAA16014
	for mpls@uu.net; Fri, 18 Aug 2000 21:00:14 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjcvr21890
	for <mpls@mail-control.mail.uu.net>; Sat, 19 Aug 2000 00:59:52 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjcvr05636;
	Fri, 18 Aug 2000 20:59:21 -0400 (EDT)
Received: from funnel.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQjcvr04019;
	Sat, 19 Aug 2000 00:59:05 GMT
Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.131.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id UAA24309; Fri, 18 Aug 2000 20:58:30 -0400 (EDT)
Received: from tnadeau-pc02.cisco.com ([161.44.204.102])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AAJ21177;
	Fri, 18 Aug 2000 20:58:27 -0400 (EDT)
Message-Id: <4.3.2.7.2.20000818203951.04dbc2e0@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 18 Aug 2000 20:46:15 -0400
To: Vijay Gill <vijay@umbc.edu>, Cheenu Srinivasan <csrinivasan@tachion.com>
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Subject: RE: consensus to make draft-kompella-mpls-te-mib-00.txt a TEWG
  it em?
Cc: te-wg@UU.NET, mpls@UU.NET, "'Jim Boyle'" <jboyle@Level3.net>
In-Reply-To: <Pine.SGI.4.21L.01.0008181645490.3659402-100000@irix1.gl.um
 bc.edu>
References: <A64EB7AC0201D411B864009027DC856C054D8B@TNNT3>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk


>Perhaps we are forgetting what problem we are trying to solve here? It
>supports a very limited and yet very operationally focused model. By a
>very strange coincidence it is what the operators seem to be asking for.

         This is only what a certain subset of operators are looking for.
The operators who are using the MPLS-TE-MIB which I have spoken to
are very happy with it. I believe this set to be much larger than
the 3 or 4 who seem to want to use Kireeti's MIB to completely manage
their MPLS LSRs.

>Yet strangely enough, for almost all purposes which I would need to run a
>network, the simple and spare kireeti MIB suffices.

         Yet strangely enough, it only suffices for networks which are
comprised of Juniper switches. Funny how that is, since it is
the Juniper proprietary MIB. I am sure that you would have the
same success with vendor X's proprietary MIBs as well.

>Just because I can
>solve some obscure corner case using the generic MIB does not mean I want
>to build a large annoying backend to support solving that corner case.
>Operational reality is that 90% of most MIBS are never used and I do not
>want to hold up my network waiting till all parties are happy with a
>solution.

         I hardly belive that fast-reroute, auto-bandwidth tunnels,
fast-reroute, tunnel path options, ER-LSPs, tunnel interface
statistics, etc.. are obscure problems. These may be obscure vapor
ware in the limited implementation from the vendor which you are
deploying LSRs from, but not in others that I know of.

         --Tom





From owner-mpls@UU.NET  Fri Aug 18 21:20:22 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12335
	for <mpls-archive@lists.ietf.org>; Fri, 18 Aug 2000 21:20:21 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcvt06577;
	Sat, 19 Aug 2000 01:20:20 GMT
Received: by mail-control.mail.uu.net 
	id QQjcvt05686
	for mpls-outgoing; Sat, 19 Aug 2000 01:20:01 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjcvt05661
	for <mpls@mail-control.mail.uu.net>; Sat, 19 Aug 2000 01:19:49 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjcvt07833
	for <mpls@uu.net>; Fri, 18 Aug 2000 21:19:28 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjcvt16434
	for <mpls@uu.net>; Sat, 19 Aug 2000 01:19:12 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id VAA17493
	for mpls@uu.net; Fri, 18 Aug 2000 21:19:11 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjcvt05583
	for <mpls@mail-control.mail.uu.net>; Sat, 19 Aug 2000 01:18:43 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjcvt23379;
	Fri, 18 Aug 2000 21:18:39 -0400 (EDT)
Received: from funnel.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQjcvt16001;
	Sat, 19 Aug 2000 01:18:38 GMT
Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.131.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id VAA25212; Fri, 18 Aug 2000 21:18:38 -0400 (EDT)
Received: from tnadeau-pc02.cisco.com ([161.44.204.102])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AAJ21233;
	Fri, 18 Aug 2000 21:18:35 -0400 (EDT)
Message-Id: <4.3.2.7.2.20000818204639.04dbe5f0@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 18 Aug 2000 21:06:13 -0400
To: Vijay Gill <vijay@umbc.edu>
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Subject: Re: consensus to make draft-kompella-mpls-te-mib-00.txt a  
  TEWGitem?
Cc: Randy Bush <randy@psg.com>, te-wg@UU.NET, mpls@UU.NET
In-Reply-To: <Pine.SGI.4.21L.01.0008181712300.3659402-100000@irix1.gl.um
 bc.edu>
References: <4.3.2.7.2.20000818135125.04dc7920@bucket.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk


> > reality of the Juniper implementation. This is not the reality of what the
> > rest of the world uses. Furthermore, it does not necessarily contain the
> > operational reality of MPLS features that other LSR vendors are currently
> > deploying due to its incomplete nature.
>
>Ah yes, I see the disconnect now.
>
>I am coming from the reality of the operators world, who have to use these

         You are coming from the reality of a rather small operator
world that only uses Juniper boxes in their network. I am
trying to speak for those operators who I have spoken with, who
are in the majority. These folks have networks which are not comprised
of a single vendor's devices. This group manages networks comprised of
boxes from many vendors and would specifically like to use a single MIB
to do this. It is an operational nightmare to have to figure out which
vendors boxes (and perhaps which versions of those boxes) use which
standard MIB. In these cases your Juniper-specific solution just will
not work for the reasons which I and others have outlined about 10 times
today. I hope that people are seeing this situation for what it really
is.

>things on a daily basis to keep a network up and running vs the reality of
>those vendors who think they know better than we what we want.

         If I understand you correctly the, "reality of those vendors who
think they know better than we what we want" means not exclusively using
Juniper boxes. If I am understanding you correctly, then this sounds okay
to me. Remember, you are free to deploy whatever you want in your network.
Bear in mind that you are in the minority of operators. We all know what
the reality of the situation is not a homogeneous network of LSRs. For
this reason, the majority of operators (and all of the ones which I personally
spoke with today) want to use a single, standard (i.e.: non-proprietary)
MIB to manage all of the *different* LSRs that they have deployed in their
networks.

         --Tom




From owner-mpls@UU.NET  Fri Aug 18 21:35:25 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13430
	for <mpls-archive@lists.ietf.org>; Fri, 18 Aug 2000 21:35:24 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcvu04271;
	Sat, 19 Aug 2000 01:35:24 GMT
Received: by mail-control.mail.uu.net 
	id QQjcvu06887
	for mpls-outgoing; Sat, 19 Aug 2000 01:35:01 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjcvu06876
	for <mpls@mail-control.mail.uu.net>; Sat, 19 Aug 2000 01:34:58 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjcvu25087
	for <mpls@uu.net>; Fri, 18 Aug 2000 21:34:48 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjcvu24555
	for <mpls@uu.net>; Sat, 19 Aug 2000 01:34:32 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id VAA18759
	for mpls@uu.net; Fri, 18 Aug 2000 21:34:32 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjcvu06819
	for <mpls@mail-control.mail.uu.net>; Sat, 19 Aug 2000 01:34:07 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjcvu09149;
	Fri, 18 Aug 2000 21:34:01 -0400 (EDT)
Received: from funnel.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQjcvu24318;
	Sat, 19 Aug 2000 01:34:00 GMT
Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.131.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id VAA25901; Fri, 18 Aug 2000 21:34:00 -0400 (EDT)
Received: from tnadeau-pc02.cisco.com ([161.44.204.102])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AAJ21276;
	Fri, 18 Aug 2000 21:33:58 -0400 (EDT)
Message-Id: <4.3.2.7.2.20000818211359.04db9600@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 18 Aug 2000 21:21:27 -0400
To: Vijay Gill <vijay@umbc.edu>, Cheenu Srinivasan <csrinivasan@tachion.com>
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Subject: RE: consensus to make draft-kompella-mpls-te-mib-00.txt a TEWG
  it  em?
Cc: te-wg@UU.NET, mpls@UU.NET
In-Reply-To: <Pine.SGI.4.21L.01.0008181721490.3659402-100000@irix1.gl.um
 bc.edu>
References: <A64EB7AC0201D411B864009027DC856C054D8F@TNNT3>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk


         Hi,

> > If all you are interested in is Juniper switches I understand your
> > viewpoint. However, the point of putting together a standard MIB
> > is to make it general enough to implement on other switches as well.
>
>That I do not argue with.  In fact, we would very much like to have this
>on all LSRs, such that we can switch out the front ends without having to
>change the backends out.  What we would like is that the kireeti MIB be
>standardized with the specical JNX bits generalized. The MIB is a good
>match to how networks are being operated today, and as such, should form a
>good basis for a standard MIB implemented across all platforms.

         So why not just take the salient features out of that MIB and
put them into the MPLS-TE-MIB? All of these features could easily be
included in the TE-MIB, as well as other features for the
others who were interested in them. If you have looked at the
MPLS-TE-MIB lately (which I unfortunately do not believe many
of the folks commenting for keeping this other MIB today have not),
it is not that much larger than Kireeti's MIB in terms of tables to
manage. The change in your operational software should not be that significant
considering the structure of things. We currently have 4 tables, one of which
is optional. Two of these tables are basically for the tunnel Hop information
which Kireeti has crammed into a single OCTET-STRING (very bad design).
If you don't care to look at LSP information, then don't follow the
XCIndex down into the MPLS-LSR-MIB and be done with it. We can easily
make conforming with the MIB easier by making some other tables
optional.

         --Tom




From owner-mpls@UU.NET  Sat Aug 19 00:23:05 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15718
	for <mpls-archive@lists.ietf.org>; Sat, 19 Aug 2000 00:23:05 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcwf08421;
	Sat, 19 Aug 2000 04:23:02 GMT
Received: by mail-control.mail.uu.net 
	id QQjcwf26205
	for mpls-outgoing; Sat, 19 Aug 2000 04:22:42 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjcwf26196
	for <mpls@mail-control.mail.uu.net>; Sat, 19 Aug 2000 04:22:34 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjcwf12422;
	Sat, 19 Aug 2000 00:22:13 -0400 (EDT)
Received: from mx3out.umbc.edu by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mx3out.umbc.edu [130.85.253.53])
	id QQjcwf20900;
	Sat, 19 Aug 2000 04:21:57 GMT
Received: from gl.umbc.edu (vijay@irix1.gl.umbc.edu [130.85.60.8])
	by mx3out.umbc.edu (8.9.3/8.9.3) with ESMTP id AAA08266;
	Sat, 19 Aug 2000 00:21:56 -0400 (EDT)
Received: from localhost (vijay@localhost)
	by gl.umbc.edu (8.9.0/8.9.0) with ESMTP id AAA3599610;
	Sat, 19 Aug 2000 00:21:54 -0400 (EDT)
X-Authentication-Warning: irix1.gl.umbc.edu: vijay owned process doing -bs
Date: Sat, 19 Aug 2000 00:21:54 -0400
From: Vijay Gill <vijay@umbc.edu>
X-Sender: vijay@irix1.gl.umbc.edu
To: "Thomas D. Nadeau" <tnadeau@cisco.com>
cc: Randy Bush <randy@psg.com>, te-wg@UU.NET, mpls@UU.NET
Subject: Re: consensus to make draft-kompella-mpls-te-mib-00.txt a    TEWGitem?
In-Reply-To: <4.3.2.7.2.20000818204639.04dbe5f0@bucket.cisco.com>
Message-ID: <Pine.SGI.4.21L.01.0008190019080.3589459-100000@irix1.gl.umbc.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

On Fri, 18 Aug 2000, Thomas D. Nadeau wrote:


>          If I understand you correctly the, "reality of those vendors who
> think they know better than we what we want" means not exclusively using
> Juniper boxes. If I am understanding you correctly, then this sounds okay
> to me. Remember, you are free to deploy whatever you want in your network.
> Bear in mind that you are in the minority of operators. We all know what

I think randy has spoken for the rest of the messages with the union vs
intersection post.  As for deploying what we want, we are going to do
precisely that and we'll check back next year, same bat list.

/vijay




From owner-mpls@UU.NET  Sat Aug 19 05:36:55 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29424
	for <mpls-archive@lists.ietf.org>; Sat, 19 Aug 2000 05:36:55 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcxa16289;
	Sat, 19 Aug 2000 09:36:54 GMT
Received: by mail-control.mail.uu.net 
	id QQjcxa19805
	for mpls-outgoing; Sat, 19 Aug 2000 09:36:23 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjcxa19800
	for <mpls@mail-control.mail.uu.net>; Sat, 19 Aug 2000 09:36:19 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjcxa11060
	for <mpls@UU.net>; Sat, 19 Aug 2000 05:36:13 -0400 (EDT)
Received: from csa.iisc.ernet.in by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: csa.iisc.ernet.in [144.16.67.8])
	id QQjcxa14495
	for <mpls@UU.net>; Sat, 19 Aug 2000 09:35:55 GMT
Received: from turing.csa.iisc.ernet.in (IDENT:root@turing.csa.iisc.ernet.in [144.16.67.4])
	by csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id PAA24401
	for <mpls@UU.net>; Sat, 19 Aug 2000 15:05:39 +0530
Received: from localhost (ytr@localhost)
	by turing.csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id PAA07986
	for <mpls@UU.net>; Sat, 19 Aug 2000 15:05:50 +0530
X-Authentication-Warning: turing.csa.iisc.ernet.in: ytr owned process doing -bs
Date: Sat, 19 Aug 2000 15:05:50 +0530 (IST)
From: Ramanjaneyulu Y T <ytr@csa.iisc.ernet.in>
To: mpls@UU.NET
Subject: questions on MPLS fragmentation
Message-ID: <Pine.LNX.4.10.10008191504140.7154-100000@turing.csa.iisc.ernet.in>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,
  I have some doubts in draft-ietf-mpls-label-encaps-08.txt . Please help
me in this regards.

I have questions in 
-----------------
  '3.4. Processing Labeled IPv4 Datagrams which are Too Big'which is  
under 'Fragmentation and PathMTU' section .
-------------------

  1. How to check DF bit in IP packet ? ( Shall i strip all MPLS labels
and check or any direct method availabel ?)



  2.  The following is the text from the draft. 

--------------------------
   If a labeled IPv4 datagram is "too big", and the DF bit is not set in
   its IP header, then the LSR MAY silently discard the datagram.

   Note that discarding such datagrams is a sensible procedure only if
   the "Maximum Initially Labeled IP Datagram Size" is set to a non-zero
   value in every LSR in the network which is capable of adding a label
   stack to an unlabeled IP datagram.
 -----------------

I didn't get the condition behind this statement ?. 'DF' bit is not set
means one can fragment the packet, but why condition (Maximum Initially
Labeled IP Datagram Size )  is required to fragment eventhough if DF is
not set ?


 3. The following is the text from draft.

------------
If the LSR chooses not to discard a labeled IPv4 datagram which is
   too big, or if the DF bit is set in that datagram, then it MUST
   execute the following algorithm:

      1. Strip off the label stack entries to obtain the IP datagram.

      2. Let N be the number of bytes in the label stack (i.e, 4 times
         the number of label stack entries).

      3. If the IP datagram does NOT have the "Don't Fragment" bit set
         in its IP header:
------------------

   In above para eventhough DF bit is set why fragmentation is required? 


Please explain clearly what this section means.

         Thanking you,

                                         
                                         Regards
                                        Ramanjaneyulu Y.T. 
 
 " A real friend is one who walks in when the rest of the world walks
 out."
 ------------------------------------------------------------------------------ 
Y.T.RAMANJANEYULU                        |   My other mail Ids:
E-70,INDIAN INSTITUTE OF SCIENCE         |         ytr@rediffmail.com
BANGALORE - 560012                       |         kingytr@excite.com
PH: 0091 - 080 - 3092622 ( HOSTEL )      |
    0091 - 080 - 3092906 ( LAB )         |
                   visit my home page:www2.csa.iisc.ernet.in/~ytr
--------------------------------------------------------------------------------



From owner-mpls@UU.NET  Sat Aug 19 18:04:56 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03450
	for <mpls-archive@lists.ietf.org>; Sat, 19 Aug 2000 18:04:56 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjcyy01687;
	Sat, 19 Aug 2000 22:04:21 GMT
Received: by mail-control.mail.uu.net 
	id QQjcyy22091
	for mpls-outgoing; Sat, 19 Aug 2000 22:04:02 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjcyy22048
	for <mpls@mail-control.mail.uu.net>; Sat, 19 Aug 2000 22:03:49 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjcyy21390;
	Sat, 19 Aug 2000 18:03:47 -0400 (EDT)
Received: from force10networks.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtp.force10networks.com [206.54.51.114])
	id QQjcyy01329;
	Sat, 19 Aug 2000 22:03:46 GMT
Received: by tonga.ncorenetworks.com with Internet Mail Service (5.5.2650.21)
	id <RBK2SSB9>; Sat, 19 Aug 2000 15:03:44 -0700
Message-ID: <23a447fd6def6de6c75bbda48ed9b6c0399f04d6@force10networks.com>
From: Arun Viswanathan <arun@force10networks.com>
To: "'Jim Boyle'" <jboyle@Level3.net>, te-wg@UU.NET
Cc: mpls@UU.NET
Subject: RE: consensus to make draft-kompella-mpls-te-mib-00.txt a TEWG it
	em?
Date: Sat, 19 Aug 2000 15:03:41 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk



> So, with that said - I'd like to see what the consensus of 
> the list is.
> 
> Should Kireeti's draft
> a) be accepted as a TE WG item at this time?
> b) not be accepted as a TE WG item at this time?

I think we should not accept the MIB as a TE WG item.
With all that's been said in favor of Kireeti's MIB by a few,
I am not convinced that a separate operationally focused MIB
is required apart from the MPLS-TE-MIB. Obviously, Kireeti's
MIB hasn't found multi-vendor support from folks who
provide MPLS TE products. Moreover, I haven't seen much
support from the operators for a 'separate MIB' besides a few.

But, one thing is clear. Kireeti's MIB has some operational
friendly objects (if the MIB in its entirety is operationally
friendly is a subjective matter). But these objects are only
a few, and can easily be incorporated into the MPLS-TE-MIB.
Ron provided a concise list of these objects.

The MPLS-TE-MIB is fairly matured at this time. In fact, we
are planning on requesting a last call with some minor edits.
I think extending the MPLS-TE-MIB for this would be the
quickest path to getting a standards track MIB that finds
rough consensus of the WG(s). I think it would be
a waste of effort to make the TE WG undergo the process of
finding such a consensus all over again, especially without
earnestly exploring why the MIBs cannot or should not be merged.

-arun


From owner-mpls@UU.NET  Sat Aug 19 19:22:02 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03688
	for <mpls-archive@lists.ietf.org>; Sat, 19 Aug 2000 19:22:02 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjczd19489;
	Sat, 19 Aug 2000 23:22:00 GMT
Received: by mail-control.mail.uu.net 
	id QQjczd10770
	for mpls-outgoing; Sat, 19 Aug 2000 23:21:43 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjczd10761
	for <mpls@mail-control.mail.uu.net>; Sat, 19 Aug 2000 23:21:40 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjczd28887;
	Sat, 19 Aug 2000 19:21:36 -0400 (EDT)
Received: from red.juniper.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: natint.juniper.net [207.17.136.129])
	id QQjczd12237;
	Sat, 19 Aug 2000 23:21:21 GMT
Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90])
	by red.juniper.net (8.9.3/8.9.3) with ESMTP id QAA24567;
	Sat, 19 Aug 2000 16:21:20 -0700 (PDT)
Received: (from kireeti@localhost) by kummer.juniper.net (8.8.7/8.7.3) id QAA14150; Sat, 19 Aug 2000 16:20:46 -0700 (PDT)
Date: Sat, 19 Aug 2000 16:20:46 -0700 (PDT)
From: Kireeti Kompella <kireeti@juniper.net>
Message-Id: <200008192320.QAA14150@kummer.juniper.net>
To: jboyle@Level3.net, te-wg@UU.NET
Subject: Re: consensus to make draft-kompella-mpls-te-mib-00.txt a TEWG item?
Cc: mpls@UU.NET
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

Reading through the vigorous debate in response to Jim's mail (thanks,
Jim!), especially Randy's, Vijay's and other service providers' input,
a thought crystallized; and I have a suggestion.

Let me cut to the chase:

***  Rename draft-ietf-mpls-te-mib      ***
***  to     draft-ietf-mpls-tunnel-mib  ***

There will be those who reject the above out-of-hand.  The rest
may care to read on and see if the following makes sense.

------------------

1) te-mib = Traffic Engineering MIB

Traffic Engineering is the mapping of traffic to traffic trunks
(see RFC 2702) for the purpose of performance optimization of
networks.  Vital to this is the routing of the traffic trunks; an
important component is the use of constraints and constraint-based
routing to this end.  Pragmatism (and RFC 2702) also dictates that
there be alternative paths for a trunk (read: primary/secondary paths).

Therefore, it would seem logical for a TE MIB to offer means to view:

a) administrative group information;
b) constraints on traffic trunks;
c) the means by which constraint information was obtained;
d) the results of constraint-based routing (EROs).

Furthermore, since trunk routing is important:

e) stats on how often trunks were re-routed (and the last time this
   happened).

From the T in TE:

f) stats on packet and octet counts through a traffic trunk.

Finally, since the objective of TE is to "optimize the network":

g) how much time a trunk used its primary path (more optimal) vs.
h) how much time a trunk used a secondary path (less optimal) vs.
i) how much time a trunk was down.

Of all of the above, the "mpls-tunnel-mib" only provides the ERO.
The "te-mib" provides all of the above.  There may be other info that
is TE-related that one or the other MIB provides, or that neither
does; however, that is for the TE WG to determine and recommend.

Action item: replace all occurences of "mplsLsp..." in the "Kireeti"
TE MIB with "trafficTrunk...".

-------------------

2) MPLS Tunnel MIB = Tunnel + MPLS

The excellently written "mpls-tunnel-mib" doesn't once mention
traffic engineering in its "features list" (section 4) or its
outline (section 5), except in naming the MIB.  These two
sections focus exclusively on tunnels, as does the entire MIB.

Furthermore, the MIB does a good job of deconstructing tunnels
into their constituent components (segments), and offers the
flexibility of defining
   a) point-to-point tunnels;
   b) multipoint-to-point tunnels;
   c) point-to-multipoint tunnels;

and of defining tunnel properties, such as whether or not they
are interfaces, fast-reroute, merging-permitted, ...

So, this is very much a tunnel MIB.

Moreover, the MIB offers (through close interaction with the LSR
MIB) the labels in and labels out information -- hence very much
an MPLS MIB.

The above information, while largely irrelevant to Traffic
Engineering, is vital indeed (as witness the large following the
MIB has).  The two years of work that has gone into this MIB have
been well spent.

---------------------

3) The argument to incorporate the TE MIB into the MPLS Tunnel MIB
   because MPLS tunnels can be used to do TE extends naturally to:
   incorporate the Diff-Serv MIB into the MPLS Tunnel MIB because
   MPLS tunnels can be used very effectively to do Diff Serv (RFC
   2430 and draft-ietf-mpls-diff-ext); and (in its ludicrous extreme)
   to fold in the interface MIB since MPLS tunnels can be interfaces.

This argument is best put to rest.

Kireeti.


From owner-mpls@UU.NET  Sat Aug 19 21:39:18 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05180
	for <mpls-archive@lists.ietf.org>; Sat, 19 Aug 2000 21:39:17 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjczm02861;
	Sun, 20 Aug 2000 01:39:16 GMT
Received: by mail-control.mail.uu.net 
	id QQjczm14977
	for mpls-outgoing; Sun, 20 Aug 2000 01:38:42 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjczm14971
	for <mpls@mail-control.mail.uu.net>; Sun, 20 Aug 2000 01:38:40 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjczm13451;
	Sat, 19 Aug 2000 21:38:37 -0400 (EDT)
Received: from force10networks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtp.force10networks.com [206.54.51.114])
	id QQjczm02246;
	Sun, 20 Aug 2000 01:38:22 GMT
Received: by tonga.ncorenetworks.com with Internet Mail Service (5.5.2650.21)
	id <RBK2SSFT>; Sat, 19 Aug 2000 18:38:20 -0700
Message-ID: <4a309caa1ce3fcf15d6fdcea58119110399f3728@force10networks.com>
From: Arun Viswanathan <arun@force10networks.com>
To: "'Kireeti Kompella'" <kireeti@juniper.net>, jboyle@Level3.net,
        te-wg@UU.NET
Cc: mpls@UU.NET
Subject: RE: consensus to make draft-kompella-mpls-te-mib-00.txt a TEWG it
	em?
Date: Sat, 19 Aug 2000 18:38:20 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk


Kireeti,

> 
> Action item: replace all occurences of "mplsLsp..." in the "Kireeti"
> TE MIB with "trafficTrunk...".
> 
> 

Good try :-)

Your MIB is also a tunnel MIB. There is no difference between a tunnel
defined in MPLS-TE-MIB or your MIB wrt a traffic-trunk defined in PASTE
or rfc2702. A tunnel is a entity routable based on some constrains. 
However there is difference, in addition to a tunnel, a traffic-trunk
also represents the associated FECs (or a set of traffic flows belonging
to a class). In other words, a traffic-trunk is tunnel and FECs considered
together.

Howsoever you may choose to slice or dice it, I think the two MIBs
are largely the same, where your MIB has some operationally interesting
objects not contained in the MPLS-TE-MIB. I think this is the main
reason for this debate.

-arun


From owner-mpls@UU.NET  Sun Aug 20 00:42:41 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07148
	for <mpls-archive@lists.ietf.org>; Sun, 20 Aug 2000 00:42:40 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjczy11984;
	Sun, 20 Aug 2000 04:42:37 GMT
Received: by mail-control.mail.uu.net 
	id QQjczy04387
	for mpls-outgoing; Sun, 20 Aug 2000 04:42:02 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjczy04379
	for <mpls@mail-control.mail.uu.net>; Sun, 20 Aug 2000 04:42:00 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjczy03715
	for <mpls@uu.net>; Sun, 20 Aug 2000 00:41:42 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjczy11299
	for <mpls@uu.net>; Sun, 20 Aug 2000 04:41:26 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id AAA26092
	for mpls@uu.net; Sun, 20 Aug 2000 00:41:25 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjczy04236
	for <mpls@mail-control.mail.uu.net>; Sun, 20 Aug 2000 04:40:44 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjczy02257;
	Sun, 20 Aug 2000 00:40:36 -0400 (EDT)
Received: from tcb.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: tcb.net [205.168.100.1])
	id QQjczy10849;
	Sun, 20 Aug 2000 04:40:35 GMT
Received: from sofos.tcb.net (sofos.tcb.net [127.0.0.1])
	by tcb.net (8.9.3/8.9.3) with ESMTP id WAA22653;
	Sat, 19 Aug 2000 22:41:18 -0600
Message-Id: <200008200441.WAA22653@tcb.net>
To: "Thomas D. Nadeau" <tnadeau@cisco.com>
cc: te-wg@UU.NET, mpls@UU.NET
From: Danny McPherson <danny@ambernetworks.com>
Reply-To: danny@ambernetworks.com
Subject: "Two roads diverged in a yellow wood"
Date: Sat, 19 Aug 2000 22:41:18 -0600
Sender: owner-mpls@UU.NET
Precedence: bulk


Thomas, 
Perhaps some of these operators you've spoken with and
keep referring to should "chime in"?  Do they have email?
Can they speak for themselves?  I've reviewed all the
posts to the thread and not seen a single one of "your
operators" voice their own opinions.  

For that matter, a glean of the archives doesn't indicate
their existence either.  

I think the reality here is that folks who are deploying
MPLS/TE and need to manage their networks today are happy
with a MIB similar to that of Kireeti's, simply because 
it's sufficient for what they're doing.  The folks that 
have been working some 2 years "MPLS-TE-MIB" have just 
been blind-sided by the simplicity and [arguable] 
usability of such a trivial, non-academically-geared MIB,
while they've been off in their corner developing this 
perfectly structured, academically sound, looks-good-on-
paper MIB.

It would seem this is occurring all to often in the IETF 
today, that's unfortunate.

As for what we do now, good question.  While I completely 
agree with Randy/Vijay's comments, I also understand there's
significant value in a single MIB.  Perhaps the right way
to go is to merge the MIBs, with some wording surrounding
the use of Kireeti's MIB as a base, and the "MPLS-TE-MIB"
as the "full MIB".  While I'm guessing this goes against 
all the "MPLS-TE-MIB" folks stand for,  and do realize it's
not quite that simple, I'm also guessing it's the only 
agreement that I foresee will result in a single MIB.

[side note:  as for the repetitive "that's only because
you use Juniper's in your network", get over it -- especially
you]

-danny

> world that only uses Juniper boxes in their network. I am
> trying to speak for those operators who I have spoken with, who
> are in the majority. These folks have networks which are not comprised
> of a single vendor's devices. This group manages networks comprised of
> boxes from many vendors and would specifically like to use a single MIB
> to do this. It is an operational nightmare to have to figure out which
> vendors boxes (and perhaps which versions of those boxes) use which
> standard MIB. In these cases your Juniper-specific solution just will
> not work for the reasons which I and others have outlined about 10 times
> today. I hope that people are seeing this situation for what it really
> is.



From owner-mpls@UU.NET  Sun Aug 20 22:13:20 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13128
	for <mpls-archive@lists.ietf.org>; Sun, 20 Aug 2000 22:13:20 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjddg16992;
	Mon, 21 Aug 2000 02:13:19 GMT
Received: by mail-control.mail.uu.net 
	id QQjddg05345
	for mpls-outgoing; Mon, 21 Aug 2000 02:12:47 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjddg05336
	for <mpls@mail-control.mail.uu.net>; Mon, 21 Aug 2000 02:12:37 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjddg28496
	for <mpls@uu.net>; Sun, 20 Aug 2000 22:12:32 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjddg16525
	for <mpls@uu.net>; Mon, 21 Aug 2000 02:12:32 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id WAA09446
	for mpls@uu.net; Sun, 20 Aug 2000 22:12:31 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjddg05315
	for <mpls@mail-control.mail.uu.net>; Mon, 21 Aug 2000 02:11:57 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjddg28442
	for <mpls@uu.net>; Sun, 20 Aug 2000 22:11:37 -0400 (EDT)
Received: from smbmail3.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smbmail3.cisco.com [171.71.162.38])
	id QQjddg22722
	for <mpls@uu.net>; Mon, 21 Aug 2000 02:11:22 GMT
Received: from hbelurntl (hbelur-dsl3.cisco.com [10.19.19.44])
	by smbmail3.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id TAA25691
	for <mpls@uu.net>; Sun, 20 Aug 2000 19:11:21 -0700 (PDT)
Message-ID: <004d01c00b14$d09d38f0$2c13130a@cisco.com>
Reply-To: "Harish Belur" <hbelur@cisco.com>
From: "Harish Belur" <hbelur@cisco.com>
To: <mpls@UU.NET>
Subject: MPLS & Ethernet
Date: Sun, 20 Aug 2000 19:09:18 -0700
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
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi,

I apologize if this has been asked and answered on this list since I am new
to this list.
How is MPLS expected to work on technologies like ethernet which have a
specific MTU ? What is the specified behavior if the packet exceeds MTU size
once a label (or stack of labels) has been added to the packet ?

Thanks,

Harish




From owner-mpls@UU.NET  Sun Aug 20 23:53:42 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14878
	for <mpls-archive@lists.ietf.org>; Sun, 20 Aug 2000 23:53:42 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjddn17494;
	Mon, 21 Aug 2000 03:53:24 GMT
Received: by mail-control.mail.uu.net 
	id QQjddn23163
	for mpls-outgoing; Mon, 21 Aug 2000 03:53:09 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjddn23158
	for <mpls@mail-control.mail.uu.net>; Mon, 21 Aug 2000 03:52:58 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjddn25238
	for <mpls@UU.NET>; Sun, 20 Aug 2000 23:52:57 -0400 (EDT)
Received: from csa.iisc.ernet.in by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: csa.iisc.ernet.in [144.16.67.8])
	id QQjddn17165
	for <mpls@UU.NET>; Mon, 21 Aug 2000 03:52:54 GMT
Received: from turing.csa.iisc.ernet.in (IDENT:root@turing.csa.iisc.ernet.in [144.16.67.4])
	by csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id JAA19324;
	Mon, 21 Aug 2000 09:22:36 +0530
Received: from localhost (ytr@localhost)
	by turing.csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id JAA18757;
	Mon, 21 Aug 2000 09:22:50 +0530
X-Authentication-Warning: turing.csa.iisc.ernet.in: ytr owned process doing -bs
Date: Mon, 21 Aug 2000 09:22:50 +0530 (IST)
From: Ramanjaneyulu Y T <ytr@csa.iisc.ernet.in>
To: Harish Belur <hbelur@cisco.com>
cc: mpls@UU.NET
Subject: Re: MPLS & Ethernet
In-Reply-To: <004d01c00b14$d09d38f0$2c13130a@cisco.com>
Message-ID: <Pine.LNX.4.10.10008210921590.18708-100000@turing.csa.iisc.ernet.in>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,  


   Please refer draft-ietf-mpls-label-encaps-08.txt for all details.

                                         
                                         Regards
                                        Ramanjaneyulu Y.T. 
 

On Sun, 20 Aug 2000, Harish Belur wrote:

> Hi,
> 
> I apologize if this has been asked and answered on this list since I am new
> to this list.
> How is MPLS expected to work on technologies like ethernet which have a
> specific MTU ? What is the specified behavior if the packet exceeds MTU size
> once a label (or stack of labels) has been added to the packet ?
> 
> Thanks,
> 
> Harish
> 
> 



From owner-mpls@UU.NET  Mon Aug 21 04:27:13 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28392
	for <mpls-archive@lists.ietf.org>; Mon, 21 Aug 2000 04:27:13 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdef25068;
	Mon, 21 Aug 2000 08:27:00 GMT
Received: by mail-control.mail.uu.net 
	id QQjdef07468
	for mpls-outgoing; Mon, 21 Aug 2000 08:26:44 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjdef07460
	for <mpls@mail-control.mail.uu.net>; Mon, 21 Aug 2000 08:26:42 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjdef08893
	for <mpls@UU.NET>; Mon, 21 Aug 2000 04:26:30 -0400 (EDT)
Received: from smtprch1.nortel.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtprch1.nortelnetworks.com [192.135.215.14])
	id QQjdef24709
	for <mpls@UU.NET>; Mon, 21 Aug 2000 08:26:30 GMT
Received: from zrchh190 by smtprch1.nortel.com; Wed, 16 Aug 2000 10:20:37 -0500
Received: from zcard00p.ca.nortel.com by zrchh190;
          Wed, 16 Aug 2000 10:23:53 -0500
Received: from americasm01.nt.com (wcars0v1.ca.nortel.com [47.14.98.167]) 
          by zcard00p.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) 
          id Q8FGFBGF; Wed, 16 Aug 2000 11:19:43 -0400
Message-ID: <399AB10E.D52BF1D2@americasm01.nt.com>
Date: Wed, 16 Aug 2000 11:19:43 -0400
From: "Darek Skalecki" <dareks@nortelnetworks.com>
Organization: Nortel
X-Mailer: Mozilla 4.06 [en] (X11; I; SunOS 5.6 sun4u)
MIME-Version: 1.0
To: mpls@UU.NET
Subject: LSP setup across IGP areas
References: <200008161049.GAA21550@ietf.org>
Content-Type: multipart/alternative;
              boundary="------------FD271251B4C8C858E81F3A0D"
X-Orig: <dareks@americasm01.nt.com>
Sender: owner-mpls@UU.NET
Precedence: bulk


--------------FD271251B4C8C858E81F3A0D
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I have a couple of questions/comments in association with
draft-venkatachalam-interarea-mpls-te-00.txt about LSP setup across IGP areas.

1. In section 4.4 (Routing algorithm):

   6. If the destination is in this area, calculate an intra-area route
      from the originating node to the destination that satisfies the
               ^^^^^^^^^^^^^^^^
      constraints, and splice the egress of the original LSP and the
                                                ^^^^^^^^^^^^
      ingress of the new LSP.

Shouldn't it be transit ABR instead of originating node, and also upstream LSP
instead of original LSP.

2. Is there some special software entity besides the signaling entity (RSVP-TE or
CR-LDP) at ABR that splices upstream LSP section to downstream LSP section. Is this
entity what you call routing process in step 4 of section 4.4. Is this entity
responsible for intercepting LABEL_REQUEST and PATH (as well as other CR-LDP and
RSVP) messages at ABRs.

3. About crankback. It is stated that crankback is to the previous nearest ABR from
the point of failure. At that ABR the routing algorithm by routing process is
repeated.  Is there any mechanism that prevents the selection of the same ABR as
was used previously. For example, refering to the following example

Area 1                      Area 0                    Area 2
--------------------    ------------------     ------------------------
|                  |    |                 |    |                       |
|  |N1  PPS1       -------    PPS3       --------      PPS5      |N2   |
|  |-------------- |ABR1  |--------------|ABR 2 |--------X-------|     |
|  |-------|       -------               -------- --|PPS7 |------|     |
|   PSS2   |       -------    PSS4       --------   |-----| PSS6       |
|          --------|ABR 3 |--------------|ABR 4  |---------            |
|                  -------               --------                      |
|                  |    |                 |    |                       |
--------------------    -------------------    -------------------------

Let's assume PPS5 failed and we initially cranked back to ABR 2 but there was no
intra-area route to the destination so we cranked back to ABR1. At ABR1 when
performing the algorithm of section 4.4 we should not consider ABR2 as this is from
where we cranked back and we know that ABR2 already tried unsuccessfully to route
to the destination.

Also, routing in response to crankback really depends on whether the failure
causing the crankback was within the current area or another downstream area. If it
was within the current area then same downstream ABR can be selected. If it was
outside of the current area then a different ABR should be selected. For example,
if PPS5 fails and we crank back to ABR2 then to ABR1 (as I eluded to above) then
ABR2 should not be considered when routing at ABR1. On the other hand, if PPS3
fails and we crank back to ABR1 then ABR2 should be considered.

4. Have you given some thought to the idea that an LSP section failure in one area
should not have an effect on surrounding LSP sections in other areas. For example,
refering to the above picture, if PPS3 fails then another intra-area route through
Area 0 between ABR1 and ABR2 is computed and LSP section reestablished along that
route without affecting LSP sections PPS1 and PPS5. This would be similar to "local
repair" where local = area.

Cheers,

Darek




--------------FD271251B4C8C858E81F3A0D
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
I have a couple of questions/comments in association with draft-venkatachalam-interarea-mpls-te-00.txt
about LSP setup across IGP areas.
<P>1. In section 4.4 (Routing algorithm):
<P><TT>&nbsp;&nbsp; 6. If the destination is in this area, calculate an
intra-area route</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; from the originating node to the
destination that satisfies the</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
^^^^^^^^^^^^^^^^</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; constraints, and splice the egress
of the original LSP and the</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
^^^^^^^^^^^^</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ingress of the new LSP.</TT>
<P>Shouldn't it be transit ABR instead of originating node, and also upstream
LSP instead of original LSP.
<P>2. Is there some special software entity besides the signaling entity
(RSVP-TE or CR-LDP) at ABR that splices upstream LSP section to downstream
LSP section. Is this entity what you call routing process in step 4 of
section 4.4. Is this entity responsible for intercepting LABEL_REQUEST
and PATH (as well as other CR-LDP and RSVP) messages at ABRs.
<P>3. About crankback. It is stated that crankback is to the previous nearest
ABR from the point of failure. At that ABR the routing algorithm by routing
process is repeated.&nbsp; Is there any mechanism that prevents the selection
of the same ABR as was used previously. For example, refering to the following
example
<P><TT>Area 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Area 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Area 2</TT>
<BR><TT>--------------------&nbsp;&nbsp;&nbsp; ------------------&nbsp;&nbsp;&nbsp;&nbsp;
------------------------</TT>
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</TT>
<BR><TT>|&nbsp; |N1&nbsp; PPS1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -------&nbsp;&nbsp;&nbsp;
PPS3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; --------&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
PPS5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |N2&nbsp;&nbsp; |</TT>
<BR><TT>|&nbsp; |-------------- |ABR1&nbsp; |--------------|ABR 2 |--------X-------|&nbsp;&nbsp;&nbsp;&nbsp;
|</TT>
<BR><TT>|&nbsp; |-------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -------&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
-------- --|PPS7 |------|&nbsp;&nbsp;&nbsp;&nbsp; |</TT>
<BR><TT>|&nbsp;&nbsp; PSS2&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
-------&nbsp;&nbsp;&nbsp; PSS4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; --------&nbsp;&nbsp;
|-----| PSS6&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</TT>
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; --------|ABR
3 |--------------|ABR 4&nbsp; |---------&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</TT>
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
-------&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
--------&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</TT>
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</TT>
<BR><TT>--------------------&nbsp;&nbsp;&nbsp; -------------------&nbsp;&nbsp;&nbsp;
-------------------------</TT>
<P>Let's assume PPS5 failed and we initially cranked back to ABR 2 but
there was no intra-area route to the destination so we cranked back to
ABR1. At ABR1 when performing the algorithm of section 4.4 we should not
consider ABR2 as this is from where we cranked back and we know that ABR2
already tried unsuccessfully to route to the destination.
<P>Also, routing in response to crankback really depends on whether the
failure causing the crankback was within the current area or another downstream
area. If it was within the current area then same downstream ABR can be
selected. If it was outside of the current area then a different ABR should
be selected. For example, if PPS5 fails and we crank back to ABR2 then
to ABR1 (as I eluded to above) then ABR2 should not be considered when
routing at ABR1. On the other hand, if PPS3 fails and we crank back to
ABR1 then ABR2 should be considered.
<P>4. Have you given some thought to the idea that an LSP section failure
in one area should not have an effect on surrounding LSP sections in other
areas. For example, refering to the above picture, if PPS3 fails then another
intra-area route through Area 0 between ABR1 and ABR2 is computed and LSP
section reestablished along that route without affecting LSP sections PPS1
and PPS5. This would be similar to "local repair" where local = area.
<P>Cheers,
<P>Darek
<BR>&nbsp;
<BR>&nbsp;
<BR>&nbsp;</HTML>

--------------FD271251B4C8C858E81F3A0D--



From owner-mpls@UU.NET  Mon Aug 21 05:44:11 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28715
	for <mpls-archive@lists.ietf.org>; Mon, 21 Aug 2000 05:44:11 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdek05430;
	Mon, 21 Aug 2000 09:43:56 GMT
Received: by mail-control.mail.uu.net 
	id QQjdek23471
	for mpls-outgoing; Mon, 21 Aug 2000 09:43:24 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjdek23458
	for <mpls@mail-control.mail.uu.net>; Mon, 21 Aug 2000 09:43:08 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjdek15714;
	Mon, 21 Aug 2000 05:42:51 -0400 (EDT)
Received: from coltrane.datcon.co.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtp.datcon.co.uk [192.91.191.4])
	id QQjdek04736;
	Mon, 21 Aug 2000 09:42:35 GMT
Received: by smtp.datcon.co.uk with Internet Mail Service (5.5.2650.21)
	id <R19M74Y6>; Mon, 21 Aug 2000 10:42:34 +0100
Message-ID: <6DEA508A9A0ED31192E80000F6CC176E2C9F46@monk.datcon.co.uk>
From: Adrian Farrel <AF@datcon.co.uk>
To: te-wg@UU.NET
Cc: mpls@UU.NET
Subject: RE: consensus to make draft-kompella-mpls-te-mib-00.txt a TEWG it
	 em?
Date: Mon, 21 Aug 2000 10:42:13 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

My $0.02 on this...

>> So, with that said - I'd like to see what the consensus of 
>> the list is.
>> 
>> Should Kireeti's draft
>> a) be accepted as a TE WG item at this time?
>> b) not be accepted as a TE WG item at this time?

I believe that this should NOT move forward as a tewg item at this time.

I suggest that it could be the role of the tewg to
- produce a TE MIB that is independent of MPLS
- produce a set of requirements on the MPLS TE MIB and
  request (insist?) that the mplswg incorporate them

I suggest that it is the role of the mplswg to
- produce a fully functional MIB (set of MIBs) that
  can be used to configure, manage and observe an MPLS
  TE network
- take input from implementers, operators and those
  with particular TE experience 

Having had considerable experience with the mplswg MIBs
I feel that there _is_ considerable overlap between the
MIBs and that much of what Kireeti shows in his MIB can
be found in the mplswg MIB.  On the other hand, there are
other functions that are "new" in Kireeti's MIB that would
be of value in the mplswg MIBs, and my view is that the
authors of the mplswg MIBs must incorporate them.

I cannot understand why it would not be a valuable use of
the conformance statement and conformance units to produce
a single combined MIB where the function of Kireeti's MIB
can be achieved by legally supporting just a subset of the
objects in the mplswg MIBs.

Would the authors (on both sides) like to comment on whether 
this is feasible, or indeed whether they have already started
discussions on this topic?

Regards,
Adrian
--
Adrian Farrel  mailto:af@datcon.co.uk
Network Convergence Group
Data Connection Ltd., Chester, UK
http://www.datcon.co.uk/
Tel: +44 (0) 1244 313440  Fax: +44 (0) 1244 312422



From owner-mpls@UU.NET  Mon Aug 21 09:02:54 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00281
	for <mpls-archive@lists.ietf.org>; Mon, 21 Aug 2000 09:02:54 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdey17138;
	Mon, 21 Aug 2000 13:02:18 GMT
Received: by mail-control.mail.uu.net 
	id QQjdey16658
	for mpls-outgoing; Mon, 21 Aug 2000 13:02:01 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjdey16180
	for <mpls@mail-control.mail.uu.net>; Mon, 21 Aug 2000 13:01:51 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjdey27307
	for <mpls@uu.net>; Mon, 21 Aug 2000 09:01:45 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjdey16720
	for <mpls@uu.net>; Mon, 21 Aug 2000 13:01:44 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA09744
	for mpls@uu.net; Mon, 21 Aug 2000 09:01:44 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjdey13844
	for <mpls@mail-control.mail.uu.net>; Mon, 21 Aug 2000 13:01:12 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjdey27250;
	Mon, 21 Aug 2000 09:01:07 -0400 (EDT)
Received: from funnel.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQjdey16382;
	Mon, 21 Aug 2000 13:01:07 GMT
Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.131.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA17647; Mon, 21 Aug 2000 09:01:07 -0400 (EDT)
Received: from tnadeau-pc02.cisco.com ([161.44.204.102])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AAJ24608;
	Mon, 21 Aug 2000 09:01:03 -0400 (EDT)
Message-Id: <4.3.2.7.2.20000821083739.04ddc810@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 21 Aug 2000 08:39:46 -0400
To: Adrian Farrel <AF@datcon.co.uk>, te-wg@UU.NET
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Subject: RE: consensus to make draft-kompella-mpls-te-mib-00.txt a TEWG
  it em?
Cc: mpls@UU.NET
In-Reply-To: <6DEA508A9A0ED31192E80000F6CC176E2C9F46@monk.datcon.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk


         Adrian,

>Would the authors (on both sides) like to comment on whether
>this is feasible, or indeed whether they have already started
>discussions on this topic?

         This is totally feasible, and in our (MPLS-TE-MIB co-authors)
view is the best choice. It accommodates both camps of people without
ignoring either. This is the option that we have advocated
since Kireeti presented his MIB in Pittsburgh.

         --Tom




From owner-mpls@UU.NET  Mon Aug 21 09:13:38 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00375
	for <mpls-archive@lists.ietf.org>; Mon, 21 Aug 2000 09:13:37 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdey25144;
	Mon, 21 Aug 2000 13:13:20 GMT
Received: by mail-control.mail.uu.net 
	id QQjdey22719
	for mpls-outgoing; Mon, 21 Aug 2000 13:12:42 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjdey22703
	for <mpls@mail-control.mail.uu.net>; Mon, 21 Aug 2000 13:12:30 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjdey29006
	for <mpls@UU.NET>; Mon, 21 Aug 2000 09:12:21 -0400 (EDT)
Received: from smtprch2.nortel.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtprch2.nortelnetworks.com [192.135.215.15])
	id QQjdey24480
	for <mpls@UU.NET>; Mon, 21 Aug 2000 13:12:20 GMT
Received: from zrchb213.us.nortel.com (actually zrchb213) 
          by smtprch2.nortel.com; Mon, 21 Aug 2000 08:04:38 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <QYZF741S>; Mon, 21 Aug 2000 08:08:08 -0500
Message-ID: <B7F2E7B20E27D41196910000F8BDCBD6010BCD5E@zmerd009.ca.nortel.com>
From: "Ajay Malik" <malika@nortelnetworks.com>
To: "'Ramanjaneyulu Y T'" <ytr@csa.iisc.ernet.in>,
        Harish Belur <hbelur@cisco.com>
Cc: mpls@UU.NET
Subject: RE: MPLS & Ethernet
Date: Mon, 21 Aug 2000 08:07:57 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C00B70.D3441130"
X-Orig: <malika@americasm01.nt.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

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_01C00B70.D3441130
Content-Type: text/plain;
	charset="iso-8859-1"


please tell me what is the draft name for 
Improving Topology Database Accuracy with LSP Feedback via CR-LDP ?

-----Original Message-----
From: Ramanjaneyulu Y T [mailto:ytr@csa.iisc.ernet.in]
Sent: Sunday, August 20, 2000 11:53 PM
To: Harish Belur
Cc: mpls@UU.NET
Subject: Re: MPLS & Ethernet


Hi,  


   Please refer draft-ietf-mpls-label-encaps-08.txt for all details.

                                         
                                         Regards
                                        Ramanjaneyulu Y.T. 
 

On Sun, 20 Aug 2000, Harish Belur wrote:

> Hi,
> 
> I apologize if this has been asked and answered on this list since I am
new
> to this list.
> How is MPLS expected to work on technologies like ethernet which have a
> specific MTU ? What is the specified behavior if the packet exceeds MTU
size
> once a label (or stack of labels) has been added to the packet ?
> 
> Thanks,
> 
> Harish
> 
> 


------_=_NextPart_001_01C00B70.D3441130
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: MPLS &amp; Ethernet</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2>please tell me what is the draft name for </FONT>
<BR><FONT SIZE=3D2>Improving Topology Database Accuracy with LSP =
Feedback via CR-LDP ?</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Ramanjaneyulu Y T [<A =
HREF=3D"mailto:ytr@csa.iisc.ernet.in">mailto:ytr@csa.iisc.ernet.in</A>]<=
/FONT>
<BR><FONT SIZE=3D2>Sent: Sunday, August 20, 2000 11:53 PM</FONT>
<BR><FONT SIZE=3D2>To: Harish Belur</FONT>
<BR><FONT SIZE=3D2>Cc: mpls@UU.NET</FONT>
<BR><FONT SIZE=3D2>Subject: Re: MPLS &amp; Ethernet</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Hi,&nbsp; </FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&nbsp;&nbsp; Please refer =
draft-ietf-mpls-label-encaps-08.txt for all details.</FONT>
</P>

<P><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Regards</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; Ramanjaneyulu Y.T. </FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
</P>

<P><FONT SIZE=3D2>On Sun, 20 Aug 2000, Harish Belur wrote:</FONT>
</P>

<P><FONT SIZE=3D2>&gt; Hi,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I apologize if this has been asked and answered =
on this list since I am new</FONT>
<BR><FONT SIZE=3D2>&gt; to this list.</FONT>
<BR><FONT SIZE=3D2>&gt; How is MPLS expected to work on technologies =
like ethernet which have a</FONT>
<BR><FONT SIZE=3D2>&gt; specific MTU ? What is the specified behavior =
if the packet exceeds MTU size</FONT>
<BR><FONT SIZE=3D2>&gt; once a label (or stack of labels) has been =
added to the packet ?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Thanks,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Harish</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C00B70.D3441130--


From owner-mpls@UU.NET  Mon Aug 21 09:25:31 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00464
	for <mpls-archive@lists.ietf.org>; Mon, 21 Aug 2000 09:25:30 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdez03493;
	Mon, 21 Aug 2000 13:25:21 GMT
Received: by mail-control.mail.uu.net 
	id QQjdez23547
	for mpls-outgoing; Mon, 21 Aug 2000 13:25:03 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjdez23528
	for <mpls@mail-control.mail.uu.net>; Mon, 21 Aug 2000 13:24:54 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjdez01046
	for <mpls@uu.net>; Mon, 21 Aug 2000 09:24:52 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjdez03066
	for <mpls@uu.net>; Mon, 21 Aug 2000 13:24:51 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA13009
	for mpls@uu.net; Mon, 21 Aug 2000 09:24:51 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjdez23508
	for <mpls@mail-control.mail.uu.net>; Mon, 21 Aug 2000 13:24:31 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjdez00990;
	Mon, 21 Aug 2000 09:24:27 -0400 (EDT)
From: Spencer.Giacalone@predictive.com
Received: from athena.predictive.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: athena.predictive.com [208.209.197.197])
	id QQjdez09556;
	Mon, 21 Aug 2000 13:24:27 GMT
To: Kireeti Kompella <kireeti@juniper.net>
Cc: jboyle@Level3.net, mpls@UU.NET, owner-te-wg@UU.NET, te-wg@UU.NET
Subject: Re: consensus to make draft-kompella-mpls-te-mib-00.txt a TEWG item?
X-Mailer: Lotus Notes Release 5.0.2c (Intl) 2 February 2000
Message-ID: <OFAE741E38.875C5378-ON85256942.00490403@predictive.com>
Date: Mon, 21 Aug 2000 09:24:55 -0400
X-MIMETrack: Serialize by Router on Athena/Predictive(Release 5.0.4a |July 24, 2000) at
 08/21/2000 09:26:25 AM,
	Serialize complete at 08/21/2000 09:26:25 AM
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-mpls@UU.NET
Precedence: bulk

My opinion is that we should merge the MIBs into a single draft so that 
the operators can manage things "now". Obviously, this also gets us out 
the duplicate MIB issue. 

We can work on the new (combined) draft to add whatever we want- that's 
what the draft process is for. We shouldn't _only_ be looking at what 
operators wish for/need/want/ for the moment. 

If the MIB gets to out of hand in the future (big), well, that's why we 
have compliance statements. 

Wouldn't this solution address both side's concerns? Merging salient 
objects seems like an easy and obvious solution. 

Yes, I have seen Randy's posts regarding union/intersection, etc,etc. 

As far as the Juniper bashing goes, (you/we know who you are) you might 
want to go back and read the thread; several operators _have_ been 
posting.. I find it hard to believe all these shops only run Juniper (I 
could be wrong) yet, they still like the Kireeti MIB.  go figure. 

-Spence





Kireeti Kompella <kireeti@juniper.net>
Sent by: owner-te-wg@UU.NET
08/19/00 07:20 PM

 
        To:     jboyle@Level3.net, te-wg@UU.NET
        cc:     mpls@UU.NET
        Subject:        Re: consensus to make draft-kompella-mpls-te-mib-00.txt a TEWG item?


Hi,

Reading through the vigorous debate in response to Jim's mail (thanks,
Jim!), especially Randy's, Vijay's and other service providers' input,
a thought crystallized; and I have a suggestion.

Let me cut to the chase:

***  Rename draft-ietf-mpls-te-mib      ***
***  to     draft-ietf-mpls-tunnel-mib  ***

There will be those who reject the above out-of-hand.  The rest
may care to read on and see if the following makes sense.

------------------

1) te-mib = Traffic Engineering MIB

Traffic Engineering is the mapping of traffic to traffic trunks
(see RFC 2702) for the purpose of performance optimization of
networks.  Vital to this is the routing of the traffic trunks; an
important component is the use of constraints and constraint-based
routing to this end.  Pragmatism (and RFC 2702) also dictates that
there be alternative paths for a trunk (read: primary/secondary paths).

Therefore, it would seem logical for a TE MIB to offer means to view:

a) administrative group information;
b) constraints on traffic trunks;
c) the means by which constraint information was obtained;
d) the results of constraint-based routing (EROs).

Furthermore, since trunk routing is important:

e) stats on how often trunks were re-routed (and the last time this
   happened).

From the T in TE:

f) stats on packet and octet counts through a traffic trunk.

Finally, since the objective of TE is to "optimize the network":

g) how much time a trunk used its primary path (more optimal) vs.
h) how much time a trunk used a secondary path (less optimal) vs.
i) how much time a trunk was down.

Of all of the above, the "mpls-tunnel-mib" only provides the ERO.
The "te-mib" provides all of the above.  There may be other info that
is TE-related that one or the other MIB provides, or that neither
does; however, that is for the TE WG to determine and recommend.

Action item: replace all occurences of "mplsLsp..." in the "Kireeti"
TE MIB with "trafficTrunk...".

-------------------

2) MPLS Tunnel MIB = Tunnel + MPLS

The excellently written "mpls-tunnel-mib" doesn't once mention
traffic engineering in its "features list" (section 4) or its
outline (section 5), except in naming the MIB.  These two
sections focus exclusively on tunnels, as does the entire MIB.

Furthermore, the MIB does a good job of deconstructing tunnels
into their constituent components (segments), and offers the
flexibility of defining
   a) point-to-point tunnels;
   b) multipoint-to-point tunnels;
   c) point-to-multipoint tunnels;

and of defining tunnel properties, such as whether or not they
are interfaces, fast-reroute, merging-permitted, ...

So, this is very much a tunnel MIB.

Moreover, the MIB offers (through close interaction with the LSR
MIB) the labels in and labels out information -- hence very much
an MPLS MIB.

The above information, while largely irrelevant to Traffic
Engineering, is vital indeed (as witness the large following the
MIB has).  The two years of work that has gone into this MIB have
been well spent.

---------------------

3) The argument to incorporate the TE MIB into the MPLS Tunnel MIB
   because MPLS tunnels can be used to do TE extends naturally to:
   incorporate the Diff-Serv MIB into the MPLS Tunnel MIB because
   MPLS tunnels can be used very effectively to do Diff Serv (RFC
   2430 and draft-ietf-mpls-diff-ext); and (in its ludicrous extreme)
   to fold in the interface MIB since MPLS tunnels can be interfaces.

This argument is best put to rest.

Kireeti.





From owner-mpls@UU.NET  Mon Aug 21 09:51:04 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00778
	for <mpls-archive@lists.ietf.org>; Mon, 21 Aug 2000 09:51:03 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdfb21271;
	Mon, 21 Aug 2000 13:50:56 GMT
Received: by mail-control.mail.uu.net 
	id QQjdfb25157
	for mpls-outgoing; Mon, 21 Aug 2000 13:50:31 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjdfb25150
	for <mpls@mail-control.mail.uu.net>; Mon, 21 Aug 2000 13:50:25 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjdfb13488
	for <mpls@UU.net>; Mon, 21 Aug 2000 09:50:10 -0400 (EDT)
Received: from snickers.cs.umd.edu by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: snickers.cs.umd.edu [128.8.126.109])
	id QQjdfb20342
	for <mpls@UU.net>; Mon, 21 Aug 2000 13:49:55 GMT
Received: from localhost (localhost [127.0.0.1])
	by snickers.cs.umd.edu (8.9.3/8.9.1) with ESMTP id JAA15238;
	Mon, 21 Aug 2000 09:49:13 -0400 (EDT)
Date: Mon, 21 Aug 2000 09:49:13 -0400 (EDT)
From: Rob Jaeger <rfj@cs.umd.edu>
To: Ajay Malik <malika@nortelnetworks.com>
cc: "'Ramanjaneyulu Y T'" <ytr@csa.iisc.ernet.in>,
        Harish Belur <hbelur@cisco.com>, mpls@UU.NET
Subject: RE: MPLS & Ethernet
In-Reply-To: <B7F2E7B20E27D41196910000F8BDCBD6010BCD5E@zmerd009.ca.nortel.com>
Message-ID: <Pine.SOL.4.21.0008210944160.15235-100000@snickers.cs.umd.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk


try going to www.ietf.org, internet drafts, I-D Keyword Search, which will
take you to:

   http://search.ietf.org/search/brokers/internet-drafts/query.html

and type in the text box entitled "query":  accuracy feedback 

the result is what you are looking for

Rob
---
Rob Jaeger
University of Maryland
College Park, MD 20742


On Mon, 21 Aug 2000, Ajay Malik wrote:

> 
> please tell me what is the draft name for 
> Improving Topology Database Accuracy with LSP Feedback via CR-LDP ?
> 
> -----Original Message-----
> From: Ramanjaneyulu Y T [mailto:ytr@csa.iisc.ernet.in]
> Sent: Sunday, August 20, 2000 11:53 PM
> To: Harish Belur
> Cc: mpls@UU.NET
> Subject: Re: MPLS & Ethernet
> 
> 
> Hi,  
> 
> 
>    Please refer draft-ietf-mpls-label-encaps-08.txt for all details.
> 
>                                          
>                                          Regards
>                                         Ramanjaneyulu Y.T. 
>  
> 
> On Sun, 20 Aug 2000, Harish Belur wrote:
> 
> > Hi,
> > 
> > I apologize if this has been asked and answered on this list since I am
> new
> > to this list.
> > How is MPLS expected to work on technologies like ethernet which have a
> > specific MTU ? What is the specified behavior if the packet exceeds MTU
> size
> > once a label (or stack of labels) has been added to the packet ?
> > 
> > Thanks,
> > 
> > Harish
> > 
> > 
> 
> 



From owner-mpls@UU.NET  Mon Aug 21 09:51:06 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00788
	for <mpls-archive@lists.ietf.org>; Mon, 21 Aug 2000 09:51:05 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdfb27626;
	Mon, 21 Aug 2000 13:50:55 GMT
Received: by mail-control.mail.uu.net 
	id QQjdfb25148
	for mpls-outgoing; Mon, 21 Aug 2000 13:50:23 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjdfb25143
	for <mpls@mail-control.mail.uu.net>; Mon, 21 Aug 2000 13:50:14 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjdfb05526
	for <mpls@UU.NET>; Mon, 21 Aug 2000 09:50:11 -0400 (EDT)
Received: from mail01.gmu.edu by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail01.gmu.edu [129.174.0.6])
	id QQjdfb20609
	for <mpls@UU.NET>; Mon, 21 Aug 2000 13:50:10 GMT
Received: from thinkpad ([129.174.247.2]) by mail01.gmu.edu
          (Netscape Messaging Server 4.1) with ESMTP id FZNAFL00.KCN; Mon,
          21 Aug 2000 09:50:09 -0400 
Message-ID: <003f01c00b76$ac419700$dcfe1ac7@gmu.edu>
From: "Lichung Chang" <lchang4@gmu.edu>
To: "Ajay Malik" <malika@nortelnetworks.com>
Cc: <mpls@UU.NET>
References: <B7F2E7B20E27D41196910000F8BDCBD6010BCD5E@zmerd009.ca.nortel.com>
Subject: Re: MPLS & Ethernet
Date: Mon, 21 Aug 2000 09:49:48 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_003C_01C00B55.24A20EE0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_003C_01C00B55.24A20EE0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

RE: MPLS & EthernetAjay,

>please tell me what is the draft name for=20
>Improving Topology Database Accuracy with LSP Feedback via CR-LDP ?

It's draft-ietf-mpls-te-feed-01.txt.

Lichung

------=_NextPart_000_003C_01C00B55.24A20EE0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE: MPLS & Ethernet</TITLE>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2614.3500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>Ajay,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2><FONT size=3D2>&gt;please tell me what is the draft =
name for=20
</FONT><BR><FONT size=3D2>&gt;Improving Topology Database Accuracy with =
LSP=20
Feedback via CR-LDP ?</FONT></FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>It's draft-ietf-mpls-te-feed-01.txt.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>Lichung</FONT></DIV></BODY></HTML>

------=_NextPart_000_003C_01C00B55.24A20EE0--



From owner-mpls@UU.NET  Mon Aug 21 10:26:05 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01414
	for <mpls-archive@lists.ietf.org>; Mon, 21 Aug 2000 10:26:05 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdfd23030;
	Mon, 21 Aug 2000 14:25:58 GMT
Received: by mail-control.mail.uu.net 
	id QQjdfd09538
	for mpls-outgoing; Mon, 21 Aug 2000 14:25:24 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjdfd09523
	for <mpls@mail-control.mail.uu.net>; Mon, 21 Aug 2000 14:25:03 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjdfd19610
	for <mpls@uu.net>; Mon, 21 Aug 2000 10:24:48 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjdfd22196
	for <mpls@uu.net>; Mon, 21 Aug 2000 14:24:48 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA21474
	for mpls@uu.net; Mon, 21 Aug 2000 10:24:47 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjdfd09466
	for <mpls@mail-control.mail.uu.net>; Mon, 21 Aug 2000 14:24:08 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjdfd12413;
	Mon, 21 Aug 2000 10:23:57 -0400 (EDT)
Received: from brixcorp2.brixnet.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: brixcorp2.brixnet.com [216.91.233.5])
	id QQjdfd14555;
	Mon, 21 Aug 2000 14:23:57 GMT
Received: by brixcorp2.brixnet.com with Internet Mail Service (5.5.2650.21)
	id <QAT4TMH9>; Mon, 21 Aug 2000 10:23:56 -0400
Message-ID: <07B0D4912B83D31188F300A0C9F62EBB2AEDE9@brixcorp2.brixnet.com>
From: "Cucchiara, Joan" <JCucchiara@Brixnet.com>
To: "'Adrian Farrel'" <AF@datcon.co.uk>, te-wg@UU.NET
Cc: mpls@UU.NET
Subject: RE: consensus to make draft-kompella-mpls-te-mib-00.txt a TEWG it
	 em?
Date: Mon, 21 Aug 2000 10:23:56 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk



> -----Original Message-----
> From: Adrian Farrel [mailto:AF@datcon.co.uk]
> Sent: Monday, August 21, 2000 5:42 AM
> To: te-wg@UU.NET
> Cc: mpls@UU.NET
> Subject: RE: consensus to make 
> draft-kompella-mpls-te-mib-00.txt a TEWG
> it em?
> 
> 
> My $0.02 on this...
> 
> >> So, with that said - I'd like to see what the consensus of 
> >> the list is.
> >> 
> >> Should Kireeti's draft
> >> a) be accepted as a TE WG item at this time?
> >> b) not be accepted as a TE WG item at this time?
> 
> I believe that this should NOT move forward as a tewg item at 
> this time.
> 
> I suggest that it could be the role of the tewg to
> - produce a TE MIB that is independent of MPLS
> - produce a set of requirements on the MPLS TE MIB and
>   request (insist?) that the mplswg incorporate them
> 
> I suggest that it is the role of the mplswg to
> - produce a fully functional MIB (set of MIBs) that
>   can be used to configure, manage and observe an MPLS
>   TE network
> - take input from implementers, operators and those
>   with particular TE experience 
> 
> Having had considerable experience with the mplswg MIBs
> I feel that there _is_ considerable overlap between the
> MIBs and that much of what Kireeti shows in his MIB can
> be found in the mplswg MIB.  On the other hand, there are
> other functions that are "new" in Kireeti's MIB that would
> be of value in the mplswg MIBs, and my view is that the
> authors of the mplswg MIBs must incorporate them.
> 
> I cannot understand why it would not be a valuable use of
> the conformance statement and conformance units to produce
> a single combined MIB where the function of Kireeti's MIB
> can be achieved by legally supporting just a subset of the
> objects in the mplswg MIBs.

I would like to understand what exactly is being
proposed here.

Are you proposing that by using conformance statements the MPLS-TE
MIB (draft-ietf-mpls-te-mib) produce a minimal set of requirements
which is essentially the objects contained in draft-kompella-te-mib?

If so, I'd like to raise a few concerns.  Assuming this could
be done (and I'm not convinced that it could) but for the
sake of argument, assuming that it is achievable:

1) that's not the purpose of conformance statements, so think
you'd be making MIB history here ;)   

2) These conformance statements would be extremely complex.  Right
now, one encounters conformance statements dealing largely with
physical issues, such as "The xxxATM Group needs to be supported
on devices which support one or more ATM interfaces".  
I can't imagine what you would base these
conformance statements on, such that someone a year from now
would be able to read them and understand what is being asked.

3) if the LSR MIB is effected because of this (and I believe that it
would be since the MPLS-TE MIB has quite a bit of dependence
on the LSR MIB) then what does this mean for the LSR MIB.  Does this
suggestion also extend to the LSR MIB, and thus, the LSR MIB's conformance
statements would need rewriting also?  Since the LSR MIB has
already had a couple of last calls, is it even possible
to go back and make changes to the LSR MIB?

4) the LDP MIB has a dependence on the LSR MIB, so I would like to
understand what is involved in rewriting conformance statements in
this way, and what the effects are on the MPLS-TE MIB and LSR MIB, 
prior to just accepting this solution at face value. 

5) Typically, when there are optional objects, these don't get
implemented.  What is the motivation for implementing them?  (there
is none to speak of because minimal compliance to a standard RFC is
compliance.)  If you end up making much of the MPLS-TE MIB optional
just to obtain a draft-kompella-mpls-te-mib, I think this is a complete
waste of time and energy, so again, I would like to understand how
this is going to be done, and what the consequences are prior to agreeing
to this course of action.

On the surface rewriting comformance statements may seem like a 
good compromise, but I have doubts about the feasibility of this
as a solution.  Could the authors speak to some of the issues above
so that we could get a clear understanding of what this would involve?

  Thanks, Joan

> 
> Would the authors (on both sides) like to comment on whether 
> this is feasible, or indeed whether they have already started
> discussions on this topic?
> 
> Regards,
> Adrian
> --
> Adrian Farrel  mailto:af@datcon.co.uk
> Network Convergence Group
> Data Connection Ltd., Chester, UK
> http://www.datcon.co.uk/
> Tel: +44 (0) 1244 313440  Fax: +44 (0) 1244 312422
> 



From owner-mpls@UU.NET  Mon Aug 21 10:40:01 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01641
	for <mpls-archive@lists.ietf.org>; Mon, 21 Aug 2000 10:40:01 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdfe26726;
	Mon, 21 Aug 2000 14:39:57 GMT
Received: by mail-control.mail.uu.net 
	id QQjdfe10436
	for mpls-outgoing; Mon, 21 Aug 2000 14:39:32 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjdfe10431
	for <mpls@mail-control.mail.uu.net>; Mon, 21 Aug 2000 14:39:30 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjdfe22186
	for <mpls@uu.net>; Mon, 21 Aug 2000 10:39:10 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjdfe02413
	for <mpls@uu.net>; Mon, 21 Aug 2000 14:39:09 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA23651
	for mpls@uu.net; Mon, 21 Aug 2000 10:39:09 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjdfe10406
	for <mpls@mail-control.mail.uu.net>; Mon, 21 Aug 2000 14:38:47 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjdfe22060
	for <mpls@uu.net>; Mon, 21 Aug 2000 10:38:38 -0400 (EDT)
Received: from procyon.pmc-sierra.bc.ca by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1])
	id QQjdfe25278
	for <mpls@uu.net>; Mon, 21 Aug 2000 14:38:18 GMT
Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183])
	by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id HAA05046;
	Mon, 21 Aug 2000 07:37:41 -0700 (PDT)
Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21)
	id <QPVGR3Y6>; Mon, 21 Aug 2000 07:40:45 -0700
Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B4073A@nt-exchange-bby.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'Vishal M'" <vishal_study@yahoo.com>,
        Shahram Davari
	 <Shahram_Davari@pmc-sierra.com>
Cc: mpls@UU.NET
Subject: RE: LSP setup time and delay
Date: Mon, 21 Aug 2000 07:40:32 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Vishal,

>-----Original Message-----
>From: Vishal M [mailto:vishal_study@yahoo.com]
>Sent: Saturday, August 19, 2000 4:20 AM
>To: Shahram Davari
>Cc: mpls@uu.net; vishal_study@yahoo.com
>Subject: RE: LSP setup time and delay
>
>
>
>Hi,
>
>Thanks for the clarifications. One more related
>question:
>
>In the MPLS network, the LSRs exchange the 
>OSPF TE LSAs containing bandwidth availability 
>information etc.
>
>Now if the resource avail changes and it calls for a 
>new TE LSP, would this change (i.e. new LSP 
>establishment) happen automatically or would it be
>data-driven. 
>

If the links characteristics (such as available BW) change and this change
is propagated via  OSPF, then there are two cases:

1) Already established LSPs: it is up to the network policy to decide
whether to re-route them to new path or to keep them as they are.
2) New LSPs: For new LSP requests the LER will use the latest LSA
information to compute the path.


>i.e. if the OSPF Routing Plane gets a new TE 
>LSA, it could handle it in following ways:
>
>a. Routing plane runs the SPF calculation
>   on receipt of every TE LSA and informs the MPLS 
>   Signalling Plane of this change.
>
>   If we follow (a), it could mean:
>   - more SPF calculations and more computation
>     overhead on the LSRs.


For a limited well known constraints, an LER could compute the best path
continuously, based on the latest LSA information. The result could be used
for new LSP requests or for re-routing the old LSPs. This technique is
called "off-line" computation, and as you said is computationally expensive,
because many of the computed routes won't be used at all, but the advantage
is that they are readily available with minimum delay. 

>
>b. Routing Plane waits for the Signaling
>   Plane to trigger a request for a new explicit 
>   path. Once requested, Routing Plane runs the
>   SPF algo, calculates new routes and gives it
>   back to the Signalling Plane. i.e. the SPF 
>   calculation is data-driven.
>
>   If we follow (b), it could lead to
>   - LSPs based on out-dated resource info
>   - delays (as mentioned in the original ques).


This method is called "on-line" computation and its problem is the delay as
you mentioned it (but not out-dated info). Its advantage is being
computationally cheaper.

>
>Which approach is preferred and why ?
>
>As far as I remember reading on this, approach (b) 
>is preferred. But, if that is correct, it contradicts
>with our current discussion (that LSP setup is _not_
>data-driven).


I think you are confusing a few things. There are two steps in TE:

1) Computing the path
2) Establishing the LSP

As I said we have two methods to compute the path: 

- on-line
- off-line

But we have 3 methods to establish the LSP:

- data driven: LSP setup is triggered by an arriving packet
- control driven: LSP setup is triggered by signaling requests
- topology/policy driven: LSP setup is triggered by network itself based on
some predefined rules. In this case the LSP is ready before any request or
packet arrives.


Which approach is preferred, depends on the network, the SLAs and the
policies involved. All these methods could be used to tailor it out to your
own situation.

Regards,
-Shahram
  
>
>Am I missing something...
>
>Could you please throw some pointers...
>
>Thanks,
>Vishal.
>
>PS: I apologize if you receive multiple copies
>of this mail. I sent this before, but didn't see
>this on the mailing list.
> 
>
>--- Shahram Davari <Shahram_Davari@pmc-sierra.com>
>wrote:
>> Hi Vishal,
>> 
>> >-----Original Message-----
>> >From: Vishal M [mailto:vishal_study@yahoo.com]
>> >Sent: Friday, August 18, 2000 2:11 PM
>> >To: Shahram Davari; 'Tim.Cook@go.ecitele.com'
>> >Cc: 'Vishal M'; mpls@UU.NET
>> >Subject: RE: LSP setup time and delay
>> >
>> >
>> >
>> >Hi Shahram,
>> >
>> >Thanks for reply. Some more doubts:
>> >
>> >1. If the LSP setup is not data-driven, how
>> >   many LSPs are established on the ingress LSR
>> (LER)
>> >   when LER initializes ?
>> 
>> It depends on the network policy and requests that
>> are signaled. In many
>> cases (such as in a Diffserv network) you probably
>> need at least one LSP per
>> egress LSR.
>> 
>> >
>> >2. Wouldn't this lead to a lot of manual
>> intervention
>> >   in pre-establishing these LSPs ?
>> 
>> Not really. You just need to specify the ingress
>> LSR, the egress LSR, the
>> FEC and the required QoS (such as BW) for the
>> required LSP, and the TE
>> software will find and establish the path for you. 
>>  
>> >
>> >3. What happens if LER gets an IP packet for which
>> >   there is no pre-established LSP (and assuming
>> >   that the IP packet belongs to a mission-critical
>> >   application) ? 
>> >   How do we ensure QoS in this case ? 
>> 
>> If after the packet classification it is found that
>> the packet does not map
>> to any LSP, then this is up to the network policy,
>> it may send it as L3
>> packet or may drop it. It is up to the network
>> provider to assign all
>> required FECs to proper LSPs at the edge.
>> 
>> The best method is for the mission-critical
>> application to signal its
>> required QoS. The network will use this information
>> to establish the
>> required LSP. If such an LSP can't be found then the
>> request will be
>> rejected. In other words admission control is the
>> best method to make sure
>> that the mission-critical packets receive their
>> required QoS.
>> 
>> Regards,
>> -Shahram 
>> 
>> >   
>> >Thanks,
>> >Vishal.
>> >
>> >--- Shahram Davari <Shahram_Davari@pmc-sierra.com>
>> >wrote:
>> >> Tim,
>> >> 
>> >> No. Control packets are L3 forwarded. Also in
>> data
>> >> driven method, the
>> >> packets are initially L3 forwarded and then
>> switched
>> >> to L2 forwarding when
>> >> LSP is setup.
>> >> 
>> >> -Shahram
>> >> 
>> >> >-----Original Message-----
>> >> >From: Tim.Cook@go.ecitele.com
>> >> [mailto:Tim.Cook@go.ecitele.com]
>> >> >Sent: Friday, August 18, 2000 10:49 AM
>> >> >To: Shahram Davari
>> >> >Cc: 'Vishal M'; mpls@UU.NET
>> >> >Subject: RE: LSP setup time and delay
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >Does this mean that there is no L3 forwarding
>> >> between two LSRs 
>> >> >(all traffic
>> >> >is labeled)?
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >Shahram Davari <Shahram_Davari@pmc-sierra.com>
>> on
>> >> 08/18/2000 
>> >> >10:22:40 AM
>> >> >                                                
>>   
>> >>           
>> >> >                                                
>>   
>> >>           
>> >> >                                                
>>   
>> >>           
>> >> > To:      "'Vishal M'" <vishal_study@yahoo.com>,
>> >> mpls@UU.NET  
>> >> >                                                
>>   
>> >>           
>> >> > cc:      (bcc: Tim Cook/Fort Lauderdale/ECI
>> >> Telecom)         
>> >> >                                                
>>   
>> >>           
>> >> >                                                
>>   
>> >>           
>> >> >                                                
>>   
>> >>           
>> >> > Subject: RE: LSP setup time and delay          
>>   
>> >>           
>> >> >                                                
>>   
>> >>           
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >Vishal,
>> >> >
>> >> >What you are describing is called "data driven
>> >> label 
>> >> >assignment". This is
>> >> >explained in framework document, and requires L3
>> >> forwarding 
>> >> >until the LSP
>> >> >is
>> >> >setup. Due to its problems it has not been
>> pursued
>> >> further by MPLS WG
>> >> >(however, some implementations exist). Control
>> >> driven label 
>> >> >assignment is
>> >> >the one most of the people are working on.
>> >> >
>> >> >Regards,
>> >> >-Shahram
>> >> >
>> >> >>-----Original Message-----
>> >> >>From: Vishal M [mailto:vishal_study@yahoo.com]
>> >> >>Sent: Friday, August 18, 2000 4:15 AM
>> >> >>To: mpls@UU.NET
>> >> >>Subject: LSP setup time and delay
>> >> >>
>> >> >>
>> >> >>
>> >> >>Hello,
>> >> >>
>> >> >>Suppose an IP packet is to sent over a MPLS
>> >> network.
>> >> >>As I understand the protocol, different
>> components
>> >> at
>> >> >>the ingres LSR (also called LER) interact in
>> the
>> >> >>following way:
>> >> >>
>> >> >>1. MPLS Signaling Plane (CR-LDP/RSVP) queries
>> the
>> >> >>Routing Plane (IGP Extensions) to get the
>> Explicit
>> >> >>Path to reach the destination (assuming nothing
>> >> >>in the tables initially).
>> >> >>
>> >> >>2. Signaling Plane uses RSVP or CR-LDP to
>> reserve
>> >> >>resources along the explicit path. Label
>> mapping
>> >> >>is performed at the intermediatory LSRs.
>> >> >>
>> >> >>3. After the path is set up i.e. LSP is
>> >> established
>> >> >>from the source to the destination, the
>> incoming
>> 
>=== message truncated ===
>
>
>__________________________________________________
>Do You Yahoo!?
>Send instant messages & get email alerts with Yahoo! Messenger.
>http://im.yahoo.com/
>



From owner-mpls@UU.NET  Mon Aug 21 11:32:29 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02989
	for <mpls-archive@lists.ietf.org>; Mon, 21 Aug 2000 11:32:29 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdfi06770;
	Mon, 21 Aug 2000 15:32:25 GMT
Received: by mail-control.mail.uu.net 
	id QQjdfi25653
	for mpls-outgoing; Mon, 21 Aug 2000 15:32:05 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjdfi25648
	for <mpls@mail-control.mail.uu.net>; Mon, 21 Aug 2000 15:31:54 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjdfi02082
	for <mpls@UU.NET>; Mon, 21 Aug 2000 11:31:14 -0400 (EDT)
Received: from red.juniper.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: natint.juniper.net [207.17.136.129])
	id QQjdfi09787
	for <mpls@UU.NET>; Mon, 21 Aug 2000 15:30:43 GMT
Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90])
	by red.juniper.net (8.9.3/8.9.3) with ESMTP id IAA11620;
	Mon, 21 Aug 2000 08:29:29 -0700 (PDT)
Received: (from kireeti@localhost) by kummer.juniper.net (8.8.7/8.7.3) id IAA17809; Mon, 21 Aug 2000 08:28:50 -0700 (PDT)
Date: Mon, 21 Aug 2000 08:28:50 -0700 (PDT)
From: Kireeti Kompella <kireeti@juniper.net>
Message-Id: <200008211528.IAA17809@kummer.juniper.net>
To: Shahram_Davari@pmc-sierra.com, vishal_study@yahoo.com
Subject: RE: LSP setup time and delay
Cc: mpls@UU.NET
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

>Now if the resource avail changes and it calls for a 
>new TE LSP, would this change (i.e. new LSP 
>establishment) happen automatically or would it be
>data-driven. 
>
>i.e. if the OSPF Routing Plane gets a new TE 
>LSA, it could handle it in following ways:
>
>a. Routing plane runs the SPF calculation
>   on receipt of every TE LSA and informs the MPLS 
>   Signalling Plane of this change.
>
>   If we follow (a), it could mean:
>   - more SPF calculations and more computation
>     overhead on the LSRs.

See section 5.6.4 of RFC 2702.

Especially:

   Stability is a major concern when re-optimization is permitted. To
   promote stability, an MPLS implementation should not be too reactive
   to the evolutionary dynamics of the network.

Kireeti.


From owner-mpls@UU.NET  Mon Aug 21 12:07:53 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03797
	for <mpls-archive@lists.ietf.org>; Mon, 21 Aug 2000 12:07:53 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdfk06588;
	Mon, 21 Aug 2000 16:07:46 GMT
Received: by mail-control.mail.uu.net 
	id QQjdfk09922
	for mpls-outgoing; Mon, 21 Aug 2000 16:07:12 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjdfk09917
	for <mpls@mail-control.mail.uu.net>; Mon, 21 Aug 2000 16:07:05 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjdfk08391
	for <mpls@UU.NET>; Mon, 21 Aug 2000 12:06:54 -0400 (EDT)
Received: from bgslc02.TBG.COM by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [63.99.125.2])
	id QQjdfk05747
	for <mpls@UU.NET>; Mon, 21 Aug 2000 16:06:39 GMT
Received: by BGSLC02 with Internet Mail Service (5.5.2650.21)
	id <P5DAZD8K>; Mon, 21 Aug 2000 09:54:42 -0600
Message-ID: <0C875DC28791D21192CD00104B95BFE7BAE90C@BGSLC02>
From: Irwin Lazar <ILazar@tbg.com>
To: "'Ajay Malik'" <malika@nortelnetworks.com>,
        Harish Belur
	 <hbelur@cisco.com>
Cc: mpls@UU.NET
Subject: RE: MPLS & Ethernet
Date: Mon, 21 Aug 2000 09:54:42 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C00B88.1EA427CA"
Sender: owner-mpls@UU.NET
Precedence: bulk

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_01C00B88.1EA427CA
Content-Type: text/plain;
	charset="iso-8859-1"

Please see http://www.mplsrc.com/drafts.shtml
<http://www.mplsrc.com/drafts.shtml>  for a link to this draft.
 
Irwin

-----Original Message-----
From: Ajay Malik [mailto:malika@nortelnetworks.com]
Sent: Monday, August 21, 2000 9:08 AM
To: 'Ramanjaneyulu Y T'; Harish Belur
Cc: mpls@UU.NET
Subject: RE: MPLS & Ethernet




please tell me what is the draft name for 
Improving Topology Database Accuracy with LSP Feedback via CR-LDP ? 

-----Original Message----- 
From: Ramanjaneyulu Y T [ mailto:ytr@csa.iisc.ernet.in
<mailto:ytr@csa.iisc.ernet.in> ] 
Sent: Sunday, August 20, 2000 11:53 PM 
To: Harish Belur 
Cc: mpls@UU.NET 
Subject: Re: MPLS & Ethernet 


Hi,  


   Please refer draft-ietf-mpls-label-encaps-08.txt for all details. 

                                         
                                         Regards 
                                        Ramanjaneyulu Y.T. 
  

On Sun, 20 Aug 2000, Harish Belur wrote: 

> Hi, 
> 
> I apologize if this has been asked and answered on this list since I am
new 
> to this list. 
> How is MPLS expected to work on technologies like ethernet which have a 
> specific MTU ? What is the specified behavior if the packet exceeds MTU
size 
> once a label (or stack of labels) has been added to the packet ? 
> 
> Thanks, 
> 
> Harish 
> 
> 


------_=_NextPart_001_01C00B88.1EA427CA
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE>RE: MPLS & Ethernet</TITLE>

<META content=3D"MSHTML 5.50.4134.600" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D562500516-21082000><FONT face=3DArial =
color=3D#0000ff size=3D2>Please=20
see <A=20
href=3D"http://www.mplsrc.com/drafts.shtml">http://www.mplsrc.com/drafts=
.shtml</A>=20
for a link to this draft.</FONT></SPAN></DIV>
<DIV><SPAN class=3D562500516-21082000><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D562500516-21082000><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>Irwin</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Ajay Malik=20
  [mailto:malika@nortelnetworks.com]<BR><B>Sent:</B> Monday, August 21, =
2000=20
  9:08 AM<BR><B>To:</B> 'Ramanjaneyulu Y T'; Harish Belur<BR><B>Cc:</B> =

  mpls@UU.NET<BR><B>Subject:</B> RE: MPLS &amp;=20
Ethernet<BR><BR></FONT></DIV><BR>
  <P><FONT size=3D2>please tell me what is the draft name for =
</FONT><BR><FONT=20
  size=3D2>Improving Topology Database Accuracy with LSP Feedback via =
CR-LDP=20
  ?</FONT> </P>
  <P><FONT size=3D2>-----Original Message-----</FONT> <BR><FONT =
size=3D2>From:=20
  Ramanjaneyulu Y T [<A=20
  =
href=3D"mailto:ytr@csa.iisc.ernet.in">mailto:ytr@csa.iisc.ernet.in</A>]<=
/FONT>=20
  <BR><FONT size=3D2>Sent: Sunday, August 20, 2000 11:53 PM</FONT> =
<BR><FONT=20
  size=3D2>To: Harish Belur</FONT> <BR><FONT size=3D2>Cc: =
mpls@UU.NET</FONT>=20
  <BR><FONT size=3D2>Subject: Re: MPLS &amp; Ethernet</FONT> </P><BR>
  <P><FONT size=3D2>Hi,&nbsp; </FONT></P><BR>
  <P><FONT size=3D2>&nbsp;&nbsp; Please refer =
draft-ietf-mpls-label-encaps-08.txt=20
  for all details.</FONT> </P>
  <P><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </FONT><BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  Regards</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  Ramanjaneyulu Y.T. </FONT><BR><FONT size=3D2>&nbsp;</FONT> </P>
  <P><FONT size=3D2>On Sun, 20 Aug 2000, Harish Belur wrote:</FONT> =
</P>
  <P><FONT size=3D2>&gt; Hi,</FONT> <BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
  size=3D2>&gt; I apologize if this has been asked and answered on this =
list since=20
  I am new</FONT> <BR><FONT size=3D2>&gt; to this list.</FONT> =
<BR><FONT=20
  size=3D2>&gt; How is MPLS expected to work on technologies like =
ethernet which=20
  have a</FONT> <BR><FONT size=3D2>&gt; specific MTU ? What is the =
specified=20
  behavior if the packet exceeds MTU size</FONT> <BR><FONT =
size=3D2>&gt; once a=20
  label (or stack of labels) has been added to the packet ?</FONT> =
<BR><FONT=20
  size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; Thanks,</FONT> <BR><FONT =
size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt; Harish</FONT> <BR><FONT size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt; </FONT></P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C00B88.1EA427CA--


From owner-mpls@UU.NET  Mon Aug 21 14:16:52 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06119
	for <mpls-archive@lists.ietf.org>; Mon, 21 Aug 2000 14:16:52 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdft16180;
	Mon, 21 Aug 2000 18:16:46 GMT
Received: by mail-control.mail.uu.net 
	id QQjdft13000
	for mpls-outgoing; Mon, 21 Aug 2000 18:16:16 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjdft12923
	for <mpls@mail-control.mail.uu.net>; Mon, 21 Aug 2000 18:16:04 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjdft00060
	for <mpls@UU.NET>; Mon, 21 Aug 2000 14:15:43 -0400 (EDT)
Received: from lux.chromisys.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: 193.140.adsl6.netlojix.net [207.71.200.140] (may be forged))
	id QQjdft10311
	for <mpls@UU.NET>; Mon, 21 Aug 2000 18:15:28 GMT
Received: by LUX with Internet Mail Service (5.5.2650.21)
	id <RDGLYR6M>; Mon, 21 Aug 2000 11:15:27 -0700
Message-ID: <51DA0AB3D747D311832F005004827CC02CE9E9@LUX>
From: Jonathan Lang <jplang@calient.net>
To: "'Dawkins, Spencer'" <Spencer.DAWKINS@fnc.fujitsu.com>, mpls@UU.NET
Subject: RE: LMP Acronym question
Date: Mon, 21 Aug 2000 11:15:27 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="windows-1252"
Sender: owner-mpls@UU.NET
Precedence: bulk

Spencer,
  I think it makes more sense to keep the reference to the Generalized
signaling draft (draft-ashwood-generalized-mpls-signaling-00.txt) instead of
redefining the terms in the LMP draft.  The wording in Section 3 is really a
brief description of how the info learned from LMP is used in the context of
Generalized signaling.

-Jonathan

> -----Original Message-----
> From: Dawkins, Spencer [mailto:Spencer.DAWKINS@fnc.fujitsu.com]
> Sent: Thursday, August 17, 2000 8:30 AM
> To: mpls@UU.NET
> Subject: LMP Acronym question
> 
> 
> In draft-lang-mpls-lmp-01.txt, section 3.0 makes reference to 
> TDM, LSC, and
> FSC, without defining these terms. I found the definitions in
> draft-ashwood-generalized-mpls-signaling-00.txt - could they be made
> explicit in the LMP draft?
> 
> Spencer
> 


From owner-mpls@UU.NET  Mon Aug 21 14:49:08 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06894
	for <mpls-archive@lists.ietf.org>; Mon, 21 Aug 2000 14:49:07 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdfv03520;
	Mon, 21 Aug 2000 18:48:57 GMT
Received: by mail-control.mail.uu.net 
	id QQjdfv15240
	for mpls-outgoing; Mon, 21 Aug 2000 18:48:37 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjdfv15185
	for <mpls@mail-control.mail.uu.net>; Mon, 21 Aug 2000 18:48:24 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjdfv05946
	for <mpls@UU.NET>; Mon, 21 Aug 2000 14:48:15 -0400 (EDT)
Received: from fortress.fnc.fujitsu.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: fortress.fnc.fujitsu.com [204.253.82.1])
	id QQjdfv02711
	for <mpls@UU.NET>; Mon, 21 Aug 2000 18:47:59 GMT
Received: from rchsemx2.fnc.fujitsu.com (rchsemx2.fnc.fujitsu.com [167.254.105.13]) by fortress.fnc.fujitsu.com (8.8.7/FNC/ITG-2.0.1) with ESMTP id NAA26197 for <mpls@UU.NET>; Mon, 21 Aug 2000 13:47:58 -0500 (CDT)
Received: by rchsemx2.fnc.fujitsu.com with Internet Mail Service (5.5.2650.21)
	id <RFGJYLY6>; Mon, 21 Aug 2000 13:48:00 -0500
Message-ID: <F8B312027514D21197BC0000F81E25A30977C226@fnc03.fnc.fujitsu.com>
From: "Dawkins, Spencer" <Spencer.DAWKINS@fnc.fujitsu.com>
To: mpls@UU.NET
Subject: RE: LMP Acronym question
Date: Mon, 21 Aug 2000 13:47:55 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

I think this may be true, especially if the Generalized Signaling draft and
LMP end up as workgroup products in the same working group (understanding of
the plan for restructuring the Unified Control Plane work). I didn't realize
that these two (individual) submissions were sharing terminology, and then
happened to find the definitions in the Generalized Signaling draft.

Thanks,

Spencer

> -----Original Message-----
> From:	Jonathan Lang [SMTP:jplang@calient.net]
> Sent:	Monday, August 21, 2000 1:15 PM
> To:	'Dawkins, Spencer'; mpls@UU.NET
> Subject:	RE: LMP Acronym question
> 
> Spencer,
>   I think it makes more sense to keep the reference to the Generalized
> signaling draft (draft-ashwood-generalized-mpls-signaling-00.txt) instead
> of
> redefining the terms in the LMP draft.  The wording in Section 3 is really
> a
> brief description of how the info learned from LMP is used in the context
> of
> Generalized signaling.
> 
> -Jonathan
> 
> > -----Original Message-----
> > From: Dawkins, Spencer [mailto:Spencer.DAWKINS@fnc.fujitsu.com]
> > Sent: Thursday, August 17, 2000 8:30 AM
> > To: mpls@UU.NET
> > Subject: LMP Acronym question
> > 
> > 
> > In draft-lang-mpls-lmp-01.txt, section 3.0 makes reference to 
> > TDM, LSC, and
> > FSC, without defining these terms. I found the definitions in
> > draft-ashwood-generalized-mpls-signaling-00.txt - could they be made
> > explicit in the LMP draft?
> > 
> > Spencer
> > 


From owner-mpls@UU.NET  Mon Aug 21 16:39:37 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08974
	for <mpls-archive@lists.ietf.org>; Mon, 21 Aug 2000 16:39:36 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdgc26455;
	Mon, 21 Aug 2000 20:39:30 GMT
Received: by mail-control.mail.uu.net 
	id QQjdgc21319
	for mpls-outgoing; Mon, 21 Aug 2000 20:39:06 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjdgc21308
	for <mpls@mail-control.mail.uu.net>; Mon, 21 Aug 2000 20:39:00 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjdgc26182
	for <mpls@uu.net>; Mon, 21 Aug 2000 16:38:40 -0400 (EDT)
Received: from mps3.leeds.ac.uk by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sunserv5.leeds.ac.uk [129.11.16.35])
	id QQjdgc18699
	for <mpls@uu.net>; Mon, 21 Aug 2000 20:38:24 GMT
Received: from electeng.leeds.ac.uk (electeng.leeds.ac.uk [129.11.178.99])
	by mps3.leeds.ac.uk (8.9.3/8.9.3) with ESMTP id VAA28186
	for <mpls@uu.net>; Mon, 21 Aug 2000 21:38:23 +0100 (BST)
Received: from ELECTENG/SpoolDir by electeng.leeds.ac.uk (Mercury 1.43);
    21 Aug 100 22:08:58 GMT
Received: from SpoolDir by ELECTENG (Mercury 1.43); 21 Aug 100 22:08:31 GMT
Received: from default (129.11.176.219) by electeng.leeds.ac.uk (Mercury 1.40);
    21 Aug 100 22:08:28 GMT
From: "Erickson Trejo-Reyes" <eenet@electeng.leeds.ac.uk>
To: <mpls@UU.NET>
Subject: MPLS and CAC
Date: Mon, 21 Aug 2000 21:39:51 +0100
Message-ID: <01c00baf$f4910160$dbb00b81@default.leeds.ac.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_000A_01C00BB8.56556960"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.71.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_000A_01C00BB8.56556960
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello, I wouldn't like to take too much of your time, but if you can be =
kind enough to answer some questions that I have, I would greatly =
appreciate it. I have some doubts about MPLS.

=20

While reading about MPLS specification (all my previous experience is on =
ATM networks), I have always found statements like: - a path is selected =
and resources are reserved in every node it traverses... Does that imply =
some sort of call admission control? (Many have told me that CAC is not =
considered for MPLS, at least for a telephony service on top of it). My =
question lies in the fact that, in order to reserve resources, first, =
some kind of effective bandwidth must be computed (am I wrong?). Next, =
if resources are reserved, that means that in some cases the requested =
resources couldn't be granted (because they would be already reserved). =
Finally, if a CAC mechanism is not due to be applied (for those who say =
so), how will a network warrant some bounds on performance metrics like =
delay and packet losses.

=20

Well, thank you very much in advance, I always consider your comments =
and discussions of great value.


Erickson Trejo-Reyes
eenet@electeng.leeds.ac.uk

------=_NextPart_000_000A_01C00BB8.56556960
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.71.1712.3"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>
<P class=3DMsoNormal><SPAN lang=3DEN-GB=20
style=3D"COLOR: black; FONT-FAMILY: Bookman Old Style; =
mso-bidi-font-size: 10.0pt">Hello,=20
I wouldn't like to take too much of your time, but if you can be kind =
enough to=20
answer some questions that I have, I would greatly appreciate it. I have =
some=20
doubts about MPLS.</SPAN><SPAN=20
style=3D"FONT-FAMILY: Times New Roman; FONT-SIZE: 12pt; =
mso-ansi-language: ES"><O:P></O:P></SPAN></P>
<P class=3DMsoNormal><SPAN lang=3DEN-GB>&nbsp;</SPAN></P>
<P class=3DMsoNormal><SPAN lang=3DEN-GB=20
style=3D"COLOR: black; FONT-FAMILY: Bookman Old Style; =
mso-bidi-font-size: 10.0pt">While=20
reading about MPLS specification (all my previous experience is on ATM=20
networks), I have always found statements like: - a path is selected and =

resources are reserved in every node it traverses... Does that imply =
some sort=20
of call admission control? (Many have told me that CAC is not considered =
for=20
MPLS, at least for a telephony service on top of it). My question lies =
in the=20
fact that, in order to reserve resources, first, some kind of effective=20
bandwidth must be computed (am I wrong?). Next, if resources are =
reserved, that=20
means that in some cases the requested resources couldn't be granted =
(because=20
they would be already reserved). Finally, if a CAC mechanism is not due =
to be=20
applied (for those who say so), how will a network warrant some bounds =
on=20
performance metrics like delay and packet losses.</SPAN></P>
<P class=3DMsoNormal><SPAN lang=3DEN-GB>&nbsp;</SPAN></P><SPAN =
lang=3DEN-GB=20
style=3D"COLOR: black; FONT-FAMILY: Bookman Old Style; FONT-SIZE: 10pt; =
mso-ansi-language: EN-GB; mso-fareast-font-family: Times New Roman; =
mso-bidi-font-family: Times New Roman; mso-fareast-language: ES; =
mso-bidi-language: AR-SA">Well,=20
thank you very much in advance, I always consider your comments and =
discussions=20
of great value.</SPAN></DIV>
<DIV><SPAN lang=3DEN-GB=20
style=3D"COLOR: black; FONT-FAMILY: Bookman Old Style; FONT-SIZE: 10pt; =
mso-ansi-language: EN-GB; mso-fareast-font-family: Times New Roman; =
mso-bidi-font-family: Times New Roman; mso-fareast-language: ES; =
mso-bidi-language: AR-SA"></SPAN>&nbsp;</DIV>
<DIV><SPAN lang=3DEN-GB=20
style=3D"COLOR: black; FONT-FAMILY: Bookman Old Style; FONT-SIZE: 10pt; =
mso-ansi-language: EN-GB; mso-fareast-font-family: Times New Roman; =
mso-bidi-font-family: Times New Roman; mso-fareast-language: ES; =
mso-bidi-language: AR-SA"></SPAN>&nbsp;</DIV>
<DIV><SPAN lang=3DEN-GB=20
style=3D"COLOR: black; FONT-FAMILY: Bookman Old Style; FONT-SIZE: 10pt; =
mso-ansi-language: EN-GB; mso-fareast-font-family: Times New Roman; =
mso-bidi-font-family: Times New Roman; mso-fareast-language: ES; =
mso-bidi-language: AR-SA"><FONT=20
color=3D#000000>Erickson Trejo-Reyes</FONT></SPAN></DIV>
<DIV><SPAN lang=3DEN-GB=20
style=3D"COLOR: black; FONT-FAMILY: Bookman Old Style; FONT-SIZE: 10pt; =
mso-ansi-language: EN-GB; mso-fareast-font-family: Times New Roman; =
mso-bidi-font-family: Times New Roman; mso-fareast-language: ES; =
mso-bidi-language: AR-SA"><FONT=20
color=3D#000000><A=20
href=3D"mailto:eenet@electeng.leeds.ac.uk">eenet@electeng.leeds.ac.uk</A>=
</FONT></SPAN></DIV></BODY></HTML>

------=_NextPart_000_000A_01C00BB8.56556960--



From owner-mpls@UU.NET  Mon Aug 21 16:47:10 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09127
	for <mpls-archive@lists.ietf.org>; Mon, 21 Aug 2000 16:47:10 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdgd01732;
	Mon, 21 Aug 2000 20:47:03 GMT
Received: by mail-control.mail.uu.net 
	id QQjdgd22349
	for mpls-outgoing; Mon, 21 Aug 2000 20:46:39 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjdgd22342
	for <mpls@mail-control.mail.uu.net>; Mon, 21 Aug 2000 20:46:37 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjdgd29383
	for <mpls@uu.net>; Mon, 21 Aug 2000 16:46:30 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88])
	id QQjdgd24001
	for <mpls@uu.net>; Mon, 21 Aug 2000 20:46:14 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id NAA28870
	for <mpls@uu.net>; Mon, 21 Aug 2000 13:46:32 -0700 (PDT)
Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id QAA11368 for mpls@uu.net; Mon, 21 Aug 2000 16:46:12 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjcvc27287
	for <mpls@mail-control.mail.uu.net>; Fri, 18 Aug 2000 21:08:34 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjcvc18700
	for <mpls@uu.net>; Fri, 18 Aug 2000 17:08:24 -0400 (EDT)
Received: from web9202.mail.yahoo.com by wodc7mr1.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: [216.136.129.35])
	id QQjcvc19295
	for <mpls@uu.net>; Fri, 18 Aug 2000 21:08:08 GMT
Message-ID: <20000818210805.3868.qmail@web9202.mail.yahoo.com>
Received: from [171.71.221.161] by web9202.mail.yahoo.com; Fri, 18 Aug 2000 14:08:05 PDT
Date: Fri, 18 Aug 2000 14:08:05 -0700 (PDT)
From: Vishal M <vishal_study@yahoo.com>
Subject: RE: LSP setup time and delay
To: Shahram Davari <Shahram_Davari@pmc-sierra.com>
Cc: mpls@UU.NET
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk


Thanks for the clarifications:

In the MPLS network, the LSRs exchange the 
OSPF TE LSAs containing bandwidth availability 
information etc.

Now if the resource avail changes and it calls for a 
new TE LSP, would this change (i.e. new LSP 
establishment) happen automatically or would it be
data-driven. 

i.e. if the OSPF Routing Plane gets a new TE 
LSA, it could handle it in following ways:

a. Routing plane runs the SPF calculation
   on receipt of every TE LSA and informs the MPLS 
   Signalling Plane of this change.

   If we follow (a), it could mean:
   - more SPF calculations and more computation
     overhead on the LSRs.

b. Routing Plane waits for the Signaling
   Plane to trigger a request for a new explicit 
   path. Once requested, Routing Plane runs the
   SPF algo, calculates new routes and gives it
   back to the Signalling Plane. i.e. the SPF 
   calculation is data-driven.

   If we follow (b), it could lead to
   - delays (as mentioned in the original ques).

Which of these is preferred approach and why ?

As far as I remember reading on this, approach (b) 
is preferred. But, if that is correct, it contradicts
with our current discussion (that LSP setup is _not_
data-driven).

Am I missing something...

Could you please throw some pointers...

Thanks,
Vishal.
 
--- Shahram Davari <Shahram_Davari@pmc-sierra.com>
wrote:
> Hi Vishal,
> 
> >-----Original Message-----
> >From: Vishal M [mailto:vishal_study@yahoo.com]
> >Sent: Friday, August 18, 2000 2:11 PM
> >To: Shahram Davari; 'Tim.Cook@go.ecitele.com'
> >Cc: 'Vishal M'; mpls@UU.NET
> >Subject: RE: LSP setup time and delay
> >
> >
> >
> >Hi Shahram,
> >
> >Thanks for reply. Some more doubts:
> >
> >1. If the LSP setup is not data-driven, how
> >   many LSPs are established on the ingress LSR
> (LER)
> >   when LER initializes ?
> 
> It depends on the network policy and requests that
> are signaled. In many
> cases (such as in a Diffserv network) you probably
> need at least one LSP per
> egress LSR.
> 
> >
> >2. Wouldn't this lead to a lot of manual
> intervention
> >   in pre-establishing these LSPs ?
> 
> Not really. You just need to specify the ingress
> LSR, the egress LSR, the
> FEC and the required QoS (such as BW) for the
> required LSP, and the TE
> software will find and establish the path for you. 
>  
> >
> >3. What happens if LER gets an IP packet for which
> >   there is no pre-established LSP (and assuming
> >   that the IP packet belongs to a mission-critical
> >   application) ? 
> >   How do we ensure QoS in this case ? 
> 
> If after the packet classification it is found that
> the packet does not map
> to any LSP, then this is up to the network policy,
> it may send it as L3
> packet or may drop it. It is up to the network
> provider to assign all
> required FECs to proper LSPs at the edge.
> 
> The best method is for the mission-critical
> application to signal its
> required QoS. The network will use this information
> to establish the
> required LSP. If such an LSP can't be found then the
> request will be
> rejected. In other words admission control is the
> best method to make sure
> that the mission-critical packets receive their
> required QoS.
> 
> Regards,
> -Shahram 
> 
> >   
> >Thanks,
> >Vishal.
> >
> >--- Shahram Davari <Shahram_Davari@pmc-sierra.com>
> >wrote:
> >> Tim,
> >> 
> >> No. Control packets are L3 forwarded. Also in
> data
> >> driven method, the
> >> packets are initially L3 forwarded and then
> switched
> >> to L2 forwarding when
> >> LSP is setup.
> >> 
> >> -Shahram
> >> 
> >> >-----Original Message-----
> >> >From: Tim.Cook@go.ecitele.com
> >> [mailto:Tim.Cook@go.ecitele.com]
> >> >Sent: Friday, August 18, 2000 10:49 AM
> >> >To: Shahram Davari
> >> >Cc: 'Vishal M'; mpls@UU.NET
> >> >Subject: RE: LSP setup time and delay
> >> >
> >> >
> >> >
> >> >
> >> >Does this mean that there is no L3 forwarding
> >> between two LSRs 
> >> >(all traffic
> >> >is labeled)?
> >> >
> >> >
> >> >
> >> >
> >> >Shahram Davari <Shahram_Davari@pmc-sierra.com>
> on
> >> 08/18/2000 
> >> >10:22:40 AM
> >> >                                                
>   
> >>           
> >> >                                                
>   
> >>           
> >> >                                                
>   
> >>           
> >> > To:      "'Vishal M'" <vishal_study@yahoo.com>,
> >> mpls@UU.NET  
> >> >                                                
>   
> >>           
> >> > cc:      (bcc: Tim Cook/Fort Lauderdale/ECI
> >> Telecom)         
> >> >                                                
>   
> >>           
> >> >                                                
>   
> >>           
> >> >                                                
>   
> >>           
> >> > Subject: RE: LSP setup time and delay          
>   
> >>           
> >> >                                                
>   
> >>           
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >Vishal,
> >> >
> >> >What you are describing is called "data driven
> >> label 
> >> >assignment". This is
> >> >explained in framework document, and requires L3
> >> forwarding 
> >> >until the LSP
> >> >is
> >> >setup. Due to its problems it has not been
> pursued
> >> further by MPLS WG
> >> >(however, some implementations exist). Control
> >> driven label 
> >> >assignment is
> >> >the one most of the people are working on.
> >> >
> >> >Regards,
> >> >-Shahram
> >> >
> >> >>-----Original Message-----
> >> >>From: Vishal M [mailto:vishal_study@yahoo.com]
> >> >>Sent: Friday, August 18, 2000 4:15 AM
> >> >>To: mpls@UU.NET
> >> >>Subject: LSP setup time and delay
> >> >>
> >> >>
> >> >>
> >> >>Hello,
> >> >>
> >> >>Suppose an IP packet is to sent over a MPLS
> >> network.
> >> >>As I understand the protocol, different
> components
> >> at
> >> >>the ingres LSR (also called LER) interact in
> the
> >> >>following way:
> >> >>
> >> >>1. MPLS Signaling Plane (CR-LDP/RSVP) queries
> the
> >> >>Routing Plane (IGP Extensions) to get the
> Explicit
> >> >>Path to reach the destination (assuming nothing
> >> >>in the tables initially).
> >> >>
> >> >>2. Signaling Plane uses RSVP or CR-LDP to
> reserve
> >> >>resources along the explicit path. Label
> mapping
> >> >>is performed at the intermediatory LSRs.
> >> >>
> >> >>3. After the path is set up i.e. LSP is
> >> established
> >> >>from the source to the destination, the
> incoming
> 
=== message truncated ===


__________________________________________________
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/



From owner-mpls@UU.NET  Mon Aug 21 16:47:20 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09140
	for <mpls-archive@lists.ietf.org>; Mon, 21 Aug 2000 16:47:20 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdgd24807;
	Mon, 21 Aug 2000 20:47:13 GMT
Received: by mail-control.mail.uu.net 
	id QQjdgd22361
	for mpls-outgoing; Mon, 21 Aug 2000 20:46:45 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjdgd22352
	for <mpls@mail-control.mail.uu.net>; Mon, 21 Aug 2000 20:46:40 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjdgd27601
	for <mpls@uu.net>; Mon, 21 Aug 2000 16:46:35 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88])
	id QQjdgd24236
	for <mpls@uu.net>; Mon, 21 Aug 2000 20:46:35 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id NAA29172
	for <mpls@uu.net>; Mon, 21 Aug 2000 13:46:52 -0700 (PDT)
Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id QAA11374 for mpls@uu.net; Mon, 21 Aug 2000 16:46:33 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjcvd28438
	for <mpls@mail-control.mail.uu.net>; Fri, 18 Aug 2000 21:17:36 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjcvd20076;
	Fri, 18 Aug 2000 17:17:28 -0400 (EDT)
Received: from mailcarrier.iad1.gctr.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailcarrier.iad1.gctr.net [204.152.166.150])
	id QQjcvd22998;
	Fri, 18 Aug 2000 21:17:13 GMT
Received: from pobox.snv1.gctr.net (dcooper@pobox.snv1.gctr.net [204.71.194.242])
	by mailcarrier.iad1.gctr.net (8.9.3/8.9.0) with ESMTP id VAA25866;
	Fri, 18 Aug 2000 21:17:11 GMT
Received: (from dcooper@localhost)
	by pobox.snv1.gctr.net (8.9.3/8.9.3) id VAA03949;
	Fri, 18 Aug 2000 21:16:53 GMT
Date: Fri, 18 Aug 2000 21:16:53 +0000
From: Dave Cooper <dcooper@gblx.net>
To: Ron Bonica <rbonica@mci.net>
Cc: "Thomas D. Nadeau" <tnadeau@cisco.com>, Vijay Gill <vijay@umbc.edu>,
        Randy Bush <randy@psg.com>, te-wg@UU.NET, mpls@UU.NET
Subject: Re: consensus to make draft-kompella-mpls-te-mib-00.txt a TEWGitem?
Message-ID: <20000818211653.A725@gblx.net>
References: <4.3.2.7.2.20000818135125.04dc7920@bucket.cisco.com> <NBBBJGONOLIJDDNHNNBEIEJOEEAA.rbonica@mci.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95i
In-Reply-To: Ron Bonica's message from Fri, Aug 18, 2000 at 02:47:53PM - ID <NBBBJGONOLIJDDNHNNBEIEJOEEAA.rbonica@mci.net>
Sender: owner-mpls@UU.NET
Precedence: bulk

Our network is another heavy implementor of MPLS w/ both vendors
in the mix and i'll second Ron's comments on what basic functionality
we need NOW rather than waiting for some all-encomapssing all-vendor
satisfying MIB (if that exists). Basic operational checks into 

LSP transitions via counter
LSP last transition
LSP path changes
LSP explicit route 
LSP record route

All of which have to currently be retrieved using less than 
spectacular methods.  A script ssh'ing to the routers
every N minute doesnt cut it.
 
While both implementations tend to do the same 
thing using different methods, i still think a majority of the 
objects in kireeti's mib can be extended across all implementations.

Bottom line... now is better than later as far as an operator's 
concerned.

-dave 


Ron Bonica said :
> >          What I will assure you of is that the Kireeti-MIB is based on the
> > reality of the Juniper implementation. This is not the reality of what the
> > rest of the world uses. Furthermore, it does not necessarily contain the
> > operational reality of MPLS features that other LSR vendors are currently
> > deploying due to its incomplete nature.
> >
> 
> Tom,
> 
> I am an operator with MPLS deployed in my network. For fault management
> purposes, I need to know the following:
> 
> 	-> which LSPs are broken
> 	-> which LSPs are sub-optimally routed
> 	-> which LSPs have reset
> 
> Using Kireeti's MIB, I can answer these questions by polling the following
> items:
> 
> 	-> mplsLspState
> 	-> mplsPathType
> 	-> mplsLspLastPathChange
> 
> This is pretty simple.
> 
> Couldn't this level of abstraction be applied to any MPLS implementation?
> 
> Please re-orient me if I am missing some very fundamental issue.
> 
>                            Ron
> 



From owner-mpls@UU.NET  Mon Aug 21 16:48:09 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09163
	for <mpls-archive@lists.ietf.org>; Mon, 21 Aug 2000 16:48:08 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdgd02775;
	Mon, 21 Aug 2000 20:48:05 GMT
Received: by mail-control.mail.uu.net 
	id QQjdgd22447
	for mpls-outgoing; Mon, 21 Aug 2000 20:47:44 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjdgd22417
	for <mpls@mail-control.mail.uu.net>; Mon, 21 Aug 2000 20:47:30 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjdgd29471
	for <mpls@uu.net>; Mon, 21 Aug 2000 16:46:58 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88])
	id QQjdgd24506
	for <mpls@uu.net>; Mon, 21 Aug 2000 20:46:58 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id NAA29516
	for <mpls@uu.net>; Mon, 21 Aug 2000 13:47:16 -0700 (PDT)
Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id QAA11380 for mpls@uu.net; Mon, 21 Aug 2000 16:46:56 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjcve00188
	for <mpls@mail-control.mail.uu.net>; Fri, 18 Aug 2000 21:34:54 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjcve09213
	for <mpls@UU.NET>; Fri, 18 Aug 2000 17:34:47 -0400 (EDT)
From: tmuir@monmouth.com
Received: from mail.monmouth.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail.monmouth.com [209.191.58.1])
	id QQjcve07102
	for <mpls@UU.NET>; Fri, 18 Aug 2000 21:34:47 GMT
Received: from 198.139.117.130 (www.monmouth.com [209.191.58.2])
	by mail.monmouth.com (8.9.3/8.9.3) with SMTP id RAA01901
	for <mpls@UU.NET>; Fri, 18 Aug 2000 17:34:47 -0400 (EDT)
Message-Id: <200008182134.RAA01901@mail.monmouth.com>
To: mpls@UU.NET
Subject: Re: consensus to make draft-kompella-mpls-te-mib-00.txt a TEWG item?
Date: Fri, 18 Aug 2000 17:34:47 EDT
X-Mailer: MI-Webmail - Monmouth Internet 
Sender: owner-mpls@UU.NET
Precedence: bulk

Jim Boyle wrote:
> Should Kireeti's draft
> a) be accepted as a TE WG item at this time?
> b) not be accepted as a TE WG item at this time?

In view of the existence of a perfectly adequate te mib in the mplswg
which has existed for quite a while now I propose that this new MIB not
be accepted as a tewg draft. We certainly do not want two MIBs for MPLS
TE!

Tom


---------------------------------------------
This message was sent using MI-Webmail.
No matter where you are, never lose touch.
Get your Email using MI-Webmail.
http://www.monmouth.com/




From owner-mpls@UU.NET  Mon Aug 21 16:48:30 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09176
	for <mpls-archive@lists.ietf.org>; Mon, 21 Aug 2000 16:48:29 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdgd26003;
	Mon, 21 Aug 2000 20:48:21 GMT
Received: by mail-control.mail.uu.net 
	id QQjdgd22455
	for mpls-outgoing; Mon, 21 Aug 2000 20:47:48 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjdgd22433
	for <mpls@mail-control.mail.uu.net>; Mon, 21 Aug 2000 20:47:41 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjdgd27778
	for <mpls@uu.net>; Mon, 21 Aug 2000 16:47:29 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11])
	id QQjdgd02204
	for <mpls@uu.net>; Mon, 21 Aug 2000 20:47:28 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id NAA14389
	for <mpls@uu.net>; Mon, 21 Aug 2000 13:47:45 -0700 (PDT)
Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id QAA11390 for mpls@uu.net; Mon, 21 Aug 2000 16:47:26 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjcvh16495
	for <mpls@mail-control.mail.uu.net>; Fri, 18 Aug 2000 22:24:18 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjcvh29261
	for <mpls@uu.net>; Fri, 18 Aug 2000 18:24:16 -0400 (EDT)
Received: from web9204.mail.yahoo.com by wodc7mr2.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: [216.136.129.37])
	id QQjcvh03600
	for <mpls@uu.net>; Fri, 18 Aug 2000 22:24:01 GMT
Message-ID: <20000818222400.12604.qmail@web9204.mail.yahoo.com>
Received: from [171.71.221.161] by web9204.mail.yahoo.com; Fri, 18 Aug 2000 15:24:00 PDT
Date: Fri, 18 Aug 2000 15:24:00 -0700 (PDT)
From: Vishal M <vishal_study@yahoo.com>
Subject: RE: LSP setup time and delay
To: Shahram Davari <Shahram_Davari@pmc-sierra.com>
Cc: mpls@UU.NET
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk


Hi Shahram,

Thanks for the clarifications. I've one more
question on a related issue:

In the MPLS network, the LSRs exchange the 
OSPF TE LSAs containing bandwidth availability 
information etc.

Now if the resource avail changes and it calls for a 
new TE LSP, would this change (i.e. new LSP 
establishment) happen automatically or would it be
data-driven. 

i.e. if the OSPF Routing Plane gets a new TE 
LSA, it could handle it in following ways:

a. Routing plane runs the SPF calculation
   on receipt of every TE LSA and informs the MPLS 
   Signalling Plane of this change.

   If we follow (a), it could mean:
   - more SPF calculations and more computation
     overhead on the LSRs.

b. Routing Plane waits for the Signaling
   Plane to trigger a request for a new explicit 
   path. Once requested, Routing Plane runs the
   SPF algo, calculates new routes and gives it
   back to the Signalling Plane. i.e. the SPF 
   calculation is data-driven.

   If we follow (b), it could lead to
   - delays (as mentioned in the original ques).

Which of these is preferred approach and why ?

As far as I remember reading on this, approach (b) 
is preferred. But, if that is correct, it contradicts
with our current discussion (that LSP setup is _not_
data-driven).

Am I missing something...

Could you please throw some pointers...

Thanks,
Vishal.


--- Shahram Davari <Shahram_Davari@pmc-sierra.com>
wrote:
> Hi Vishal,
> 
> >-----Original Message-----
> >From: Vishal M [mailto:vishal_study@yahoo.com]
> >Sent: Friday, August 18, 2000 2:11 PM
> >To: Shahram Davari; 'Tim.Cook@go.ecitele.com'
> >Cc: 'Vishal M'; mpls@UU.NET
> >Subject: RE: LSP setup time and delay
> >
> >
> >
> >Hi Shahram,
> >
> >Thanks for reply. Some more doubts:
> >
> >1. If the LSP setup is not data-driven, how
> >   many LSPs are established on the ingress LSR
> (LER)
> >   when LER initializes ?
> 
> It depends on the network policy and requests that
> are signaled. In many
> cases (such as in a Diffserv network) you probably
> need at least one LSP per
> egress LSR.
> 
> >
> >2. Wouldn't this lead to a lot of manual
> intervention
> >   in pre-establishing these LSPs ?
> 
> Not really. You just need to specify the ingress
> LSR, the egress LSR, the
> FEC and the required QoS (such as BW) for the
> required LSP, and the TE
> software will find and establish the path for you. 
>  
> >
> >3. What happens if LER gets an IP packet for which
> >   there is no pre-established LSP (and assuming
> >   that the IP packet belongs to a mission-critical
> >   application) ? 
> >   How do we ensure QoS in this case ? 
> 
> If after the packet classification it is found that
> the packet does not map
> to any LSP, then this is up to the network policy,
> it may send it as L3
> packet or may drop it. It is up to the network
> provider to assign all
> required FECs to proper LSPs at the edge.
> 
> The best method is for the mission-critical
> application to signal its
> required QoS. The network will use this information
> to establish the
> required LSP. If such an LSP can't be found then the
> request will be
> rejected. In other words admission control is the
> best method to make sure
> that the mission-critical packets receive their
> required QoS.
> 
> Regards,
> -Shahram 
> 
> >   
> >Thanks,
> >Vishal.
> >
> >--- Shahram Davari <Shahram_Davari@pmc-sierra.com>
> >wrote:
> >> Tim,
> >> 
> >> No. Control packets are L3 forwarded. Also in
> data
> >> driven method, the
> >> packets are initially L3 forwarded and then
> switched
> >> to L2 forwarding when
> >> LSP is setup.
> >> 
> >> -Shahram
> >> 
> >> >-----Original Message-----
> >> >From: Tim.Cook@go.ecitele.com
> >> [mailto:Tim.Cook@go.ecitele.com]
> >> >Sent: Friday, August 18, 2000 10:49 AM
> >> >To: Shahram Davari
> >> >Cc: 'Vishal M'; mpls@UU.NET
> >> >Subject: RE: LSP setup time and delay
> >> >
> >> >
> >> >
> >> >
> >> >Does this mean that there is no L3 forwarding
> >> between two LSRs 
> >> >(all traffic
> >> >is labeled)?
> >> >
> >> >
> >> >
> >> >
> >> >Shahram Davari <Shahram_Davari@pmc-sierra.com>
> on
> >> 08/18/2000 
> >> >10:22:40 AM
> >> >                                                
>   
> >>           
> >> >                                                
>   
> >>           
> >> >                                                
>   
> >>           
> >> > To:      "'Vishal M'" <vishal_study@yahoo.com>,
> >> mpls@UU.NET  
> >> >                                                
>   
> >>           
> >> > cc:      (bcc: Tim Cook/Fort Lauderdale/ECI
> >> Telecom)         
> >> >                                                
>   
> >>           
> >> >                                                
>   
> >>           
> >> >                                                
>   
> >>           
> >> > Subject: RE: LSP setup time and delay          
>   
> >>           
> >> >                                                
>   
> >>           
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >Vishal,
> >> >
> >> >What you are describing is called "data driven
> >> label 
> >> >assignment". This is
> >> >explained in framework document, and requires L3
> >> forwarding 
> >> >until the LSP
> >> >is
> >> >setup. Due to its problems it has not been
> pursued
> >> further by MPLS WG
> >> >(however, some implementations exist). Control
> >> driven label 
> >> >assignment is
> >> >the one most of the people are working on.
> >> >
> >> >Regards,
> >> >-Shahram
> >> >
> >> >>-----Original Message-----
> >> >>From: Vishal M [mailto:vishal_study@yahoo.com]
> >> >>Sent: Friday, August 18, 2000 4:15 AM
> >> >>To: mpls@UU.NET
> >> >>Subject: LSP setup time and delay
> >> >>
> >> >>
> >> >>
> >> >>Hello,
> >> >>
> >> >>Suppose an IP packet is to sent over a MPLS
> >> network.
> >> >>As I understand the protocol, different
> components
> >> at
> >> >>the ingres LSR (also called LER) interact in
> the
> >> >>following way:
> >> >>
> >> >>1. MPLS Signaling Plane (CR-LDP/RSVP) queries
> the
> >> >>Routing Plane (IGP Extensions) to get the
> Explicit
> >> >>Path to reach the destination (assuming nothing
> >> >>in the tables initially).
> >> >>
> >> >>2. Signaling Plane uses RSVP or CR-LDP to
> reserve
> >> >>resources along the explicit path. Label
> mapping
> >> >>is performed at the intermediatory LSRs.
> >> >>
> >> >>3. After the path is set up i.e. LSP is
> >> established
> >> >>from the source to the destination, the
> incoming
> 
=== message truncated ===


__________________________________________________
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/



From owner-mpls@UU.NET  Mon Aug 21 16:49:16 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09190
	for <mpls-archive@lists.ietf.org>; Mon, 21 Aug 2000 16:49:15 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdgd04076;
	Mon, 21 Aug 2000 20:49:11 GMT
Received: by mail-control.mail.uu.net 
	id QQjdgd22585
	for mpls-outgoing; Mon, 21 Aug 2000 20:48:40 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjdgd22573
	for <mpls@mail-control.mail.uu.net>; Mon, 21 Aug 2000 20:48:33 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjdgd29656
	for <mpls@uu.net>; Mon, 21 Aug 2000 16:48:05 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88])
	id QQjdgd25390
	for <mpls@uu.net>; Mon, 21 Aug 2000 20:47:45 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id NAA00019
	for <mpls@uu.net>; Mon, 21 Aug 2000 13:48:02 -0700 (PDT)
Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id QAA11396 for mpls@uu.net; Mon, 21 Aug 2000 16:47:43 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjcwv02139
	for <mpls@mail-control.mail.uu.net>; Sat, 19 Aug 2000 08:20:17 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjcwv04466
	for <mpls@uu.net>; Sat, 19 Aug 2000 04:20:15 -0400 (EDT)
Received: from web9204.mail.yahoo.com by wodc7mr2.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: [216.136.129.37])
	id QQjcwv09486
	for <mpls@uu.net>; Sat, 19 Aug 2000 08:19:44 GMT
Message-ID: <20000819081945.22378.qmail@web9204.mail.yahoo.com>
Received: from [209.245.136.33] by web9204.mail.yahoo.com; Sat, 19 Aug 2000 01:19:45 PDT
Date: Sat, 19 Aug 2000 01:19:45 -0700 (PDT)
From: Vishal M <vishal_study@yahoo.com>
Subject: RE: LSP setup time and delay
To: Shahram Davari <Shahram_Davari@pmc-sierra.com>
Cc: mpls@UU.NET, vishal_study@yahoo.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk


Hi,

Thanks for the clarifications. One more related
question:

In the MPLS network, the LSRs exchange the 
OSPF TE LSAs containing bandwidth availability 
information etc.

Now if the resource avail changes and it calls for a 
new TE LSP, would this change (i.e. new LSP 
establishment) happen automatically or would it be
data-driven. 

i.e. if the OSPF Routing Plane gets a new TE 
LSA, it could handle it in following ways:

a. Routing plane runs the SPF calculation
   on receipt of every TE LSA and informs the MPLS 
   Signalling Plane of this change.

   If we follow (a), it could mean:
   - more SPF calculations and more computation
     overhead on the LSRs.

b. Routing Plane waits for the Signaling
   Plane to trigger a request for a new explicit 
   path. Once requested, Routing Plane runs the
   SPF algo, calculates new routes and gives it
   back to the Signalling Plane. i.e. the SPF 
   calculation is data-driven.

   If we follow (b), it could lead to
   - LSPs based on out-dated resource info
   - delays (as mentioned in the original ques).

Which approach is preferred and why ?

As far as I remember reading on this, approach (b) 
is preferred. But, if that is correct, it contradicts
with our current discussion (that LSP setup is _not_
data-driven).

Am I missing something...

Could you please throw some pointers...

Thanks,
Vishal.

PS: I apologize if you receive multiple copies
of this mail. I sent this before, but didn't see
this on the mailing list.
 

--- Shahram Davari <Shahram_Davari@pmc-sierra.com>
wrote:
> Hi Vishal,
> 
> >-----Original Message-----
> >From: Vishal M [mailto:vishal_study@yahoo.com]
> >Sent: Friday, August 18, 2000 2:11 PM
> >To: Shahram Davari; 'Tim.Cook@go.ecitele.com'
> >Cc: 'Vishal M'; mpls@UU.NET
> >Subject: RE: LSP setup time and delay
> >
> >
> >
> >Hi Shahram,
> >
> >Thanks for reply. Some more doubts:
> >
> >1. If the LSP setup is not data-driven, how
> >   many LSPs are established on the ingress LSR
> (LER)
> >   when LER initializes ?
> 
> It depends on the network policy and requests that
> are signaled. In many
> cases (such as in a Diffserv network) you probably
> need at least one LSP per
> egress LSR.
> 
> >
> >2. Wouldn't this lead to a lot of manual
> intervention
> >   in pre-establishing these LSPs ?
> 
> Not really. You just need to specify the ingress
> LSR, the egress LSR, the
> FEC and the required QoS (such as BW) for the
> required LSP, and the TE
> software will find and establish the path for you. 
>  
> >
> >3. What happens if LER gets an IP packet for which
> >   there is no pre-established LSP (and assuming
> >   that the IP packet belongs to a mission-critical
> >   application) ? 
> >   How do we ensure QoS in this case ? 
> 
> If after the packet classification it is found that
> the packet does not map
> to any LSP, then this is up to the network policy,
> it may send it as L3
> packet or may drop it. It is up to the network
> provider to assign all
> required FECs to proper LSPs at the edge.
> 
> The best method is for the mission-critical
> application to signal its
> required QoS. The network will use this information
> to establish the
> required LSP. If such an LSP can't be found then the
> request will be
> rejected. In other words admission control is the
> best method to make sure
> that the mission-critical packets receive their
> required QoS.
> 
> Regards,
> -Shahram 
> 
> >   
> >Thanks,
> >Vishal.
> >
> >--- Shahram Davari <Shahram_Davari@pmc-sierra.com>
> >wrote:
> >> Tim,
> >> 
> >> No. Control packets are L3 forwarded. Also in
> data
> >> driven method, the
> >> packets are initially L3 forwarded and then
> switched
> >> to L2 forwarding when
> >> LSP is setup.
> >> 
> >> -Shahram
> >> 
> >> >-----Original Message-----
> >> >From: Tim.Cook@go.ecitele.com
> >> [mailto:Tim.Cook@go.ecitele.com]
> >> >Sent: Friday, August 18, 2000 10:49 AM
> >> >To: Shahram Davari
> >> >Cc: 'Vishal M'; mpls@UU.NET
> >> >Subject: RE: LSP setup time and delay
> >> >
> >> >
> >> >
> >> >
> >> >Does this mean that there is no L3 forwarding
> >> between two LSRs 
> >> >(all traffic
> >> >is labeled)?
> >> >
> >> >
> >> >
> >> >
> >> >Shahram Davari <Shahram_Davari@pmc-sierra.com>
> on
> >> 08/18/2000 
> >> >10:22:40 AM
> >> >                                                
>   
> >>           
> >> >                                                
>   
> >>           
> >> >                                                
>   
> >>           
> >> > To:      "'Vishal M'" <vishal_study@yahoo.com>,
> >> mpls@UU.NET  
> >> >                                                
>   
> >>           
> >> > cc:      (bcc: Tim Cook/Fort Lauderdale/ECI
> >> Telecom)         
> >> >                                                
>   
> >>           
> >> >                                                
>   
> >>           
> >> >                                                
>   
> >>           
> >> > Subject: RE: LSP setup time and delay          
>   
> >>           
> >> >                                                
>   
> >>           
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >Vishal,
> >> >
> >> >What you are describing is called "data driven
> >> label 
> >> >assignment". This is
> >> >explained in framework document, and requires L3
> >> forwarding 
> >> >until the LSP
> >> >is
> >> >setup. Due to its problems it has not been
> pursued
> >> further by MPLS WG
> >> >(however, some implementations exist). Control
> >> driven label 
> >> >assignment is
> >> >the one most of the people are working on.
> >> >
> >> >Regards,
> >> >-Shahram
> >> >
> >> >>-----Original Message-----
> >> >>From: Vishal M [mailto:vishal_study@yahoo.com]
> >> >>Sent: Friday, August 18, 2000 4:15 AM
> >> >>To: mpls@UU.NET
> >> >>Subject: LSP setup time and delay
> >> >>
> >> >>
> >> >>
> >> >>Hello,
> >> >>
> >> >>Suppose an IP packet is to sent over a MPLS
> >> network.
> >> >>As I understand the protocol, different
> components
> >> at
> >> >>the ingres LSR (also called LER) interact in
> the
> >> >>following way:
> >> >>
> >> >>1. MPLS Signaling Plane (CR-LDP/RSVP) queries
> the
> >> >>Routing Plane (IGP Extensions) to get the
> Explicit
> >> >>Path to reach the destination (assuming nothing
> >> >>in the tables initially).
> >> >>
> >> >>2. Signaling Plane uses RSVP or CR-LDP to
> reserve
> >> >>resources along the explicit path. Label
> mapping
> >> >>is performed at the intermediatory LSRs.
> >> >>
> >> >>3. After the path is set up i.e. LSP is
> >> established
> >> >>from the source to the destination, the
> incoming
> 
=== message truncated ===


__________________________________________________
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/



From owner-mpls@UU.NET  Mon Aug 21 16:49:36 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09201
	for <mpls-archive@lists.ietf.org>; Mon, 21 Aug 2000 16:49:36 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdgd27296;
	Mon, 21 Aug 2000 20:49:31 GMT
Received: by mail-control.mail.uu.net 
	id QQjdgd22632
	for mpls-outgoing; Mon, 21 Aug 2000 20:48:56 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjdgd22597
	for <mpls@mail-control.mail.uu.net>; Mon, 21 Aug 2000 20:48:44 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjdgd29759
	for <mpls@uu.net>; Mon, 21 Aug 2000 16:48:39 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11])
	id QQjdgd02827
	for <mpls@uu.net>; Mon, 21 Aug 2000 20:48:08 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id NAA14914
	for <mpls@uu.net>; Mon, 21 Aug 2000 13:48:25 -0700 (PDT)
Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id QAA11406 for mpls@uu.net; Mon, 21 Aug 2000 16:48:07 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjdcb05358
	for <mpls@mail-control.mail.uu.net>; Sun, 20 Aug 2000 18:27:28 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjdcb27401;
	Sun, 20 Aug 2000 14:27:23 -0400 (EDT)
Received: from mailcarrier.snv1.gctr.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailcarrier.snv1.gctr.net [206.251.8.19])
	id QQjdcb13685;
	Sun, 20 Aug 2000 18:27:08 GMT
Received: from xipeng (dhcp-197.cas1.gctr.net [208.48.114.197])
	by mailcarrier.snv1.gctr.net (8.9.3/8.9.0) with SMTP id SAA24217;
	Sun, 20 Aug 2000 18:27:07 GMT
Message-ID: <007c01c00ad4$f36ac860$c57230d0@gctr.net>
Reply-To: "Xipeng Xiao" <xiaoxipe@cse.msu.edu>
From: "Xipeng Xiao" <xiaoxipe@cse.msu.edu>
To: <danny@ambernetworks.com>
Cc: <te-wg@UU.NET>, <mpls@UU.NET>
References: <200008200441.WAA22653@tcb.net>
Subject: Re: "Two roads diverged in a yellow wood"
Date: Sun, 20 Aug 2000 11:32:09 -0700
Organization: Michigan State Univ.
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.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

> As for what we do now, good question.  While I completely 
> agree with Randy/Vijay's comments, I also understand there's
> significant value in a single MIB.  Perhaps the right way
> to go is to merge the MIBs, with some wording surrounding
> the use of Kireeti's MIB as a base, and the "MPLS-TE-MIB"
> as the "full MIB".  While I'm guessing this goes against 
> all the "MPLS-TE-MIB" folks stand for,  and do realize it's
> not quite that simple, I'm also guessing it's the only 
> agreement that I foresee will result in a single MIB.

I agree with Danny here.

Xipeng




From owner-mpls@UU.NET  Mon Aug 21 16:50:27 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09225
	for <mpls-archive@lists.ietf.org>; Mon, 21 Aug 2000 16:50:27 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdgd05439;
	Mon, 21 Aug 2000 20:50:19 GMT
Received: by mail-control.mail.uu.net 
	id QQjdgd22731
	for mpls-outgoing; Mon, 21 Aug 2000 20:49:44 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjdgd22675
	for <mpls@mail-control.mail.uu.net>; Mon, 21 Aug 2000 20:49:25 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjdgd28332
	for <mpls@uu.net>; Mon, 21 Aug 2000 16:49:20 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88])
	id QQjdgd26850
	for <mpls@uu.net>; Mon, 21 Aug 2000 20:49:04 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id NAA01294
	for <mpls@uu.net>; Mon, 21 Aug 2000 13:49:22 -0700 (PDT)
Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id QAA11420 for mpls@uu.net; Mon, 21 Aug 2000 16:49:03 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjddm22592
	for <mpls@mail-control.mail.uu.net>; Mon, 21 Aug 2000 03:43:58 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjddm23878
	for <mpls@UU.NET>; Sun, 20 Aug 2000 23:43:45 -0400 (EDT)
Received: from force10networks.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtp.force10networks.com [206.54.51.114])
	id QQjddm12222
	for <mpls@UU.NET>; Mon, 21 Aug 2000 03:43:29 GMT
Received: from pc2101 by force10networks.com (8.8.8+Sun/ncore-main9-99)
	id UAA21396; Sun, 20 Aug 2000 20:43:25 -0700 (PDT)
From: "Rajeev Manur" <rmanur@force10networks.com>
To: "'Harish Belur'" <hbelur@cisco.com>, <mpls@UU.NET>
Subject: RE: MPLS & Ethernet
Date: Sun, 20 Aug 2000 20:43:22 -0700
Message-ID: <845591f43c2c79b60d274ee60991f51f39a0a5cb@force10networks.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <004d01c00b14$d09d38f0$2c13130a@cisco.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Please refer to section 3.0 of draft-ietf-mpls-label-encaps-08.txt

-----Original Message-----
From: Harish Belur [mailto:hbelur@cisco.com]
Sent: Sunday, August 20, 2000 7:09 PM
To: mpls@UU.NET
Subject: MPLS & Ethernet


Hi,

I apologize if this has been asked and answered on this list since I am new
to this list.
How is MPLS expected to work on technologies like ethernet which have a
specific MTU ? What is the specified behavior if the packet exceeds MTU size
once a label (or stack of labels) has been added to the packet ?

Thanks,

Harish





From owner-mpls@UU.NET  Mon Aug 21 16:50:42 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09236
	for <mpls-archive@lists.ietf.org>; Mon, 21 Aug 2000 16:50:42 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdgd28699;
	Mon, 21 Aug 2000 20:50:39 GMT
Received: by mail-control.mail.uu.net 
	id QQjdgd22802
	for mpls-outgoing; Mon, 21 Aug 2000 20:50:05 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjdgd22739
	for <mpls@mail-control.mail.uu.net>; Mon, 21 Aug 2000 20:49:46 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjdgd28374
	for <mpls@uu.net>; Mon, 21 Aug 2000 16:49:32 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11])
	id QQjdgd04524
	for <mpls@uu.net>; Mon, 21 Aug 2000 20:49:31 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id NAA16198
	for <mpls@uu.net>; Mon, 21 Aug 2000 13:49:48 -0700 (PDT)
Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id QAA11428 for mpls@uu.net; Mon, 21 Aug 2000 16:49:29 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjddw06285
	for <mpls@mail-control.mail.uu.net>; Mon, 21 Aug 2000 06:13:40 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjddw13768
	for <mpls@uu.net>; Mon, 21 Aug 2000 02:13:37 -0400 (EDT)
Received: from shell16.ba.best.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: shell16.ba.best.com [206.184.139.148])
	id QQjddw13250
	for <mpls@uu.net>; Mon, 21 Aug 2000 06:13:07 GMT
Received: from localhost (heard@localhost)
	by shell16.ba.best.com (8.9.3/8.9.2/best.sh) with ESMTP id XAA10240;
	Sun, 20 Aug 2000 23:13:04 -0700 (PDT)
X-Authentication-Warning: shell16.ba.best.com: heard owned process doing -bs
Date: Sun, 20 Aug 2000 23:13:04 -0700 (PDT)
From: "C. M. Heard" <heard@vvnet.com>
X-Sender: heard@shell16.ba.best.com
To: IETF <ietf@ietf.org>
cc: IESG <iesg@ietf.org>, MPLS <mpls@UU.NET>
Subject: Re: Last Call: ICMP Extensions for MultiProtocol Label Switching to
 Proposed Standard
In-Reply-To: <200008111446.KAA20448@ietf.org>
Message-ID: <Pine.BSF.4.21.0008201133080.15611-100000@shell16.ba.best.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

On Fri, 11 Aug 2000, The IESG wrote:

> The IESG has received a request from the Multiprotocol Label Switching
> Working Group to consider ICMP Extensions for MultiProtocol Label
> Switching <draft-ietf-mpls-icmp-02.txt> as a Proposed Standard.

The IESG and the IETF community are urged to carefully evaluate
the above-referenced draft, as the ICMP extensions that it proposes
require *modification of the format* of the ICMPv4 Destination
Unreachable, Time Exceeded, Parameter Problem, Source Quench, and
Redirect messages, and the proposed modifications are not entirely
backward compatible with RFC 1122 and RFC 1812.

The details of the proposal and the rationale for it are in the draft.
Here is a quick overview.  The format of ICMPv4 error messages, as
defined in RFCs 792, 1122, and 1812 is as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Code      |          Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 varies according to message type              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Internet Header + at least 8 data octets from original datagram|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

RFC 792 specifies that an ICMP error message must contain the Internet
header plus 64 bits of the original datagram's data.  RFC 1122 specifies
that an ICMP error message must contain the Internet header and at least
the first 8 data octets of the datagram that triggered the error;  more
than 8 octets MAY be sent;  this header and data MUST be unchanged
from the received datagram.  RFC 1812 specifies that an ICMP error
message SHOULD contain as much of the original datagram as possible
without the length of the ICMP datagram exceeding 576 bytes.  The
returned IP header (and user data) MUST be identical to that which
was received, except that a router is not required to undo any
modifications to the IP header that are normally performed in forwarding
that were performed before the error was detected (e.g., decrementing
the TTL, or updating options).

The draft proposes to change this as follows:  the first 128 bytes
following the 8-octet ICMP header will contain the original datagram's
Internet header plus as much data as will fit in 128 bytes;  if the
original datagram is shorter than 128 bytes then it will be padded
with 0's.  Immediately after the 128 bytes of data from the original
datagram there will be a checjsummed data structure containing TLV-encoded
objects such as an MPLS label stack or additional returned user data.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Code      |          Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 varies according to message type              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Internet Header + as many data octets from original datagram as|
   |will fit in 128 bytes (zero padded to 128 bytes if necessary)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Extension Data Structure                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The proposed modification breaks the rule that the returned user data
MUST be unchanged from the received datagram.

The IESG and the IETF community are requested to carefully consider
whether breaking this rule is likely to have adverse effects on
deployed implementations.  I have not been able to find any applications
that would be adversely affected, but I would like others who are more
knowledgeable to have a hard look.

Assuming that this proposal to modify ICMPv4 is accepted for
standardization, I would suggest that the title of the draft
be changed to reflect the fact that the extension data structure
is not limited to MPLS-specific extensions, but can in principle
accomodate other extensions as well.  Also, the extension header
version and extension object Class-Num and C-Type fields will need
to be under IANA control, and the document should have an "IANA
Considerations" section (cf. RFC 2434).

There are also some minor technical issues that I would like to point out.

%  According to RFC-792, bytes 0 through 19 of any ICMP message contain
%  a header whose format is analogous to that of the IP datagram. Bytes
%  20 through 23 contain an ICMP message type, code and checksum. Bytes
%  24 through 27 contain message specific data.

I think that bytes 0 through 19 are supposed to be the Internet header
of the IP datagram containing the ICMP message.  There may be more than
20 bytes if IP options are present, and the draft should mention this.

%  Also according to RFC-792, the final field contained by each of the
%  ICMP message types listed above begins at byte 28. It reflects the
%  IP header and leading 64 bits of the original datagram. [RFC-1812]
%  recommends that this final field be extended to include as much of
%  the original datagram as possible.

The final field is at offset 28 from the start of the IP datagram
only in the absence if IP options.

[ ... ]

%  When an LSR appends the data structure defined herein to an ICMP
%  message, the ICMP "total length" MUST be equal to the data structure
%  length plus 156. The first octet of the data structure must be
%  displaced 156 octets from the beginning of the ICMP message.

The number 156 is accurate only in the absence of IP options.

Cordially,

C. M. Heard
heard@vvnet.com




From owner-mpls@UU.NET  Mon Aug 21 17:09:12 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09516
	for <mpls-archive@lists.ietf.org>; Mon, 21 Aug 2000 17:09:12 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdge19277;
	Mon, 21 Aug 2000 21:09:05 GMT
Received: by mail-control.mail.uu.net 
	id QQjdge06484
	for mpls-outgoing; Mon, 21 Aug 2000 21:08:30 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjdge06459
	for <mpls@mail-control.mail.uu.net>; Mon, 21 Aug 2000 21:08:22 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjdge03326
	for <mpls@UU.NET>; Mon, 21 Aug 2000 17:08:14 -0400 (EDT)
Received: from lux.chromisys.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: 193.140.adsl6.netlojix.net [207.71.200.140] (may be forged))
	id QQjdge18222
	for <mpls@UU.NET>; Mon, 21 Aug 2000 21:07:44 GMT
Received: by LUX with Internet Mail Service (5.5.2650.21)
	id <RDGLYR7F>; Mon, 21 Aug 2000 14:07:40 -0700
Message-ID: <51DA0AB3D747D311832F005004827CC02CE9EC@LUX>
From: Jonathan Lang <jplang@calient.net>
To: "'Dawkins, Spencer'" <Spencer.DAWKINS@fnc.fujitsu.com>,
        "'IETF MPLS mailing list'" <mpls@UU.NET>
Subject: RE: LinkSummary in draft-lang-mpls-lmp-01.txt missing fields?
Date: Mon, 21 Aug 2000 14:07:39 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="windows-1252"
Sender: owner-mpls@UU.NET
Precedence: bulk

Spencer,
  Backup CCIds are listed in the Protection channel subobjects of the
LinkSummary message.  Recall from the text in Section 8.5.1 that the "list
of working channels MUST include the control channel".  The identification
of backup control channels is mentioned in the Protection Channel subobject
format.  To make things clear, I can add to the LinkSummary text  as follows
(new text in <<>>):

   "The LinkSummary message contains a list of working channel 
   subobjects and protection channel subobjects.  The list of working 
   channels MUST include the control channel.  <<Any backup control channels
that
   are defined MUST be included in the list of protection channel
subobjects.  Note that
   a backup control channel can also be a working component link (provided
it has
   preemptive priority over the working component link), so it is possible
to appear
   in both the working channel subobject as well as the protection channel
subobject.>>"


-Jonathan

> -----Original Message-----
> From: Dawkins, Spencer [mailto:Spencer.DAWKINS@fnc.fujitsu.com]
> Sent: Thursday, August 17, 2000 12:26 PM
> To: 'IETF MPLS mailing list'
> Subject: LinkSummary in draft-lang-mpls-lmp-01.txt missing fields?
> 
> 
> The text in Section 6.0 of this draft says
> 
>    "The LinkSummary message contains the primary 
>    and backup CCIds, the IP address for the link (binding the 
> CCIds to 
>    the link IP addresses), and the local and remote LinkIds for each 
>    component link and their associated priorities."
> 
> but I don't see the backup CCIds in the LinkSummary message 
> described in
> 8.5.1:
> 
>  The format of the LinkSummary 
>    message is as follows: 
>     
>    <LinkSummary Message> ::= <Common Header> <LinkSummary> 
>     
>    The LinkSummary Object has the following format: 
>     
>     0                   1                   2                   3 
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>    |                          MessageId                            | 
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>    |                     Interface IP Address                      | 
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>    |                          NumWorking                           | 
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>    |                        NumProtection                          | 
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>    |                                                               | 
>    //                 (working channel subobjects)                // 
>    |                                                               | 
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>    |                                                               | 
>    //               (protection channel subobjects)               // 
>    |                                                               | 
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> 
> and the Common Header looks like
> 
>    In addition to the standard IP header, all LMP control-channel 
>    messages have the following common header: 
>     
>     0                   1                   2                   3 
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>    | Vers  |    Flags      |    Msg Type   |   (Reserved)          | 
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>    |                      Control Channel Id                       | 
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> 
> Am I missing something obvious?
> 
> Spencer
> 


From owner-mpls@UU.NET  Mon Aug 21 18:28:12 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA10334
	for <mpls-archive@lists.ietf.org>; Mon, 21 Aug 2000 18:28:11 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdgj10053;
	Mon, 21 Aug 2000 22:28:06 GMT
Received: by mail-control.mail.uu.net 
	id QQjdgj24631
	for mpls-outgoing; Mon, 21 Aug 2000 22:27:34 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjdgj24616
	for <mpls@mail-control.mail.uu.net>; Mon, 21 Aug 2000 22:27:24 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjdgj14627
	for <mpls@UU.NET>; Mon, 21 Aug 2000 18:27:19 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQjdgj09541
	for <mpls@UU.NET>; Mon, 21 Aug 2000 22:27:19 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA25273
	for <mpls@UU.NET>; Mon, 21 Aug 2000 18:27:16 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA19350
	for <mpls@UU.NET>; Mon, 21 Aug 2000 18:27:17 -0400 (EDT)
Message-ID: <39A1ACFF.50852E4E@marconi.com>
Date: Mon, 21 Aug 2000 18:28:15 -0400
From: David Charlap <david.charlap@marconi.com>
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: MPLS and CAC
References: <01c00baf$f4910160$dbb00b81@default.leeds.ac.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Erickson Trejo-Reyes wrote:
>
> While reading about MPLS specification (all my previous experience is
> on ATM networks), I have always found statements like: - a path is
> selected and resources are reserved in every node it traverses... Does
> that imply some sort of call admission control?

Any time resources are reserved (on any system, not just MPLS), there
must be admission control.  Otherwise, a router would be unable to
actually guarantee the resources it claims to be reserving.

This is done as a part of the signalling code (either RSVP-TE or
CR-LDP).

Of course, when tunnels are signalled for best-effort traffic, then no
admission control is necessary.

> (Many have told me that CAC is not considered for MPLS, at least for a
> telephony service on top of it). My question lies in the fact that, in
> order to reserve resources, first, some kind of effective bandwidth
> must be computed (am I wrong?).

It is possible to run telephony services over best-effort tunnels
(without reserving any resources).  This is the way internet-based phone
services run today.  It's not ideal, but it seems to be good enough for
many customers.

> Next, if resources are reserved, that means that in some cases the
> requested resources couldn't be granted (because they would be already
> reserved).

Obviously.  I think you may have misunderstood those who you were
talking to.

I don't think they meant that admission control isn't possible under
MPLS.  I think they meant that it is not used for best-effort traffic,
which is what everybody is signalling with MPLS today.

In the future, when people start signalling QoS-bound tunnels, there
will have to be some form of admission control, since it is always
possible for a resource to be exhausted.

> Finally, if a CAC mechanism is not due to be applied (for those who
> say so), how will a network warrant some bounds on performance metrics
> like delay and packet losses.

It won't be able to guarantee them obviously.

Those implementations that don't use any form of admission control will
either be unable to gurantee a reservation, or some form of
administrative action will be required to prevent the resources from
becoming oversubscribed.

-- David


From owner-mpls@UU.NET  Mon Aug 21 19:13:14 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10872
	for <mpls-archive@lists.ietf.org>; Mon, 21 Aug 2000 19:13:14 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdgm07081;
	Mon, 21 Aug 2000 23:13:06 GMT
Received: by mail-control.mail.uu.net 
	id QQjdgm08974
	for mpls-outgoing; Mon, 21 Aug 2000 23:12:35 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjdgm08959
	for <mpls@mail-control.mail.uu.net>; Mon, 21 Aug 2000 23:12:25 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjdgm20211;
	Mon, 21 Aug 2000 19:12:14 -0400 (EDT)
Received: from almso1.proxy.att.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: almso1.att.com [192.128.167.69])
	id QQjdgm06497;
	Mon, 21 Aug 2000 23:12:13 GMT
Received: from njb140r1.ems.att.com ([135.65.202.58])
	by almso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id TAA01813;
	Mon, 21 Aug 2000 19:12:12 -0400 (EDT)
Received: from njb140bh1.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
	id TAA14721; Mon, 21 Aug 2000 19:10:56 -0400 (EDT)
Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2652.35)
	id <R1GLSMPH>; Mon, 21 Aug 2000 19:12:12 -0400
Message-ID: <1B08859602C8D211B66F0000C0769CFA0223EF5F@njc240po03.mt.att.com>
From: "Fang, Luyuan, ALSVC" <luyuanfang@att.com>
To: "'Xipeng Xiao'" <xiaoxipe@cse.msu.edu>, danny@ambernetworks.com
Cc: te-wg@UU.NET, mpls@UU.NET
Subject: RE: "Two roads diverged in a yellow wood"
Date: Mon, 21 Aug 2000 19:12:08 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

I agree that we should merge the two MIBs into one, it is especially
important for the operators in today's multi-vendor environment. 

I would suggest the next discussion is which MIB to be used as a base.

Luyuan Fang


-----Original Message-----
From: Xipeng Xiao [mailto:xiaoxipe@cse.msu.edu]
Sent: Sunday, August 20, 2000 2:32 PM
To: danny@ambernetworks.com
Cc: te-wg@UU.NET; mpls@UU.NET
Subject: Re: "Two roads diverged in a yellow wood"


> As for what we do now, good question.  While I completely 
> agree with Randy/Vijay's comments, I also understand there's
> significant value in a single MIB.  Perhaps the right way
> to go is to merge the MIBs, with some wording surrounding
> the use of Kireeti's MIB as a base, and the "MPLS-TE-MIB"
> as the "full MIB".  While I'm guessing this goes against 
> all the "MPLS-TE-MIB" folks stand for,  and do realize it's
> not quite that simple, I'm also guessing it's the only 
> agreement that I foresee will result in a single MIB.

I agree with Danny here.

Xipeng



From owner-mpls@UU.NET  Mon Aug 21 20:46:45 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11555
	for <mpls-archive@lists.ietf.org>; Mon, 21 Aug 2000 20:46:45 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdgt29704;
	Tue, 22 Aug 2000 00:46:36 GMT
Received: by mail-control.mail.uu.net 
	id QQjdgs27904
	for mpls-outgoing; Tue, 22 Aug 2000 00:40:31 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjdgs27787
	for <mpls@mail-control.mail.uu.net>; Tue, 22 Aug 2000 00:35:10 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjdgr27513
	for <mpls@UU.NET>; Mon, 21 Aug 2000 20:19:29 -0400 (EDT)
Received: from mailhost.avici.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.246.215.9])
	id QQjdgr14812
	for <mpls@UU.NET>; Tue, 22 Aug 2000 00:19:14 GMT
Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37])
	by mailhost.avici.com (8.11.0/8.11.0) with ESMTP id e7M0JCf00731;
	Mon, 21 Aug 2000 20:19:12 -0400 (EDT)
Received: from curtis-lt.avici.com (localhost [127.0.0.1])
	by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id UAA28485;
	Mon, 21 Aug 2000 20:19:30 -0400 (EDT)
	(envelope-from curtis@curtis-lt.avici.com)
Message-Id: <200008220019.UAA28485@curtis-lt.avici.com>
To: David Charlap <david.charlap@marconi.com>
cc: mpls@UU.NET
Reply-To: curtis@avici.com
Subject: Re: MPLS and CAC 
In-reply-to: Your message of "Mon, 21 Aug 2000 18:28:15 EDT."
             <39A1ACFF.50852E4E@marconi.com> 
Date: Mon, 21 Aug 2000 20:19:30 -0400
From: Curtis Villamizar <curtis@avici.com>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <39A1ACFF.50852E4E@marconi.com>, David Charlap writes:
> Erickson Trejo-Reyes wrote:
> >
> > While reading about MPLS specification (all my previous experience is
> > on ATM networks), I have always found statements like: - a path is
> > selected and resources are reserved in every node it traverses... Does
> > that imply some sort of call admission control?
> 
> Any time resources are reserved (on any system, not just MPLS), there
> must be admission control.  Otherwise, a router would be unable to
> actually guarantee the resources it claims to be reserving.
> 
> This is done as a part of the signalling code (either RSVP-TE or
> CR-LDP).
> 
> Of course, when tunnels are signalled for best-effort traffic, then no
> admission control is necessary.

That's one way of doing things and it is the one that is most familiar
to people coming from an ATM background.  btw- Making no reservations
for best-effort traffic and not providing any means for best effort to
be traffic engineeered and route around congestion has been referred
to in the IRTF (see end2end-interest archives) as one component of
"worst-effort" service for best effort traffic.

There are others (or maybe its just me :) that have a different vision
of how to take advantage of what MPLS has to offer.  Please don't
start a flame war over whether there is One True Way to use MPLS.
There are at least two (probably more).  Here is an alternate.

While CAC is fully supported it can essentially be ignored by setting
a very high overbooking factor.  If that is done, some other means to
cause traffic to route around congestion is needed.  Typically the
metric used in the SPF is biased by the ingress to reflect loading
(heavily loaded links are made more costly in the OSPF cost sense or
given an artificially higher metric using ISIS terminology, either way
it is an CR-SPF).  

Behavior is significantly different (from the ATM/CAC way of doing
things) when a major change occurs in the network such as link
failure.  Tunnels will tend to reroute quickly, often more quickly
than information can be flooded back to indicate that bandwidth is
being used up or is no longer available.  Without overbooking, CAC
kicks in and some reservation request fail and must be retried.  With
the high overbooking, these tunnels come up anyway.  If there are
preferred services, they get preferred treatment so the overbooking
doesn't matter to them.  Best effort services temporarily get
squeezed.  The reason for doing things this way is that a very small
amount of loss can cause TCP to back off significantly, therefore
oversubscribing is much more preferrable to having CAC kick in and
losing 100% of the traffic until things settle down.

After the initial layout, if flooding indicates that some of the links
are significantly oversubscribed, then a good adaptivity
implementation can begin to optimize the layout.  Adaptivity is needed
regardless of whether oversubscription is used because some tunnels
which did not traverse a link that went down may need to be moved in
order to achieve a more efficient layout.

There is no One True Way to use MPLS.  This is just another way to use
MPLS for which some interest has been expressed.

Curtis


From owner-mpls@UU.NET  Mon Aug 21 21:06:02 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11696
	for <mpls-archive@lists.ietf.org>; Mon, 21 Aug 2000 21:06:02 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdgu10481;
	Tue, 22 Aug 2000 01:05:50 GMT
Received: by mail-control.mail.uu.net 
	id QQjdgu10647
	for mpls-outgoing; Tue, 22 Aug 2000 01:05:30 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjdgu10642
	for <mpls@mail-control.mail.uu.net>; Tue, 22 Aug 2000 01:05:29 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjdgu01324
	for <mpls@uu.net>; Mon, 21 Aug 2000 21:01:49 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjdgu08268
	for <mpls@uu.net>; Tue, 22 Aug 2000 01:01:34 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id VAA15593
	for mpls@uu.net; Mon, 21 Aug 2000 21:01:33 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjdgt28479
	for <mpls@mail-control.mail.uu.net>; Tue, 22 Aug 2000 00:54:40 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjdgt00262
	for <mpls@UU.NET>; Mon, 21 Aug 2000 20:52:24 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88])
	id QQjdgt26718
	for <mpls@UU.NET>; Tue, 22 Aug 2000 00:52:24 GMT
Received: from krakow.cisco.com (krakow.cisco.com [171.69.71.26])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id RAA02971;
	Mon, 21 Aug 2000 17:52:41 -0700 (PDT)
Received: from cisco.com (warsaw.cisco.com [171.69.71.119]) by krakow.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id RAA03377; Mon, 21 Aug 2000 17:52:46 -0700 (PDT)
Message-ID: <39A1CC85.2946E53B@cisco.com>
Date: Mon, 21 Aug 2000 17:42:45 -0700
From: Robert Raszuk <rraszuk@cisco.com>
Reply-To: rraszuk@cisco.com
Organization: Signature: http://www.employees.org/~raszuk/sig/
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jeff Bush <jbush@mitre.org>
CC: mpls@UU.NET
Subject: Re: general MPLS questions
References: <399D75CB.7934B07F@mitre.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Jeff,

See below ..

> Jeff Bush wrote:
> 
> Hello:
> 
> My colleagues and I have some questions on on MPLS that are more of a
> generic nature - as we are getting more knowledgeable about the
> subject.  Your comments would be most appreciated. We apologize if some
> topics have already been discussed on the list.
> 
> 1.  Is there any issue with MTU conflicts as shims are added to the
> original packet?

Sure. You need to make sure that your other network devices for example
LAN switches can handle large frames when you add MPLS header to already
1500 byte packet. Otherwise you need to fragment.

> 2.  Is it true (as some ISP folks have stated) that MPLS VPNs are not
> scalable?

No. Those who say this simply don't like the concept of prefix based
MPLS. The facts are that almost significant ISPs & SPs and Europe are
deploying mpls-vpns, Asia & Australia following. In US the first focus
was given towards TE with only a few ISPs deploying MPLS-VPNs today.
 
> 3.  Is MPLS currently providing traffic engineering only - using TOS
> bits.  Are there deployments out there that provide QoS (voice over
> data) using MPLS (without ATM, say)?

DiffServ is orthogonal to MPLS. MPLS can enhance the qos capabilities
but not substitute for the lack of basic IP qos. Today most of the
production environments is using E-LSPs /coping or writing directly 3
bits in EXP field in the MPLS header/ for packet prioritization in the
network.

> 4. Does LDP create a huge state machine and potentially clog the network
> (especially if the one or more LSPs are disturbed or disconnected)?

LDP state machine is defined here: draft-ietf-mpls-ldp-state-03.txt You
can judge if it's big or not. As far as cloging the network - I would
say is implementation dependent - but remember this is peer-to-peer
protocol.
 
> 5. If there are more than one LDP used in a hybrid environment, could
> there be conflicts regarding LSPs?

I don't understand your question. LDP process is one global per router
to distribute label bindings to it's peers.
 
> 6. Does variable length header processing cause high latency?

Without going into modern high speed lookup processors discussion the
short answer is no.

> 7. How does MPLS gets deployed in the "last mile" - between the egress
> router and the end-system - say on the LAN?

That really depends what is this "last mile". I don't really think that
MPSL to the end-system (since you brought LAN example) probably you mean
end-workstations is at all needed.
 
> 9. Say you have a path (LSP) established between four LSRs, A, B, C, and
> D.  Then when packets are being transmitted on this LSP, C fails.  What
> happens then?  We would be trying to establish another LSP by sending
> LDP packets to D from B.  Or should this be A which established the LSP
> first?  And, what happens to the packets in transit?

Are you asking about: 

A. Prefix based LSPs (established with IP routing plane + LDP)
B  TE LSPs ?

If A:

If there are other paths in the network let's say B - D then after the
IGP convergence B will send packets with a new label to D by itself. 

If B: 

If this is TE LSP then you again have two choices: Using FRR or not.
Anyhow locally protected or not at some point A will need to create new
LSP path to bypass C.

> 10. Is it true that MPLS is good for the network backbone only?

MPLS is good where it is needed and where is used wisely.

R.



From owner-mpls@UU.NET  Tue Aug 22 09:34:58 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05416
	for <mpls-archive@lists.ietf.org>; Tue, 22 Aug 2000 09:34:58 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdis27045;
	Tue, 22 Aug 2000 13:34:47 GMT
Received: by mail-control.mail.uu.net 
	id QQjdis17397
	for mpls-outgoing; Tue, 22 Aug 2000 13:34:27 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjdis17392
	for <mpls@mail-control.mail.uu.net>; Tue, 22 Aug 2000 13:34:14 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjdis20410
	for <mpls@UU.NET>; Tue, 22 Aug 2000 09:33:47 -0400 (EDT)
Received: from fortress.fnc.fujitsu.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: fortress.fnc.fujitsu.com [204.253.82.1])
	id QQjdis26054
	for <mpls@UU.NET>; Tue, 22 Aug 2000 13:33:27 GMT
Received: from rchsemx2.fnc.fujitsu.com (rchsemx2.fnc.fujitsu.com [167.254.105.13]) by fortress.fnc.fujitsu.com (8.8.7/FNC/ITG-2.0.1) with ESMTP id IAA24205 for <mpls@UU.NET>; Tue, 22 Aug 2000 08:33:25 -0500 (CDT)
Received: by rchsemx2.fnc.fujitsu.com with Internet Mail Service (5.5.2650.21)
	id <RFGJY5PX>; Tue, 22 Aug 2000 08:33:27 -0500
Message-ID: <F8B312027514D21197BC0000F81E25A30977C228@fnc03.fnc.fujitsu.com>
From: "Dawkins, Spencer" <Spencer.DAWKINS@fnc.fujitsu.com>
To: "'IETF MPLS mailing list'" <mpls@UU.NET>
Subject: RE: LinkSummary in draft-lang-mpls-lmp-01.txt missing fields?
Date: Tue, 22 Aug 2000 08:33:22 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Thanks, this helps a lot. If I understand this correctly, 

o the active control channel is listed as a working channel in the
LinkSummary, 

o any backup control channels are listed as protection channels in the
LinkSummary, pointing to the active control channel as the protected
channel,

o so switching to a backup control channel looks (roughly) like switching to
any other protection channel.

I think I understand how control channel switchover happens (section 4.1.3
is pretty clear), but am a little less clear on how data channel switchover
happens. Most of Section 7 deals with fault detection and isolation, not
with signaling that data channel switchover is occurring/has occurred.
Actually, this is a good place to start.

When a data channel fails and the upstream node (right?) sends an updated
LinkSummary (including the former protection channel listed as a working
channel), does this mean (1) the switchover has already occurred, or (2) the
switchover should occur? I'm guessing (2) from the end of section 7.2, but
I'm not sure I saw this explicitly stated.

I also noticed that there isn't a section 8...

Spencer

> -----Original Message-----
> From:	Jonathan Lang [SMTP:jplang@calient.net]
> Sent:	Monday, August 21, 2000 4:08 PM
> To:	'Dawkins, Spencer'; 'IETF MPLS mailing list'
> Subject:	RE: LinkSummary in draft-lang-mpls-lmp-01.txt missing
> fields?
> 
> Spencer,
>   Backup CCIds are listed in the Protection channel subobjects of the
> LinkSummary message.  Recall from the text in Section 8.5.1 that the "list
> of working channels MUST include the control channel".  The identification
> of backup control channels is mentioned in the Protection Channel
> subobject
> format.  To make things clear, I can add to the LinkSummary text  as
> follows
> (new text in <<>>):
> 
>    "The LinkSummary message contains a list of working channel 
>    subobjects and protection channel subobjects.  The list of working 
>    channels MUST include the control channel.  <<Any backup control
> channels
> that
>    are defined MUST be included in the list of protection channel
> subobjects.  Note that
>    a backup control channel can also be a working component link (provided
> it has
>    preemptive priority over the working component link), so it is possible
> to appear
>    in both the working channel subobject as well as the protection channel
> subobject.>>"
> 
> 
> -Jonathan
> 
> > -----Original Message-----
> > From: Dawkins, Spencer [mailto:Spencer.DAWKINS@fnc.fujitsu.com]
> > Sent: Thursday, August 17, 2000 12:26 PM
> > To: 'IETF MPLS mailing list'
> > Subject: LinkSummary in draft-lang-mpls-lmp-01.txt missing fields?
> > 
> > 
> > The text in Section 6.0 of this draft says
> > 
> >    "The LinkSummary message contains the primary 
> >    and backup CCIds, the IP address for the link (binding the 
> > CCIds to 
> >    the link IP addresses), and the local and remote LinkIds for each 
> >    component link and their associated priorities."
> > 
> > but I don't see the backup CCIds in the LinkSummary message 
> > described in
> > 8.5.1:
> > 
> >  The format of the LinkSummary 
> >    message is as follows: 
> >     
> >    <LinkSummary Message> ::= <Common Header> <LinkSummary> 
> >     
> >    The LinkSummary Object has the following format: 
> >     
> >     0                   1                   2                   3 
> >     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >    |                          MessageId                            | 
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >    |                     Interface IP Address                      | 
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >    |                          NumWorking                           | 
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >    |                        NumProtection                          | 
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >    |                                                               | 
> >    //                 (working channel subobjects)                // 
> >    |                                                               | 
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >    |                                                               | 
> >    //               (protection channel subobjects)               // 
> >    |                                                               | 
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> > 
> > and the Common Header looks like
> > 
> >    In addition to the standard IP header, all LMP control-channel 
> >    messages have the following common header: 
> >     
> >     0                   1                   2                   3 
> >     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >    | Vers  |    Flags      |    Msg Type   |   (Reserved)          | 
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >    |                      Control Channel Id                       | 
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> > 
> > Am I missing something obvious?
> > 
> > Spencer
> > 


From owner-mpls@UU.NET  Tue Aug 22 11:44:07 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08944
	for <mpls-archive@lists.ietf.org>; Tue, 22 Aug 2000 11:44:07 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdja08416;
	Tue, 22 Aug 2000 15:44:00 GMT
Received: by mail-control.mail.uu.net 
	id QQjdja20406
	for mpls-outgoing; Tue, 22 Aug 2000 15:43:24 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjdja20394
	for <mpls@mail-control.mail.uu.net>; Tue, 22 Aug 2000 15:43:20 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjdja16665
	for <mpls@UU.NET>; Tue, 22 Aug 2000 11:42:56 -0400 (EDT)
Received: from lux.chromisys.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: 193.140.adsl6.netlojix.net [207.71.200.140] (may be forged))
	id QQjdja07333
	for <mpls@UU.NET>; Tue, 22 Aug 2000 15:42:56 GMT
Received: by LUX with Internet Mail Service (5.5.2650.21)
	id <RDGLYR9Y>; Tue, 22 Aug 2000 08:42:55 -0700
Message-ID: <51DA0AB3D747D311832F005004827CC02CE9FD@LUX>
From: Jonathan Lang <jplang@calient.net>
To: "'Dawkins, Spencer'" <Spencer.DAWKINS@fnc.fujitsu.com>,
        "'IETF MPLS mailing list'" <mpls@UU.NET>
Subject: RE: LinkSummary in draft-lang-mpls-lmp-01.txt missing fields?
Date: Tue, 22 Aug 2000 08:42:54 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Spencer,
  See comments inline.

-Jonathan

> -----Original Message-----
> From: Dawkins, Spencer [mailto:Spencer.DAWKINS@fnc.fujitsu.com]
> Sent: Tuesday, August 22, 2000 6:33 AM
> To: 'IETF MPLS mailing list'
> Subject: RE: LinkSummary in draft-lang-mpls-lmp-01.txt missing fields?
> 
> 
> Thanks, this helps a lot. If I understand this correctly, 
> 
> o the active control channel is listed as a working channel in the
> LinkSummary, 
yes

> 
> o any backup control channels are listed as protection channels in the
> LinkSummary, pointing to the active control channel as the protected
> channel,
yes

> 
> o so switching to a backup control channel looks (roughly) 
> like switching to any other protection channel.
The actual switching to a backup control channel looks quite different from
switching to a protection channel because of the procedure that is used in
LMP for the switchover.  For the component links, the switchover to a
protection channel is handled by the signaling protocol (e.g., RSVP or LDP).
Having said this, the mechanism to map the protection channels to working
channels is the same for control channel and component links.
 
> 
> I think I understand how control channel switchover happens 
> (section 4.1.3 is pretty clear), but am a little less clear on how data 
> channel switchover happens. Most of Section 7 deals with fault detection
and 
> isolation, not with signaling that data channel switchover is
occurring/has occurred.
> Actually, this is a good place to start.
> 
> When a data channel fails and the upstream node (right?) 
> sends an updated LinkSummary (including the former protection channel
listed 
> as a working channel), does this mean (1) the switchover has already 
> occurred, or (2) the switchover should occur? I'm guessing (2) from the
end of 
> section 7.2, but I'm not sure I saw this explicitly stated.
The signaling of data channel switchover is not done in LMP, but is
relegated to the signaling protocol that is being used.  LMP is used to
exchange the working/protect channel mappings and to assist in the fault
isolation.  Therefore, using your above example, (1) would be the proper
operation.

> 
> I also noticed that there isn't a section 8...
yes, I had some numbering problems...


From owner-mpls@UU.NET  Tue Aug 22 12:10:54 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09756
	for <mpls-archive@lists.ietf.org>; Tue, 22 Aug 2000 12:10:53 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdjc01608;
	Tue, 22 Aug 2000 16:10:49 GMT
Received: by mail-control.mail.uu.net 
	id QQjdjc04355
	for mpls-outgoing; Tue, 22 Aug 2000 16:10:12 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjdjc04348
	for <mpls@mail-control.mail.uu.net>; Tue, 22 Aug 2000 16:10:12 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjdjc21641
	for <mpls@uu.net>; Tue, 22 Aug 2000 12:09:26 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjdjc07025
	for <mpls@uu.net>; Tue, 22 Aug 2000 16:08:56 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA19234
	for mpls@uu.net; Tue, 22 Aug 2000 12:08:55 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjdjc04262
	for <mpls@mail-control.mail.uu.net>; Tue, 22 Aug 2000 16:08:43 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjdjc25384
	for <mpls@UU.NET>; Tue, 22 Aug 2000 12:08:12 -0400 (EDT)
Received: from mailman.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailman.cisco.com [171.68.225.9])
	id QQjdjc29044
	for <mpls@UU.NET>; Tue, 22 Aug 2000 16:07:41 GMT
Received: from chmetz-pc.cisco.com ([10.19.239.36])
	by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id JAA01348
	for <mpls@UU.NET>; Tue, 22 Aug 2000 09:07:39 -0700 (PDT)
Message-Id: <4.3.1.2.20000822112156.024875a0@sj-email.cisco.com>
X-Sender: chmetz@sj-email.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Tue, 22 Aug 2000 12:11:23 -0700
To: mpls@UU.NET
From: Chris Metz <chmetz@cisco.com>
Subject: Forwarding Adjacency Setup Question
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_12766212==_.ALT"
Sender: owner-mpls@UU.NET
Precedence: bulk

--=====================_12766212==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

Hello-
I had a question forwarding adjacencies. 
http://search.ietf.org/internet-drafts/draft-ietf-mpls-lsp-hierarchy-00.txt 
states that

>In general, creation/termination of a forwarding adjacency and its
>    FA-LSP could be driven either by mechanisms outside of MPLS (e.g.,
>    via configuration control on the LSR at the head-end of the
>    adjacency), or by mechanisms within MPLS (e.g., as a result of the
>    LSR at the head-end of the adjacency receiving LSP setup requests
>    originated by some other LSRs).

I am confused by the latter statement and the implied sequence of events. 
It seems to be saying that

"some other LSRs" (let's say A in the example below) would signal 
RSVP/CRLDP messages (towards H) that pass thru a "head-end" LSR (C) who in 
turn would establish a FA-LSP to F.

A--B--C(head-end)====D====E====F--G--H

How does the A know to send an RSVP/CRLDP message thru C if the FA-LSP 
(C===F) does not already exist? Shouldn't the FA-LSP appear first as a link 
in A's topology database which would imply it has already been setup?

Thanks ...





Chris Metz
Lead IP Architect
Solutions Integration
Service Provider Line of Business
Cisco Systems
email: chmetz@cisco.com
offic phone: 408-525-3275
home office: 914-241-0423
pager: 800-365-4578
Internal URL: http://wwwin-people.cisco.com/chmetz/chmetz.htm  
--=====================_12766212==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
Hello-<br>
I had a question forwarding adjacencies.
<a href="http://search.ietf.org/internet-drafts/draft-ietf-mpls-lsp-hierarchy-00.txt" eudora="autourl">http://search.ietf.org/internet-drafts/draft-ietf-mpls-lsp-hierarchy-00.</a><a href="http://search.ietf.org/internet-drafts/draft-ietf-mpls-lsp-hierarchy-00.txt" eudora="autourl">txt</a>
states that<br>
<br>
<blockquote type=cite cite><font face="Courier New, Courier" size=2>In general, creation/termination of a forwarding adjacency and its<br>
&nbsp;&nbsp; FA-LSP could be driven either by mechanisms outside of MPLS (e.g.,<br>
&nbsp;&nbsp; via configuration control on the LSR at the head-end of the<br>
&nbsp;&nbsp; adjacency), or by mechanisms within MPLS (e.g., as a result of the<br>
&nbsp;&nbsp; LSR at the head-end of the adjacency receiving LSP setup requests<br>
&nbsp;&nbsp; originated by some other LSRs).</blockquote><br>
I am confused by the latter statement and the implied sequence of events. It seems to be saying that<br>
<br>
&quot;some other LSRs&quot; (let's say A in the example below) would signal RSVP/CRLDP messages (towards H) that pass thru a &quot;head-end&quot; LSR (C) who in turn would establish a FA-LSP to F. <br>
<br>
A--B--C(head-end)====D====E====F--G--H<br>
<br>
How does the A know to send an RSVP/CRLDP message thru C if the FA-LSP (C===F) does not already exist? Shouldn't the FA-LSP appear first as a link in A's topology database which would imply it has already been setup?<br>
<br>
Thanks ...<br>
<br>
&nbsp;</font><br>
<br>
<br>
<br>
<div>Chris Metz</div>
<div>Lead IP Architect</div>
<div>Solutions Integration</div>
<div>Service Provider Line of Business</div>
<div>Cisco Systems</div>
<div>email: chmetz@cisco.com</div>
<div>offic phone: 408-525-3275</div>
<div>home office: 914-241-0423</div>
<div>pager: 800-365-4578</div>
Internal URL: <a href="http://wwwin-people.cisco.com/chmetz/chmetz.htm" EUDORA=AUTOURL>http://wwwin-people.cisco.com/chmetz/chmetz.htm</a>&nbsp; 
</html>

--=====================_12766212==_.ALT--




From owner-mpls@UU.NET  Tue Aug 22 13:06:38 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10980
	for <mpls-archive@lists.ietf.org>; Tue, 22 Aug 2000 13:06:38 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdjg17418;
	Tue, 22 Aug 2000 17:06:25 GMT
Received: by mail-control.mail.uu.net 
	id QQjdjg20190
	for mpls-outgoing; Tue, 22 Aug 2000 17:05:52 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjdjg20172
	for <mpls@mail-control.mail.uu.net>; Tue, 22 Aug 2000 17:05:36 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjdjg04797
	for <mpls@UU.NET>; Tue, 22 Aug 2000 13:05:25 -0400 (EDT)
Received: from red.juniper.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: natint.juniper.net [207.17.136.129])
	id QQjdjg16349
	for <mpls@UU.NET>; Tue, 22 Aug 2000 17:05:24 GMT
Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90])
	by red.juniper.net (8.9.3/8.9.3) with ESMTP id KAA06266;
	Tue, 22 Aug 2000 10:05:24 -0700 (PDT)
Received: (from kireeti@localhost) by kummer.juniper.net (8.8.7/8.7.3) id KAA21708; Tue, 22 Aug 2000 10:04:43 -0700 (PDT)
Date: Tue, 22 Aug 2000 10:04:43 -0700 (PDT)
From: Kireeti Kompella <kireeti@juniper.net>
Message-Id: <200008221704.KAA21708@kummer.juniper.net>
To: chmetz@cisco.com, mpls@UU.NET
Subject: Re: Forwarding Adjacency Setup Question
Sender: owner-mpls@UU.NET
Precedence: bulk

> "some other LSRs" (let's say A in the example below) would signal 
> RSVP/CRLDP messages (towards H) that pass thru a "head-end" LSR (C) who in 
> turn would establish a FA-LSP to F.

So far, so good.  Note that the path the A computes is ABCDEFGH.

> A--B--C(head-end)====D====E====F--G--H

See section 4.3.2. (LSP regions) that explains how C determines
that an FA is needed to F.

> How does the A know to send an RSVP/CRLDP message thru C if the FA-LSP 
> (C===F) does not already exist? Shouldn't the FA-LSP appear first as a link 
> in A's topology database which would imply it has already been setup?

Well, as mentioned above, the path that A computed is ABCDEFGH; but
C intercepts this, and creates an FA to F (C is the head end of this
FA-LSP), then strips the FA from the original ERO, and sends the path
message for the A->H LSP directly to F.

C also advertises the CF FA-LSP so that others can see it and use it.

Kireeti.


From owner-mpls@UU.NET  Tue Aug 22 15:44:13 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14319
	for <mpls-archive@lists.ietf.org>; Tue, 22 Aug 2000 15:44:13 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdjq08247;
	Tue, 22 Aug 2000 19:44:03 GMT
Received: by mail-control.mail.uu.net 
	id QQjdjq24564
	for mpls-outgoing; Tue, 22 Aug 2000 19:43:44 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjdjq24559
	for <mpls@mail-control.mail.uu.net>; Tue, 22 Aug 2000 19:43:35 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjdjq07479
	for <mpls@uu.net>; Tue, 22 Aug 2000 15:43:15 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjdjq07631
	for <mpls@uu.net>; Tue, 22 Aug 2000 19:43:15 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA19267
	for mpls@uu.net; Tue, 22 Aug 2000 15:43:14 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjdjq24538
	for <mpls@mail-control.mail.uu.net>; Tue, 22 Aug 2000 19:42:59 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjdjq07327
	for <mpls@UU.NET>; Tue, 22 Aug 2000 15:42:38 -0400 (EDT)
Received: from dnsmx2pya.telcordia.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: dnsmx2pya.telcordia.com [128.96.20.32])
	id QQjdjq11175
	for <mpls@UU.NET>; Tue, 22 Aug 2000 19:42:37 GMT
Received: from notes949.cc.telcordia.com (notes949a.cc.telcordia.com [128.96.246.8])
	by dnsmx2pya.telcordia.com (8.9.3/8.9.3) with SMTP id PAA06191
	for <mpls@UU.NET>; Tue, 22 Aug 2000 15:41:40 -0400 (EDT)
Received: by notes949.cc.telcordia.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 85256943.006C2DF1 ; Tue, 22 Aug 2000 15:41:36 -0400
X-Lotus-FromDomain: TELCORDIA
From: "Hong Liao" <hliao@telcordia.com>
To: mpls@UU.NET
cc: "Hong Liao" <hliao@telcordia.com>
Message-ID: <85256943.006C2D05.00@notes949.cc.telcordia.com>
Date: Tue, 22 Aug 2000 15:40:39 -0400
Subject: rsvp questions
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-mpls@UU.NET
Precedence: bulk



Hi,

I have questions about rsvp-te:

1) Extended tunnel ID:  It is normally set to all zeros(please refer to the page
41of draft-ietf-mpls-rsvp-lsp-tunnel-06.txt), but the page 13 of this draft said
that this field can be put the ingress node's ip address, so I was wondering
right now which one is being implemented in the industry market?

2)  Can LSP ID and tunnel ID be the same if there is only one session setup
between sender and receiver, and no reroute happens?

Thanks,

Julia





From owner-mpls@UU.NET  Tue Aug 22 16:02:13 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14682
	for <mpls-archive@lists.ietf.org>; Tue, 22 Aug 2000 16:02:13 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdjs21425;
	Tue, 22 Aug 2000 20:02:07 GMT
Received: by mail-control.mail.uu.net 
	id QQjdjs00114
	for mpls-outgoing; Tue, 22 Aug 2000 20:01:33 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjdjs00043
	for <mpls@mail-control.mail.uu.net>; Tue, 22 Aug 2000 20:01:29 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjdjs10774
	for <mpls@uu.net>; Tue, 22 Aug 2000 16:01:18 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjdjs20665
	for <mpls@uu.net>; Tue, 22 Aug 2000 20:01:17 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA22393
	for mpls@uu.net; Tue, 22 Aug 2000 16:01:17 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjdjs28871
	for <mpls@mail-control.mail.uu.net>; Tue, 22 Aug 2000 20:00:48 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjdjs14653
	for <mpls@UU.NET>; Tue, 22 Aug 2000 16:00:39 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjdjs19966
	for <mpls@UU.NET>; Tue, 22 Aug 2000 20:00:23 GMT
Received: from swallow-pc01 (ch2-dhcp134-192.cisco.com [161.44.134.192])
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id QAA22251;
	Tue, 22 Aug 2000 16:00:17 -0400 (EDT)
Message-Id: <4.1.20000822155954.009f9620@pilgrim.cisco.com>
X-Sender: swallow@pilgrim.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 22 Aug 2000 16:06:03 -0400
To: "Hong Liao" <hliao@telcordia.com>, mpls@UU.NET
From: George Swallow <swallow@cisco.com>
Subject: Re: rsvp questions
Cc: "Hong Liao" <hliao@telcordia.com>
In-Reply-To: <85256943.006C2D05.00@notes949.cc.telcordia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-mpls@UU.NET
Precedence: bulk

At 03:40 PM 8/22/00 -0400, Hong Liao wrote:
>
>
>Hi,
>
>I have questions about rsvp-te:
>
>1) Extended tunnel ID:  It is normally set to all zeros(please refer to the 
>page
>41of draft-ietf-mpls-rsvp-lsp-tunnel-06.txt), but the page 13 of this draft 
>said
>that this field can be put the ingress node's ip address, so I was wondering
>right now which one is being implemented in the industry market?

The Cisco implementation puts the ingress node's ip address in this field.

>2)  Can LSP ID and tunnel ID be the same if there is only one session setup
>between sender and receiver, and no reroute happens?

The two spaces are independent.  In fact LSP ID need only be unique within the scope 
of a particular tunnel.  So you could always set LSP_ID = Tunnel_ID if there were only
one LSP associated with the tunnel for all time.  But they are different identifiersm so I wouldn't
call them the "same", they just happen to have the "same value".

...George




From owner-mpls@UU.NET  Tue Aug 22 16:14:13 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14873
	for <mpls-archive@lists.ietf.org>; Tue, 22 Aug 2000 16:14:12 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdjs03973;
	Tue, 22 Aug 2000 20:14:05 GMT
Received: by mail-control.mail.uu.net 
	id QQjdjs08614
	for mpls-outgoing; Tue, 22 Aug 2000 20:13:34 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjdjs08609
	for <mpls@mail-control.mail.uu.net>; Tue, 22 Aug 2000 20:13:32 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjdjs13123
	for <mpls@UU.NET>; Tue, 22 Aug 2000 16:13:29 -0400 (EDT)
Received: from icarian.ZAFFIRE.COM by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ATHM-64-232-xxx-132.home.net [64.232.69.132] (may be forged))
	id QQjdjs29535
	for <mpls@UU.NET>; Tue, 22 Aug 2000 20:13:13 GMT
Received: by ICARIAN with Internet Mail Service (5.5.2650.21)
	id <QX145A85>; Tue, 22 Aug 2000 13:21:19 -0700
Message-ID: <4D3F9F2BEC58D4118FCE009027B0A66213619F@ICARIAN>
From: Eric Gray <EGray@zaffire.com>
To: "'Kireeti Kompella'" <kireeti@juniper.net>
Cc: chmetz@cisco.com, mpls@UU.NET
Subject: RE: Forwarding Adjacency Setup Question
Date: Tue, 22 Aug 2000 13:21:15 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Kireeti,

	Alternatively, A may have computed a path that 
is AB(X)GH where (X) is an AS, or an address prefix, 
including routers C, D, E and F.  When C received the 
ERO containing (X) - which it is a part of - it could 
be configured to set up an FA-LSP through the AS.  
Correct?

> -----Original Message-----
> From: Kireeti Kompella [mailto:kireeti@juniper.net]
> Sent: Tuesday, August 22, 2000 10:05 AM
> To: chmetz@cisco.com; mpls@UU.NET
> Subject: Re: Forwarding Adjacency Setup Question
> 
> 
> > "some other LSRs" (let's say A in the example below) would signal 
> > RSVP/CRLDP messages (towards H) that pass thru a "head-end" 
> LSR (C) who in 
> > turn would establish a FA-LSP to F.
> 
> So far, so good.  Note that the path the A computes is ABCDEFGH.
> 
> > A--B--C(head-end)====D====E====F--G--H
> 
> See section 4.3.2. (LSP regions) that explains how C determines
> that an FA is needed to F.
> 
> > How does the A know to send an RSVP/CRLDP message thru C if 
> the FA-LSP 
> > (C===F) does not already exist? Shouldn't the FA-LSP appear 
> first as a link 
> > in A's topology database which would imply it has already 
> been setup?
> 
> Well, as mentioned above, the path that A computed is ABCDEFGH; but
> C intercepts this, and creates an FA to F (C is the head end of this
> FA-LSP), then strips the FA from the original ERO, and sends the path
> message for the A->H LSP directly to F.
> 
> C also advertises the CF FA-LSP so that others can see it and use it.
> 
> Kireeti.
> 


From owner-mpls@UU.NET  Wed Aug 23 09:46:37 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11585
	for <mpls-archive@lists.ietf.org>; Wed, 23 Aug 2000 09:46:36 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdml14295;
	Wed, 23 Aug 2000 13:46:31 GMT
Received: by mail-control.mail.uu.net 
	id QQjdml02190
	for mpls-outgoing; Wed, 23 Aug 2000 13:45:59 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjdml02185
	for <mpls@mail-control.mail.uu.net>; Wed, 23 Aug 2000 13:45:55 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjdml25017
	for <mpls@uu.net>; Wed, 23 Aug 2000 09:45:45 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11])
	id QQjdml08328
	for <mpls@uu.net>; Wed, 23 Aug 2000 13:45:45 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id GAA27435
	for <mpls@uu.net>; Wed, 23 Aug 2000 06:46:02 -0700 (PDT)
Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA12645 for mpls@uu.net; Wed, 23 Aug 2000 09:45:43 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjdmf15083
	for <mpls@mail-control.mail.uu.net>; Wed, 23 Aug 2000 12:16:11 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjdmf11120
	for <mpls@uu.net>; Wed, 23 Aug 2000 08:16:07 -0400 (EDT)
Received: from ns01.newbridge.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ns01.newbridge.com [192.75.23.67])
	id QQjdmf15227
	for <mpls@uu.net>; Wed, 23 Aug 2000 12:16:06 GMT
Received: (from smtpd@localhost)
	by ns01.newbridge.com (8.9.2/8.9.2) id IAA17300
	for <mpls@uu.net>; Wed, 23 Aug 2000 08:08:51 -0400 (EDT)
Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1.ca.newbridge.com"
 via SMTP by ns01.newbridge.com, id smtpdBAA5i1HA_; Wed Aug 23 08:08:46 2000
Received: from kanmail02.ca.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP for mpls@uu.net; Wed, 23 Aug 2000 08:13:58 -0400
Received: from newbridge.com ([138.120.51.119])
          by kanmail02.ca.newbridge.com (Netscape Messaging Server 3.6)
           with ESMTP id AAA1430 for <mpls@uu.net>;
          Wed, 23 Aug 2000 08:15:17 -0400
Message-Id: <39A3C08B.C7B0700F@newbridge.com>
Date: Wed, 23 Aug 2000 08:16:12 -0400
From: "HANSEN CHAN" <hansen.chan@alcatel.com>
X-Mailer: Mozilla 4.73 [en] (Win95; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Using DU Mode of LDP
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Dear all,

In draft-martini-l2circuit-trans-mpls-01.txt (and also another similar
draft draft-malis-sonet-ces-mpls-00.txt), the use of downstream
unsolicited mode of LDP is specified to setup VC LSP. Is there any
technical reasons that prevent using RSVP-TE or downstream on demand
mode of LDP?

Thanks,
Hansen



From owner-mpls@UU.NET  Wed Aug 23 10:58:58 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13813
	for <mpls-archive@lists.ietf.org>; Wed, 23 Aug 2000 10:58:58 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdmp00947;
	Wed, 23 Aug 2000 14:58:46 GMT
Received: by mail-control.mail.uu.net 
	id QQjdmp19361
	for mpls-outgoing; Wed, 23 Aug 2000 14:58:19 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjdmp19354
	for <mpls@mail-control.mail.uu.net>; Wed, 23 Aug 2000 14:58:18 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjdmp09147
	for <mpls@uu.net>; Wed, 23 Aug 2000 10:58:10 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjdmp08274
	for <mpls@uu.net>; Wed, 23 Aug 2000 14:57:54 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA20968
	for mpls@uu.net; Wed, 23 Aug 2000 10:57:54 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjdmp19294
	for <mpls@mail-control.mail.uu.net>; Wed, 23 Aug 2000 14:57:19 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjdmp08910
	for <mpls@UU.NET>; Wed, 23 Aug 2000 10:56:59 -0400 (EDT)
Received: from funnel.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQjdmp07463
	for <mpls@UU.NET>; Wed, 23 Aug 2000 14:56:44 GMT
Received: from lir.cisco.com (lir-hme1.cisco.com [171.69.209.57]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA06803; Wed, 23 Aug 2000 10:56:43 -0400 (EDT)
Received: from localhost (swallow@localhost) by lir.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id KAA05151; Wed, 23 Aug 2000 10:56:42 -0400 (EDT)
Message-Id: <200008231456.KAA05151@lir.cisco.com>
X-Authentication-Warning: lir.cisco.com: swallow owned process doing -bs
To: "HANSEN CHAN" <hansen.chan@alcatel.com>
cc: mpls@UU.NET, swallow@cisco.com
Subject: Re: Using DU Mode of LDP 
In-reply-to: Your message of "Wed, 23 Aug 2000 08:16:12 EDT."
             <39A3C08B.C7B0700F@newbridge.com> 
Date: Wed, 23 Aug 2000 10:56:42 -0400
From: George Swallow <swallow@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

Hansen -

The authors may have a more definitive answer, but my quess would be
that they don't really require downstream unsolicited, only that it be
able to work with downstream unsolicited.  That is, they're not
depending on RSVP or LDP to communicate anything end-to-end.

...George

==================================================================
George Swallow       Cisco Systems                   (978) 244-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824



From owner-mpls@UU.NET  Wed Aug 23 12:23:29 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17619
	for <mpls-archive@lists.ietf.org>; Wed, 23 Aug 2000 12:23:29 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdmv04635;
	Wed, 23 Aug 2000 16:23:23 GMT
Received: by mail-control.mail.uu.net 
	id QQjdmv20242
	for mpls-outgoing; Wed, 23 Aug 2000 16:22:40 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjdmv20201
	for <mpls@mail-control.mail.uu.net>; Wed, 23 Aug 2000 16:22:31 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjdmv01878
	for <mpls@uu.net>; Wed, 23 Aug 2000 12:22:27 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjdmv03912
	for <mpls@uu.net>; Wed, 23 Aug 2000 16:22:27 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA03373
	for mpls@uu.net; Wed, 23 Aug 2000 12:22:26 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjdmv20036
	for <mpls@mail-control.mail.uu.net>; Wed, 23 Aug 2000 16:21:50 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjdmv26285
	for <mpls@UU.NET>; Wed, 23 Aug 2000 12:21:48 -0400 (EDT)
Received: from dnsmx1rrc.telcordia.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: dnsmx1rrc.telcordia.com [128.96.20.41])
	id QQjdmv03041
	for <mpls@UU.NET>; Wed, 23 Aug 2000 16:21:29 GMT
Received: from notes949.cc.telcordia.com (notes949a.cc.telcordia.com [128.96.246.8])
	by dnsmx1rrc.telcordia.com (8.9.3/8.9.2) with SMTP id MAA13586
	for <mpls@UU.NET>; Wed, 23 Aug 2000 12:19:30 -0400 (EDT)
Received: by notes949.cc.telcordia.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 85256944.0059AAC6 ; Wed, 23 Aug 2000 12:19:24 -0400
X-Lotus-FromDomain: TELCORDIA
From: "Hong Liao" <hliao@telcordia.com>
To: mpls@UU.NET
cc: "Hong Liao" <hliao@telcordia.com>
Message-ID: <85256944.0059AA59.00@notes949.cc.telcordia.com>
Date: Wed, 23 Aug 2000 12:18:27 -0400
Subject: L3PID
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-mpls@UU.NET
Precedence: bulk



Hi,

I have questions for the L3PID.

It is an identifier of the layer 3 protocol using this path, it might not be the
IP protocol only, right?
As I know, if it is IP protocol using this path, the L3PID is 0x0800.

Thanks,

Julia





From owner-mpls@UU.NET  Wed Aug 23 12:40:27 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18078
	for <mpls-archive@lists.ietf.org>; Wed, 23 Aug 2000 12:40:26 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdmw16196;
	Wed, 23 Aug 2000 16:40:17 GMT
Received: by mail-control.mail.uu.net 
	id QQjdmw22251
	for mpls-outgoing; Wed, 23 Aug 2000 16:39:52 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjdmw22246
	for <mpls@mail-control.mail.uu.net>; Wed, 23 Aug 2000 16:39:42 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjdmw29226
	for <mpls@UU.NET>; Wed, 23 Aug 2000 12:39:37 -0400 (EDT)
Received: from alpha.tellium.com by wodc7mr1.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: alpha.tellium.com [151.198.92.2])
	id QQjdmw22102
	for <mpls@UU.NET>; Wed, 23 Aug 2000 16:39:36 GMT
Received: from tellium.com (node1.tellium.com [151.198.92.15])
	by alpha.tellium.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e7NGWRX26460;
	Wed, 23 Aug 2000 12:32:27 -0400 (EDT)
Message-ID: <39A3FE13.6D0E3824@tellium.com>
Date: Wed, 23 Aug 2000 12:38:43 -0400
From: Vasanthi Thirumalai <vasanthi@tellium.com>
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Aditya Bhatnagar <Aditya.Bhatnagar@cwusa.com>
CC: Samantha Quadros <SQuadros@narus.com>, "'mpls@UU.NET'" <mpls@UU.NET>,
        "'mpls-ops@mplsrc.com'" <mpls-ops@mplsrc.com>
Subject: Re: Port
References: <D233CC5C9935D311A1AA00A0C9E45B0B01175016@hermes.narus.com> <39A3F463.50B3ECD4@cwusa.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


Aditya,

Aditya Bhatnagar wrote:

> MPLS resides at Layer 2.  Why would there be a port number?

    MPLS control plane resides in layer 3 and that is why a port number
had to be assigned to handle the control plane traffic.

-Vasanthi

>
>
> Aditya
>
> Samantha Quadros wrote:
>
> > Hi
> >
> > Has a port number been permanantly for MPLS?
> >
> > Samantha



From owner-mpls@UU.NET  Wed Aug 23 13:03:57 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18895
	for <mpls-archive@lists.ietf.org>; Wed, 23 Aug 2000 13:03:57 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdmy02377;
	Wed, 23 Aug 2000 17:03:44 GMT
Received: by mail-control.mail.uu.net 
	id QQjdmy00942
	for mpls-outgoing; Wed, 23 Aug 2000 17:03:26 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjdmy00854
	for <mpls@mail-control.mail.uu.net>; Wed, 23 Aug 2000 17:03:21 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjdmy08384
	for <mpls@UU.NET>; Wed, 23 Aug 2000 13:03:17 -0400 (EDT)
Received: from smtprch1.nortel.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtprch1.nortelnetworks.com [192.135.215.14])
	id QQjdmy01951
	for <mpls@UU.NET>; Wed, 23 Aug 2000 17:03:16 GMT
Received: from zrchb213.us.nortel.com (actually zrchb213) 
          by smtprch1.nortel.com; Wed, 23 Aug 2000 11:47:24 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <RNY5KLAW>; Wed, 23 Aug 2000 11:46:07 -0500
Message-ID: <B7F2E7B20E27D41196910000F8BDCBD6010BCD77@zmerd009.ca.nortel.com>
From: "Ajay Malik" <malika@nortelnetworks.com>
To: "'Rob Jaeger'" <rfj@cs.umd.edu>
Cc: mpls@UU.NET
Subject: negotiations in CR-LDP
Date: Wed, 23 Aug 2000 11:46:03 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C00D21.A023B370"
Sender: owner-mpls@UU.NET
Precedence: bulk

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_01C00D21.A023B370
Content-Type: text/plain;
	charset="iso-8859-1"

Hi,
  I have a question regarding negotiations in CR-LDP: 
     LER--LSR1--LSR2---LSR3--LER

  if the LSR2 finds that sufficient resources are not available and the
parameter 
  values are negotiable what does it exactly does ? 
    * does it modify the setup and sends it to LSR3 irrespective of anything
?
    * does it first negotiate with LSR1 ? how ? (take example of PDR in
Delay 
      sensitive service) 
    
Ajay
  
    
 

------_=_NextPart_001_01C00D21.A023B370
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>negotiations in CR-LDP</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Hi,</FONT>
<BR><FONT SIZE=2>&nbsp; I have a question regarding negotiations in CR-LDP: </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; LER--LSR1--LSR2---LSR3--LER</FONT>
</P>

<P><FONT SIZE=2>&nbsp; if the LSR2 finds that sufficient resources are not available and the parameter </FONT>
<BR><FONT SIZE=2>&nbsp; values are negotiable what does it exactly does ? </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; * does it modify the setup and sends it to LSR3 irrespective of anything ?</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; * does it first negotiate with LSR1 ? how ? (take example of PDR in Delay </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; sensitive service) </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=2>Ajay</FONT>
<BR><FONT SIZE=2>&nbsp; </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=2>&nbsp;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C00D21.A023B370--


From owner-mpls@UU.NET  Wed Aug 23 13:30:19 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19344
	for <mpls-archive@lists.ietf.org>; Wed, 23 Aug 2000 13:30:19 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdna25480;
	Wed, 23 Aug 2000 17:30:13 GMT
Received: by mail-control.mail.uu.net 
	id QQjdmz07828
	for mpls-outgoing; Wed, 23 Aug 2000 17:29:46 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjdmz07823
	for <mpls@mail-control.mail.uu.net>; Wed, 23 Aug 2000 17:29:34 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjdmz07495
	for <mpls@UU.NET>; Wed, 23 Aug 2000 13:29:25 -0400 (EDT)
Received: from alpha.tellium.com by wodc7mr1.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: alpha.tellium.com [151.198.92.2])
	id QQjdmz24559
	for <mpls@UU.NET>; Wed, 23 Aug 2000 17:29:10 GMT
Received: from tellium.com (node1.tellium.com [151.198.92.15])
	by alpha.tellium.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e7NHM3X28661;
	Wed, 23 Aug 2000 13:22:03 -0400 (EDT)
Message-ID: <39A409B3.DC1DB591@tellium.com>
Date: Wed, 23 Aug 2000 13:28:19 -0400
From: Vasanthi Thirumalai <vasanthi@tellium.com>
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Aditya Bhatnagar <Aditya.Bhatnagar@cwusa.com>,
        Samantha Quadros <SQuadros@narus.com>, "'mpls@UU.NET'" <mpls@UU.NET>,
        "'mpls-ops@mplsrc.com'" <mpls-ops@mplsrc.com>
Subject: Re: Port
References: <D233CC5C9935D311A1AA00A0C9E45B0B01175016@hermes.narus.com> <39A3F463.50B3ECD4@cwusa.com> <39A3FE13.6D0E3824@tellium.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


Based on a private mail that I received in response to this mail, a little
more explanantion is in order.

LDP and RSVP-TE are two MPLS control-plane protocols. LDP 'Hello' messages
are exchanged over the UDP port 646. LDP session messages are exchanged
over the TCP port 646.
RSVP-TE runs over raw IP and its protocol number is 46( same as defined in
RFC 2205 )

-Vasanthi
Vasanthi Thirumalai wrote:

> Aditya,
>
> Aditya Bhatnagar wrote:
>
> > MPLS resides at Layer 2.  Why would there be a port number?
>
>     MPLS control plane resides in layer 3 and that is why a port number
> had to be assigned to handle the control plane traffic.
>
> -Vasanthi
>
> >
> >
> > Aditya
> >
> > Samantha Quadros wrote:
> >
> > > Hi
> > >
> > > Has a port number been permanantly for MPLS?
> > >
> > > Samantha



From owner-mpls@UU.NET  Wed Aug 23 13:44:06 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19600
	for <mpls-archive@lists.ietf.org>; Wed, 23 Aug 2000 13:44:05 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdna00507;
	Wed, 23 Aug 2000 17:43:57 GMT
Received: by mail-control.mail.uu.net 
	id QQjdna08503
	for mpls-outgoing; Wed, 23 Aug 2000 17:43:22 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjdna08497
	for <mpls@mail-control.mail.uu.net>; Wed, 23 Aug 2000 17:43:20 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjdna15013
	for <mpls@uu.net>; Wed, 23 Aug 2000 13:43:02 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjdna04425
	for <mpls@uu.net>; Wed, 23 Aug 2000 17:43:02 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA16416
	for mpls@uu.net; Wed, 23 Aug 2000 13:43:01 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjdna08463
	for <mpls@mail-control.mail.uu.net>; Wed, 23 Aug 2000 17:42:06 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjdna10007
	for <mpls@UU.NET>; Wed, 23 Aug 2000 13:41:51 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88])
	id QQjdna28848
	for <mpls@UU.NET>; Wed, 23 Aug 2000 17:41:35 GMT
Received: from rhthomas-sun2.cisco.com (rhthomas-sun2.cisco.com [161.44.134.47])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id KAA00541
	for <mpls@UU.NET>; Wed, 23 Aug 2000 10:41:53 -0700 (PDT)
Received: (rhthomas@localhost) by rhthomas-sun2.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id NAA27213; Wed, 23 Aug 2000 13:41:34 -0400 (EDT)
Date: Wed, 23 Aug 2000 13:41:34 -0400 (EDT)
Message-Id: <200008231741.NAA27213@rhthomas-sun2.cisco.com>
From: Bob Thomas <rhthomas@cisco.com>
To: mpls@UU.NET
Subject: Clarification of LDP session establishment procedure
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

The procedure for session establishment in Section 2.5.2 (Transport
Connection Establishment) of draft-ietf-mpls-ldp-10.txt is under
specified.

The following addition to draft-ietf-mpls-ldp-10.txt clarifies the
procedure:

 * page 16 add new paragraph following step (3):

   Note that when an LSR sends a Hello it selects the transport address
   for its end of the session connection and uses the Hello to advertise
   the address, either explicitly by including it in an optional
   Transport Address TLV or implicitly by omitting the TLV and using it
   as the Hello source address.

   An LSR MUST advertise the same transport address in all Hellos that
   advertise the same label space.  This requirement ensures that two
   LSRs linked by multiple Hello adjacencies using the same label spaces
   play the same connection establishment role for each adjacency.

Attached below is the complete revised text for Section 2.5.2 with the
change highlighted.


Note that these additions are intended as a clarification of the
procedure, not a change to the procedure.

This clarfication will be added to draft-ietf-mpls-ldp-11.txt to be posted
shortly.


Bob


2.5.2. Transport Connection Establishment

   The exchange of Hellos results in the creation of a Hello adjacency
   at LSR1 that serves to bind the link (L) and the label spaces LSR1:a
   and LSR2:b.

     1.  If LSR1 does not already have an LDP session for the exchange
         of label spaces LSR1:a and LSR2:b it attempts to open a TCP
         connection for a new LDP session with LSR2.

         LSR1 determines the transport addresses to be used at its end
         (A1) and LSR2's end (A2) of the LDP TCP connection.  Address A1
         is determined as follows:

         a.  If LSR1 uses the Transport Address optional object (TLV) in
             Hello's it sends to LSR2 to advertise an address, A1 is the
             address LSR1 advertises via the optional object;

         b.  If LSR1 does not use the Transport Address optional object,
             A1 is the source address used in Hellos it sends to LSR2.

         Similarly, address A2 is determined as follows:

         a.  If LSR2 uses the Transport Address optional object, A2 is
             the address LSR2 advertises via the optional object;

         b.  If LSR2 does not use the Transport Address optional object,
             A2 is the source address in Hellos received from LSR2.

     2.  LSR1 determines whether it will play the active or passive role
         in session establishment by comparing addresses A1 and A2 as
         unsigned integers.  If A1 > A2, LSR1 plays the active role;
         otherwise it is passive.

         The procedure for comparing A1 and A2 as unsigned integers is:

           - If A1 and A2 are not in the same address family, they are
             incomparable, and no session can be established.

           - Let U1 be the abstract unsigned integer obtained by
             treating A1 as a sequence of bytes, where the byte which
             appears earliest in the message is the most significant
             byte of the integer and the byte which appears latest in
             the message is the least significant byte of the integer.

             Let U2 be the abstract unsigned integer obtained from A2 in
             a similar manner.

           - Compare U1 with U2.  If U1 > U2, then A1 > A2; if U1 < U2,
             then A1 < A2.

     3.  If LSR1 is active, it attempts to establish the LDP TCP
         connection by connecting to the well-known LDP port at address
         A2.  If LSR1 is passive, it waits for LSR2 to establish the LDP
         TCP connection to its well-known LDP port.

   Note that when an LSR sends a Hello it selects the transport address    ***
   for its end of the session connection and uses the Hello to advertise   ***
   the address, either explicitly by including it in an optional           ***
   Transport Address TLV or implicitly by omitting the TLV and using it    ***
   as the Hello source address.                                            ***
                                                                           ***
   An LSR MUST advertise the same transport address in all Hellos that     ***
   advertise the same label space.  This requirement ensures that two      ***
   LSRs linked by multiple Hello adjacencies using the same label spaces   ***
   play the same connection establishment role for each adjacency.         ***



From owner-mpls@UU.NET  Wed Aug 23 14:16:16 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20444
	for <mpls-archive@lists.ietf.org>; Wed, 23 Aug 2000 14:16:16 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdnd28857;
	Wed, 23 Aug 2000 18:16:11 GMT
Received: by mail-control.mail.uu.net 
	id QQjdnd22867
	for mpls-outgoing; Wed, 23 Aug 2000 18:15:29 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjdnd22837
	for <mpls@mail-control.mail.uu.net>; Wed, 23 Aug 2000 18:15:09 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjdnd16847
	for <mpls@UU.NET>; Wed, 23 Aug 2000 14:15:05 -0400 (EDT)
Received: from alpha.tellium.com by wodc7mr2.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: alpha.tellium.com [151.198.92.2])
	id QQjdnc24192
	for <mpls@UU.NET>; Wed, 23 Aug 2000 18:14:51 GMT
Received: from tellium.com (node1.tellium.com [151.198.92.15])
	by alpha.tellium.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e7NI7qA00999;
	Wed, 23 Aug 2000 14:07:52 -0400 (EDT)
Message-ID: <39A41470.892F7BB5@tellium.com>
Date: Wed, 23 Aug 2000 14:14:08 -0400
From: Vasanthi Thirumalai <vasanthi@tellium.com>
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Ajay Malik <malika@nortelnetworks.com>
CC: mpls@UU.NET
Subject: Re: negotiations in CR-LDP
References: <B7F2E7B20E27D41196910000F8BDCBD6010BCD77@zmerd009.ca.nortel.com>
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi,
<br>&nbsp;&nbsp;&nbsp; In the example that you have given, LSR2 would modify
the PDR(it may substitute it with a smaller value) and send the Label request
to LSR3.
<p>In general an LSR that cannot satisfy a negotiable traffic parameter
request, replaces it with a smaller&nbsp; value and propagates the Label
request. Label Mapping carries the final negotiated value. The LSRs along
the path, then adjust the resources they&nbsp; reserved for the path, based
on the values conveyed in&nbsp; the Label Mapping message.
<p>-Vasanthi
<p>Ajay Malik wrote:
<br><font size=-1>Hi,</font>
<blockquote TYPE=CITE><font size=-1>&nbsp; I have a question regarding
negotiations in CR-LDP:</font>
<br><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp; LER--LSR1--LSR2---LSR3--LER</font>
<p><font size=-1>&nbsp; if the LSR2 finds that sufficient resources are
not available and the parameter</font>
<br><font size=-1>&nbsp; values are negotiable what does it exactly does
?</font>
<br><font size=-1>&nbsp;&nbsp;&nbsp; * does it modify the setup and sends
it to LSR3 irrespective of anything ?</font>
<br><font size=-1>&nbsp;&nbsp;&nbsp; * does it first negotiate with LSR1
? how ? (take example of PDR in Delay</font>
<br><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; sensitive service)</font>
<p><font size=-1>Ajay</font>
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;</blockquote>
</html>



From owner-mpls@UU.NET  Wed Aug 23 14:16:17 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20450
	for <mpls-archive@lists.ietf.org>; Wed, 23 Aug 2000 14:16:17 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdnd25293;
	Wed, 23 Aug 2000 18:16:06 GMT
Received: by mail-control.mail.uu.net 
	id QQjdnd22857
	for mpls-outgoing; Wed, 23 Aug 2000 18:15:26 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjdnd22844
	for <mpls@mail-control.mail.uu.net>; Wed, 23 Aug 2000 18:15:23 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjdnd21418
	for <mpls@UU.NET>; Wed, 23 Aug 2000 14:15:22 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQjdnd24475
	for <mpls@UU.NET>; Wed, 23 Aug 2000 18:15:08 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA13685
	for <mpls@UU.NET>; Wed, 23 Aug 2000 14:15:05 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA03915
	for <mpls@UU.NET>; Wed, 23 Aug 2000 14:15:05 -0400 (EDT)
Message-ID: <39A414AF.50F75DDD@marconi.com>
Date: Wed, 23 Aug 2000 14:15:11 -0400
From: David Charlap <david.charlap@marconi.com>
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: L3PID
References: <85256944.0059AA59.00@notes949.cc.telcordia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hong Liao wrote:
> 
> I have questions for the L3PID.
> 
> It is an identifier of the layer 3 protocol using this path, it might
> not be the IP protocol only, right?

Correct.  According to section draft-ietf-mpls-rsvp-lsp-tunnel-06.txt,
in section 4.2.1, 4.2.2 and 4.2.3, it says:

	L3PID

	   an identifier of the layer 3 protocol using this path.
	   Standard Ethertype values are used.

So, any value that is valid as a an Ethernet L3PID is valid here as
well.  If you want to forward non-IP data through an MPLS tunnel, you
may do so - just provide the appropriate Ethertype ID in your label
request object.

> As I know, if it is IP protocol using this path, the L3PID is 0x0800.

-- David


From owner-mpls@UU.NET  Wed Aug 23 14:40:34 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21071
	for <mpls-archive@lists.ietf.org>; Wed, 23 Aug 2000 14:40:34 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdne13976;
	Wed, 23 Aug 2000 18:40:28 GMT
Received: by mail-control.mail.uu.net 
	id QQjdne24203
	for mpls-outgoing; Wed, 23 Aug 2000 18:40:03 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjdne24191
	for <mpls@mail-control.mail.uu.net>; Wed, 23 Aug 2000 18:39:54 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjdne21865
	for <mpls@UU.NET>; Wed, 23 Aug 2000 14:39:27 -0400 (EDT)
Received: from ertpg14e1.nortelnetworks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ertpg14e1.nortelnetworks.com [47.234.0.35])
	id QQjdne13027
	for <mpls@UU.NET>; Wed, 23 Aug 2000 18:39:26 GMT
Received: from zrtpd004.us.nortel.com (actually zrtpd004) 
          by ertpg14e1.nortelnetworks.com; Wed, 23 Aug 2000 14:39:11 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <RPW6ZSBA>; Wed, 23 Aug 2000 14:39:10 -0400
Message-ID: <B7F2E7B20E27D41196910000F8BDCBD6010BCD78@zmerd009.ca.nortel.com>
From: "Ajay Malik" <malika@nortelnetworks.com>
To: "'Vasanthi Thirumalai'" <vasanthi@tellium.com>
Cc: mpls@UU.NET
Subject: RE: negotiations in CR-LDP
Date: Wed, 23 Aug 2000 14:38:57 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C00D31.6556CD80"
Sender: owner-mpls@UU.NET
Precedence: bulk

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_01C00D31.6556CD80
Content-Type: text/plain;
	charset="iso-8859-1"

Can a lower limit for negotiations for any parameter be specified in the
setup message ?

-----Original Message-----
From: Vasanthi Thirumalai [mailto:vasanthi@tellium.com]
Sent: Wednesday, August 23, 2000 2:14 PM
To: Malik, Ajay [SKY:1H62:EXCH]
Cc: mpls@UU.NET
Subject: Re: negotiations in CR-LDP


Hi, 
    In the example that you have given, LSR2 would modify the PDR(it may
substitute it with a smaller value) and send the Label request to LSR3. 

In general an LSR that cannot satisfy a negotiable traffic parameter
request, replaces it with a smaller  value and propagates the Label request.
Label Mapping carries the final negotiated value. The LSRs along the path,
then adjust the resources they  reserved for the path, based on the values
conveyed in  the Label Mapping message. 


-Vasanthi 


Ajay Malik wrote: 
Hi, 


  I have a question regarding negotiations in CR-LDP: 
     LER--LSR1--LSR2---LSR3--LER 

  if the LSR2 finds that sufficient resources are not available and the
parameter 
  values are negotiable what does it exactly does ? 
    * does it modify the setup and sends it to LSR3 irrespective of anything
? 
    * does it first negotiate with LSR1 ? how ? (take example of PDR in
Delay 
      sensitive service) 


Ajay 
  
  
 


------_=_NextPart_001_01C00D31.6556CD80
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 5.00.3013.2600" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=151033718-23082000>Can a 
lower limit for negotiations for any parameter be specified in the setup message 
?</SPAN></FONT></DIV>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Vasanthi Thirumalai 
  [mailto:vasanthi@tellium.com]<BR><B>Sent:</B> Wednesday, August 23, 2000 2:14 
  PM<BR><B>To:</B> Malik, Ajay [SKY:1H62:EXCH]<BR><B>Cc:</B> 
  mpls@UU.NET<BR><B>Subject:</B> Re: negotiations in 
  CR-LDP<BR><BR></DIV></FONT>Hi, <BR>&nbsp;&nbsp;&nbsp; In the example that you 
  have given, LSR2 would modify the PDR(it may substitute it with a smaller 
  value) and send the Label request to LSR3. 
  <P>In general an LSR that cannot satisfy a negotiable traffic parameter 
  request, replaces it with a smaller&nbsp; value and propagates the Label 
  request. Label Mapping carries the final negotiated value. The LSRs along the 
  path, then adjust the resources they&nbsp; reserved for the path, based on the 
  values conveyed in&nbsp; the Label Mapping message. 
  <P>-Vasanthi 
  <P>Ajay Malik wrote: <BR><FONT size=-1>Hi,</FONT> 
  <BLOCKQUOTE TYPE="CITE"><FONT size=-1>&nbsp; I have a question regarding 
    negotiations in CR-LDP:</FONT> <BR><FONT size=-1>&nbsp;&nbsp;&nbsp;&nbsp; 
    LER--LSR1--LSR2---LSR3--LER</FONT> 
    <P><FONT size=-1>&nbsp; if the LSR2 finds that sufficient resources are not 
    available and the parameter</FONT> <BR><FONT size=-1>&nbsp; values are 
    negotiable what does it exactly does ?</FONT> <BR><FONT 
    size=-1>&nbsp;&nbsp;&nbsp; * does it modify the setup and sends it to LSR3 
    irrespective of anything ?</FONT> <BR><FONT size=-1>&nbsp;&nbsp;&nbsp; * 
    does it first negotiate with LSR1 ? how ? (take example of PDR in 
    Delay</FONT> <BR><FONT size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; sensitive 
    service)</FONT> 
    <P><FONT size=-1>Ajay</FONT> <BR>&nbsp; <BR>&nbsp; 
<BR>&nbsp;</P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C00D31.6556CD80--


From owner-mpls@UU.NET  Wed Aug 23 14:46:49 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21143
	for <mpls-archive@lists.ietf.org>; Wed, 23 Aug 2000 14:46:49 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdnf18991;
	Wed, 23 Aug 2000 18:46:40 GMT
Received: by mail-control.mail.uu.net 
	id QQjdnf24683
	for mpls-outgoing; Wed, 23 Aug 2000 18:46:01 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjdnf24669
	for <mpls@mail-control.mail.uu.net>; Wed, 23 Aug 2000 18:45:46 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjdnf23355
	for <mpls@UU.NET>; Wed, 23 Aug 2000 14:45:36 -0400 (EDT)
Received: from mps3.leeds.ac.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sunserv5.leeds.ac.uk [129.11.16.35])
	id QQjdnf21351
	for <mpls@UU.NET>; Wed, 23 Aug 2000 18:45:35 GMT
Received: from electeng.leeds.ac.uk (electeng.leeds.ac.uk [129.11.178.99])
	by mps3.leeds.ac.uk (8.9.3/8.9.3) with ESMTP id TAA20705
	for <mpls@UU.NET>; Wed, 23 Aug 2000 19:45:34 +0100 (BST)
Received: from ELECTENG/SpoolDir by electeng.leeds.ac.uk (Mercury 1.43);
    23 Aug 100 20:16:39 GMT
Received: from SpoolDir by ELECTENG (Mercury 1.43); 23 Aug 100 20:16:24 GMT
Received: from default (129.11.176.219) by electeng.leeds.ac.uk (Mercury 1.40);
    23 Aug 100 20:16:21 GMT
From: "Erickson Trejo-Reyes" <eenet@electeng.leeds.ac.uk>
To: <mpls@UU.NET>
Subject: RTP
Date: Wed, 23 Aug 2000 19:47:19 +0100
Message-ID: <01c00d32$90db7040$dbb00b81@default.leeds.ac.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0093_01C00D3A.F29FD840"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.71.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0093_01C00D3A.F29FD840
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Can somebody tell me please how much overhead is introduced by RTP on =
top of UDP. It is impossible for me, at least for now, to have access to =
updated ITU-T recommendations. Thanks in advance,


Erickson Trejo

-----Original Message-----
From: David Charlap <david.charlap@marconi.com>
To: mpls@UU.NET <mpls@UU.NET>
Date: Wednesday, August 23, 2000 7:15 PM
Subject: Re: L3PID


Hong Liao wrote:
>=20
> I have questions for the L3PID.
>=20
> It is an identifier of the layer 3 protocol using this path, it might
> not be the IP protocol only, right?

Correct.  According to section draft-ietf-mpls-rsvp-lsp-tunnel-06.txt,
in section 4.2.1, 4.2.2 and 4.2.3, it says:

L3PID

   an identifier of the layer 3 protocol using this path.
   Standard Ethertype values are used.

So, any value that is valid as a an Ethernet L3PID is valid here as
well.  If you want to forward non-IP data through an MPLS tunnel, you
may do so - just provide the appropriate Ethertype ID in your label
request object.

> As I know, if it is IP protocol using this path, the L3PID is 0x0800.

-- David

------=_NextPart_000_0093_01C00D3A.F29FD840
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.71.1712.3"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3D"Bookman Old Style" size=3D2>Can somebody tell me =
please how much=20
overhead is introduced by RTP on top of UDP. It is impossible for me, at =
least=20
for now, to have access to updated ITU-T recommendations. Thanks in=20
advance,</FONT></DIV>
<DIV><FONT face=3D"Bookman Old Style" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Bookman Old Style" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Bookman Old Style" size=3D2>Erickson =
Trejo</FONT></DIV>
<DIV><FONT face=3DArial size=3D2><B></B></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><B>-----Original =
Message-----</B><BR><B>From:=20
</B>David Charlap &lt;<A=20
href=3D"mailto:david.charlap@marconi.com">david.charlap@marconi.com</A>&g=
t;<BR><B>To:=20
</B><A href=3D"mailto:mpls@UU.NET">mpls@UU.NET</A> &lt;<A=20
href=3D"mailto:mpls@UU.NET">mpls@UU.NET</A>&gt;<BR><B>Date: =
</B>Wednesday, August=20
23, 2000 7:15 PM<BR><B>Subject: </B>Re: =
L3PID<BR><BR>&nbsp;</DIV></FONT>Hong=20
Liao wrote:<BR>&gt; <BR>&gt; I have questions for the L3PID.<BR>&gt; =
<BR>&gt; It=20
is an identifier of the layer 3 protocol using this path, it =
might<BR>&gt; not=20
be the IP protocol only, right?<BR><BR>Correct.&nbsp; According to =
section=20
draft-ietf-mpls-rsvp-lsp-tunnel-06.txt,<BR>in section 4.2.1, 4.2.2 and =
4.2.3, it=20
says:<BR><BR>L3PID<BR><BR>&nbsp;&nbsp; an identifier of the layer 3 =
protocol=20
using this path.<BR>&nbsp;&nbsp; Standard Ethertype values are =
used.<BR><BR>So,=20
any value that is valid as a an Ethernet L3PID is valid here =
as<BR>well.&nbsp;=20
If you want to forward non-IP data through an MPLS tunnel, you<BR>may do =
so -=20
just provide the appropriate Ethertype ID in your label<BR>request=20
object.<BR><BR>&gt; As I know, if it is IP protocol using this path, the =
L3PID=20
is 0x0800.<BR><BR>-- David</BODY></HTML>

------=_NextPart_000_0093_01C00D3A.F29FD840--



From owner-mpls@UU.NET  Wed Aug 23 15:31:22 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22030
	for <mpls-archive@lists.ietf.org>; Wed, 23 Aug 2000 15:31:22 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdni23432;
	Wed, 23 Aug 2000 19:31:16 GMT
Received: by mail-control.mail.uu.net 
	id QQjdni10771
	for mpls-outgoing; Wed, 23 Aug 2000 19:30:54 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjdni10764
	for <mpls@mail-control.mail.uu.net>; Wed, 23 Aug 2000 19:30:50 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjdni06667
	for <mpls@uu.net>; Wed, 23 Aug 2000 15:30:36 -0400 (EDT)
Received: from mtiwmhc26.worldnet.att.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mtiwmhc26.worldnet.att.net [204.127.131.51])
	id QQjdni25582
	for <mpls@uu.net>; Wed, 23 Aug 2000 19:30:35 GMT
Received: from alan-s-thinkpad ([12.77.2.134])
          by mtiwmhc26.worldnet.att.net
          (InterMail vM.4.01.02.39 201-229-119-122) with SMTP
          id <20000823193034.KHQA9297.mtiwmhc26.worldnet.att.net@alan-s-thinkpad>;
          Wed, 23 Aug 2000 19:30:34 +0000
Message-ID: <001701c00d36$bfa60ee0$4d4d5864@alan-s-thinkpad>
From: "Alan Clark" <alan@telchemy.com>
To: "Erickson Trejo-Reyes" <eenet@electeng.leeds.ac.uk>, <mpls@UU.NET>
Subject: Re: RTP
Date: Wed, 23 Aug 2000 15:17:10 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0014_01C00D15.35133760"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3155.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0014_01C00D15.35133760
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

RTP nominally adds 12 bytes to the UDP header.  You don't need access to =
the ITU-T recommendations to find the RTP spec .... check RFC1889 on the =
IETF site.  There is also quite a bit of downloadable and useful data in =
the ETSI TIPHON ftp server.

Alan Clark
Telchemy

    -----Original Message-----
    From: Erickson Trejo-Reyes <eenet@electeng.leeds.ac.uk>
    To: mpls@UU.NET <mpls@UU.NET>
    Date: Wednesday, August 23, 2000 2:46 PM
    Subject: RTP
   =20
   =20
    Can somebody tell me please how much overhead is introduced by RTP =
on top of UDP. It is impossible for me, at least for now, to have access =
to updated ITU-T recommendations. Thanks in advance,
    =20
    =20
    Erickson Trejo
    =20
    -----Original Message-----
    From: David Charlap <david.charlap@marconi.com>
    To: mpls@UU.NET <mpls@UU.NET>
    Date: Wednesday, August 23, 2000 7:15 PM
    Subject: Re: L3PID
   =20
    =20
    Hong Liao wrote:
    >=20
    > I have questions for the L3PID.
    >=20
    > It is an identifier of the layer 3 protocol using this path, it =
might
    > not be the IP protocol only, right?
   =20
    Correct.  According to section =
draft-ietf-mpls-rsvp-lsp-tunnel-06.txt,
    in section 4.2.1, 4.2.2 and 4.2.3, it says:
   =20
    L3PID
   =20
       an identifier of the layer 3 protocol using this path.
       Standard Ethertype values are used.
   =20
    So, any value that is valid as a an Ethernet L3PID is valid here as
    well.  If you want to forward non-IP data through an MPLS tunnel, =
you
    may do so - just provide the appropriate Ethertype ID in your label
    request object.
   =20
    > As I know, if it is IP protocol using this path, the L3PID is =
0x0800.
   =20
    -- David=20

------=_NextPart_000_0014_01C00D15.35133760
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type><!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 =
HTML//EN">
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000 size=3D2>RTP nominally adds 12 bytes to the =
UDP=20
header.&nbsp; You don't need access to the ITU-T recommendations to find =
the RTP=20
spec .... check RFC1889 on the IETF site.&nbsp; There is also quite a =
bit of=20
downloadable and useful data in the ETSI TIPHON ftp server.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Alan Clark</FONT></DIV>
<DIV><FONT size=3D2>Telchemy</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 solid 2px; MARGIN-LEFT: 5px; PADDING-LEFT: =
5px">
    <DIV><FONT face=3DArial size=3D2><B>-----Original =
Message-----</B><BR><B>From:=20
    </B>Erickson Trejo-Reyes &lt;<A=20
    =
href=3D"mailto:eenet@electeng.leeds.ac.uk">eenet@electeng.leeds.ac.uk</A>=
&gt;<BR><B>To:=20
    </B><A href=3D"mailto:mpls@UU.NET">mpls@UU.NET</A> &lt;<A=20
    href=3D"mailto:mpls@UU.NET">mpls@UU.NET</A>&gt;<BR><B>Date: =
</B>Wednesday,=20
    August 23, 2000 2:46 PM<BR><B>Subject: </B>RTP<BR><BR></DIV></FONT>
    <DIV><FONT face=3D"Bookman Old Style" size=3D2>Can somebody tell me =
please how=20
    much overhead is introduced by RTP on top of UDP. It is impossible =
for me,=20
    at least for now, to have access to updated ITU-T recommendations. =
Thanks in=20
    advance,</FONT></DIV>
    <DIV><FONT face=3D"Bookman Old Style" size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3D"Bookman Old Style" size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3D"Bookman Old Style" size=3D2>Erickson =
Trejo</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2><B></B></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2><B>-----Original =
Message-----</B><BR><B>From:=20
    </B>David Charlap &lt;<A=20
    =
href=3D"mailto:david.charlap@marconi.com">david.charlap@marconi.com</A>&g=
t;<BR><B>To:=20
    </B><A href=3D"mailto:mpls@UU.NET">mpls@UU.NET</A> &lt;<A=20
    href=3D"mailto:mpls@UU.NET">mpls@UU.NET</A>&gt;<BR><B>Date: =
</B>Wednesday,=20
    August 23, 2000 7:15 PM<BR><B>Subject: </B>Re:=20
    L3PID<BR><BR>&nbsp;</DIV></FONT>Hong Liao wrote:<BR>&gt; <BR>&gt; I =
have=20
    questions for the L3PID.<BR>&gt; <BR>&gt; It is an identifier of the =
layer 3=20
    protocol using this path, it might<BR>&gt; not be the IP protocol =
only,=20
    right?<BR><BR>Correct.&nbsp; According to section=20
    draft-ietf-mpls-rsvp-lsp-tunnel-06.txt,<BR>in section 4.2.1, 4.2.2 =
and=20
    4.2.3, it says:<BR><BR>L3PID<BR><BR>&nbsp;&nbsp; an identifier of =
the layer=20
    3 protocol using this path.<BR>&nbsp;&nbsp; Standard Ethertype =
values are=20
    used.<BR><BR>So, any value that is valid as a an Ethernet L3PID is =
valid=20
    here as<BR>well.&nbsp; If you want to forward non-IP data through an =
MPLS=20
    tunnel, you<BR>may do so - just provide the appropriate Ethertype ID =
in your=20
    label<BR>request object.<BR><BR>&gt; As I know, if it is IP protocol =
using=20
    this path, the L3PID is 0x0800.<BR><BR>-- David =
</BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0014_01C00D15.35133760--



From owner-mpls@UU.NET  Wed Aug 23 17:55:20 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23436
	for <mpls-archive@lists.ietf.org>; Wed, 23 Aug 2000 17:55:19 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdnr06342;
	Wed, 23 Aug 2000 21:55:10 GMT
Received: by mail-control.mail.uu.net 
	id QQjdnr13860
	for mpls-outgoing; Wed, 23 Aug 2000 21:54:47 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjdnr13855
	for <mpls@mail-control.mail.uu.net>; Wed, 23 Aug 2000 21:54:44 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjdnr28687
	for <mpls@uu.net>; Wed, 23 Aug 2000 17:54:38 -0400 (EDT)
Received: from devmail.dev.tivoli.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: devmail.dev.tivoli.com [208.230.244.136])
	id QQjdnr09849
	for <mpls@uu.net>; Wed, 23 Aug 2000 21:54:22 GMT
Received: from madev-dns.ma.dev.tivoli.com (madev-dns.ma.dev.tivoli.com [146.84.242.19])
	by devmail.dev.tivoli.com (8.9.1/8.8.8) with ESMTP id QAA17569
	for <mpls@uu.net>; Wed, 23 Aug 2000 16:54:22 -0500 (CDT)
Received: from ptasillo (ptasillo.ma.dev.tivoli.com [146.84.242.70])
	by madev-dns.ma.dev.tivoli.com (8.8.8/8.8.8) with SMTP id RAA00387
	for <mpls@uu.net>; Wed, 23 Aug 2000 17:56:33 -0400 (EDT)
From: "Paul Tasillo" <Paul.tasillo@tivoli.com>
To: <mpls@UU.NET>
Subject: FW: basic MPLS ATM question
Date: Wed, 23 Aug 2000 17:54:11 -0400
Message-ID: <NDBBIBIGNKNLFBNPNPAIKEGKCFAA.Paul.tasillo@tivoli.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit



Hi-
	In draft-ietf-mpls-ldp-applic-02.txt it says,

  LDP, together with an IP routing plane and software to program ATM
   switch or Frame Relay switch cross-connect tables, can implement IP
   in a network of ATM and/or Frame Relay switches without requiring an
   overlay or the use of ATM-specific or Frame Relay-specific addressing
   or routing.

In the absence of ATM/FR specific addressing or routing, what is being used
for addressing? If the answer is IP, then am I safe in assuming that this
requires each ATM switch to have an IP address? I understand the ATM
switches will be participating in L3 routing protocols (BGP, OSPF, etc).

Is there also an overlay MPLS model? Where MPLS make decisions on a frame
basis rather then cell and uses ATM/FR specifc addressing and routing?

And are there other MPLS over ATM models that I haven't listed?

Thanks in advance,
Paul



From owner-mpls@UU.NET  Wed Aug 23 18:03:00 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23579
	for <mpls-archive@lists.ietf.org>; Wed, 23 Aug 2000 18:03:00 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdns15956;
	Wed, 23 Aug 2000 22:02:40 GMT
Received: by mail-control.mail.uu.net 
	id QQjdns21012
	for mpls-outgoing; Wed, 23 Aug 2000 22:02:17 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjdns20972
	for <mpls@mail-control.mail.uu.net>; Wed, 23 Aug 2000 22:02:10 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjdns03533
	for <mpls@uu.net>; Wed, 23 Aug 2000 18:02:05 -0400 (EDT)
Received: from turin.trillium.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: turin.trillium.com [38.187.146.197])
	id QQjdns15468
	for <mpls@uu.net>; Wed, 23 Aug 2000 22:02:04 GMT
Received: from aiglos.trillium.com (smtp.trillium.com) by turin.trillium.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <T26bb92c51124e34b78ff8@turin.trillium.com>;
 Wed, 23 Aug 2000 15:18:14 -0700
Received: from aega.trillium.com (aega.trillium.com [192.168.1.19])
	by aiglos.trillium.com (8.9.3/8.9.3) with ESMTP id PAA26517;
	Wed, 23 Aug 2000 15:01:47 -0700 (PDT)
Received: by aega.trillium.com with Internet Mail Service (5.5.2650.21)
	id <QXRK8M5N>; Wed, 23 Aug 2000 14:54:53 -0700
Message-ID: <8BBD33A986C5D311804000902719FF5D952C11@aega.trillium.com>
From: Prem Shankar Sharma <prem@trillium.com>
To: "'Ajay Malik'" <malika@nortelnetworks.com>,
        "'Vasanthi Thirumalai'"
	 <vasanthi@tellium.com>
Cc: mpls@UU.NET
Subject: RE: negotiations in CR-LDP
Date: Wed, 23 Aug 2000 14:54:52 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C00D4C.C445F5EE"
Sender: owner-mpls@UU.NET
Precedence: bulk

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_01C00D4C.C445F5EE
Content-Type: text/plain;
	charset="iso-8859-1"

Well, the negotiation flag associated with each parameter dictates what all
parameters could be negotiated or not. 
 
The drafts don't mention anything about the lower limits except that PDR
can not be less than CDR .
 
The exact rules for deciding on downgrading the requirements of the LSP or
to initiate pre-emption of other LSPs could depend on network policies.
 
Prem
 
 
 -----Original Message-----
From: Ajay Malik [mailto:malika@nortelnetworks.com]
Sent: Wednesday, August 23, 2000 11:39 AM
To: 'Vasanthi Thirumalai'
Cc: mpls@uu.net
Subject: RE: negotiations in CR-LDP



Can a lower limit for negotiations for any parameter be specified in the
setup message ?

-----Original Message-----
From: Vasanthi Thirumalai [mailto:vasanthi@tellium.com]
Sent: Wednesday, August 23, 2000 2:14 PM
To: Malik, Ajay [SKY:1H62:EXCH]
Cc: mpls@UU.NET
Subject: Re: negotiations in CR-LDP


Hi, 
    In the example that you have given, LSR2 would modify the PDR(it may
substitute it with a smaller value) and send the Label request to LSR3. 

In general an LSR that cannot satisfy a negotiable traffic parameter
request, replaces it with a smaller  value and propagates the Label request.
Label Mapping carries the final negotiated value. The LSRs along the path,
then adjust the resources they  reserved for the path, based on the values
conveyed in  the Label Mapping message. 


-Vasanthi 


Ajay Malik wrote: 
Hi, 


  I have a question regarding negotiations in CR-LDP: 
     LER--LSR1--LSR2---LSR3--LER 

  if the LSR2 finds that sufficient resources are not available and the
parameter 
  values are negotiable what does it exactly does ? 
    * does it modify the setup and sends it to LSR3 irrespective of anything
? 
    * does it first negotiate with LSR1 ? how ? (take example of PDR in
Delay 
      sensitive service) 


Ajay 
  
  
 


------_=_NextPart_001_01C00D4C.C445F5EE
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 5.00.2314.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=523024521-23082000>Well, 
the negotiation flag associated with each parameter dictates what 
all</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=523024521-23082000>parameters could be negotiated or not. 
</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=523024521-23082000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=523024521-23082000>The 
drafts don't mention anything about the lower limits except that 
PDR</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=523024521-23082000>can 
not be less than CDR .</SPAN></FONT></DIV>
<DIV><SPAN class=523024521-23082000></SPAN><FONT face=Tahoma><FONT size=2><SPAN 
class=523024521-23082000><FONT color=#0000ff 
face=Arial></FONT></SPAN></FONT></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2>The exact rules for 
deciding&nbsp;<SPAN class=523024521-23082000>on</SPAN>&nbsp;<SPAN 
class=523024521-23082000>downgrading </SPAN>the requirements of the 
LSP&nbsp;<SPAN class=523024521-23082000>o</SPAN><SPAN 
class=523024521-23082000>r</SPAN></FONT></DIV>
<DIV><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
class=523024521-23082000>to initiate </SPAN>pre-emption<SPAN 
class=523024521-23082000> of other LSPs could depend on network 
policies.</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
class=523024521-23082000></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
class=523024521-23082000>Prem</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
class=523024521-23082000></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=Tahoma><FONT size=2><SPAN 
class=523024521-23082000>&nbsp;</SPAN></FONT></FONT></DIV>
<DIV><FONT face=Tahoma><FONT size=2><SPAN 
class=523024521-23082000>&nbsp;</SPAN>-----Original Message-----<BR><B>From:</B> 
Ajay Malik [mailto:malika@nortelnetworks.com]<BR><B>Sent:</B> Wednesday, August 
23, 2000 11:39 AM<BR><B>To:</B> 'Vasanthi Thirumalai'<BR><B>Cc:</B> 
mpls@uu.net<BR><B>Subject:</B> RE: negotiations in CR-LDP<BR><BR></DIV></FONT>
<BLOCKQUOTE 
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px"></FONT>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=151033718-23082000>Can 
  a lower limit for negotiations for any parameter be specified in the setup 
  message ?</SPAN></FONT></DIV>
  <BLOCKQUOTE style="MARGIN-RIGHT: 0px">
    <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
    size=2>-----Original Message-----<BR><B>From:</B> Vasanthi Thirumalai 
    [mailto:vasanthi@tellium.com]<BR><B>Sent:</B> Wednesday, August 23, 2000 
    2:14 PM<BR><B>To:</B> Malik, Ajay [SKY:1H62:EXCH]<BR><B>Cc:</B> 
    mpls@UU.NET<BR><B>Subject:</B> Re: negotiations in 
    CR-LDP<BR><BR></DIV></FONT>Hi, <BR>&nbsp;&nbsp;&nbsp; In the example that 
    you have given, LSR2 would modify the PDR(it may substitute it with a 
    smaller value) and send the Label request to LSR3. 
    <P>In general an LSR that cannot satisfy a negotiable traffic parameter 
    request, replaces it with a smaller&nbsp; value and propagates the Label 
    request. Label Mapping carries the final negotiated value. The LSRs along 
    the path, then adjust the resources they&nbsp; reserved for the path, based 
    on the values conveyed in&nbsp; the Label Mapping message. 
    <P>-Vasanthi 
    <P>Ajay Malik wrote: <BR><FONT size=-1>Hi,</FONT> 
    <BLOCKQUOTE TYPE="CITE"><FONT size=-1>&nbsp; I have a question regarding 
      negotiations in CR-LDP:</FONT> <BR><FONT size=-1>&nbsp;&nbsp;&nbsp;&nbsp; 
      LER--LSR1--LSR2---LSR3--LER</FONT> 
      <P><FONT size=-1>&nbsp; if the LSR2 finds that sufficient resources are 
      not available and the parameter</FONT> <BR><FONT size=-1>&nbsp; values are 
      negotiable what does it exactly does ?</FONT> <BR><FONT 
      size=-1>&nbsp;&nbsp;&nbsp; * does it modify the setup and sends it to LSR3 
      irrespective of anything ?</FONT> <BR><FONT size=-1>&nbsp;&nbsp;&nbsp; * 
      does it first negotiate with LSR1 ? how ? (take example of PDR in 
      Delay</FONT> <BR><FONT size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; sensitive 
      service)</FONT> 
      <P><FONT size=-1>Ajay</FONT> <BR>&nbsp; <BR>&nbsp; 
    <BR>&nbsp;</P></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C00D4C.C445F5EE--


From owner-mpls@UU.NET  Wed Aug 23 18:38:34 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23883
	for <mpls-archive@lists.ietf.org>; Wed, 23 Aug 2000 18:38:34 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdnu04430;
	Wed, 23 Aug 2000 22:38:26 GMT
Received: by mail-control.mail.uu.net 
	id QQjdnu28998
	for mpls-outgoing; Wed, 23 Aug 2000 22:37:54 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjdnu28986
	for <mpls@mail-control.mail.uu.net>; Wed, 23 Aug 2000 22:37:40 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjdnu08243
	for <mpls@uu.net>; Wed, 23 Aug 2000 18:37:37 -0400 (EDT)
Received: from turin.trillium.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: turin.trillium.com [38.187.146.197])
	id QQjdnu07632
	for <mpls@uu.net>; Wed, 23 Aug 2000 22:37:06 GMT
Received: from aiglos.trillium.com (smtp.trillium.com) by turin.trillium.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <T26bb92c51124e34d7b69f@turin.trillium.com>;
 Wed, 23 Aug 2000 15:53:21 -0700
Received: from aega.trillium.com (aega.trillium.com [192.168.1.19])
	by aiglos.trillium.com (8.9.3/8.9.3) with ESMTP id PAA27517;
	Wed, 23 Aug 2000 15:36:54 -0700 (PDT)
Received: by aega.trillium.com with Internet Mail Service (5.5.2650.21)
	id <QXRK8M65>; Wed, 23 Aug 2000 15:30:00 -0700
Message-ID: <8BBD33A986C5D311804000902719FF5D952C13@aega.trillium.com>
From: Prem Shankar Sharma <prem@trillium.com>
To: "'Vasanthi Thirumalai'" <vasanthi@tellium.com>
Cc: "'mpls@uu.net'" <mpls@UU.NET>
Subject: RE: Port
Date: Wed, 23 Aug 2000 15:29:59 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Vasanthi,

   It's a long standing debate whether MPLS control plane entities
   are layer2 or layer3 in nature. Yakov in one of his mails clearly
   pointed out the difference long back. 

   Unlike layer3 layers, MPLS lacks addressing and routing component. It
   has to rely on IP, OSPF/BGP etc. for that. It's not layer 2 either as
   it operates layer 2 and doesn't have a single format for data
   transmission - requirement for layer2.

   Hope it helps.

Thanks.
Prem


> > > MPLS resides at Layer 2.  Why would there be a port number?
> >
> >     MPLS control plane resides in layer 3 and that is why a 
> port number
> > had to be assigned to handle the control plane traffic.
> >
> > -Vasanthi
>


From owner-mpls@UU.NET  Wed Aug 23 18:39:57 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23900
	for <mpls-archive@lists.ietf.org>; Wed, 23 Aug 2000 18:39:57 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdnu09647;
	Wed, 23 Aug 2000 22:39:50 GMT
Received: by mail-control.mail.uu.net 
	id QQjdnu29222
	for mpls-outgoing; Wed, 23 Aug 2000 22:39:34 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjdnu29140
	for <mpls@mail-control.mail.uu.net>; Wed, 23 Aug 2000 22:39:17 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjdnu08520
	for <mpls@UU.NET>; Wed, 23 Aug 2000 18:39:11 -0400 (EDT)
Received: from cplane.com by wodc7mr1.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: jersey.cplane.com [63.193.105.226])
	id QQjdnu08826
	for <mpls@UU.NET>; Wed, 23 Aug 2000 22:38:55 GMT
Received: (qmail 26092 invoked from network); 23 Aug 2000 21:18:43 -0000
Received: from unknown (HELO texas.cplane.com) (unknown)
  by unknown with SMTP; 23 Aug 2000 21:18:43 -0000
Received: (qmail 10059 invoked from network); 23 Aug 2000 22:38:43 -0000
Received: from unknown (HELO cplane.com) (unknown)
  by unknown with SMTP; 23 Aug 2000 22:38:43 -0000
Message-ID: <39A45273.8E679919@cplane.com>
Date: Wed, 23 Aug 2000 15:38:43 -0700
From: Mukul Katiyar <mukul@cplane.com>
Reply-To: mukul@cplane.com
Organization: Cplane Inc
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul.tasillo@tivoli.com, mpls@UU.NET
Subject: Re: FW: basic MPLS ATM question,
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

paul,

There is one more way of establish an MPLS-LSP 
to traverse an ATM network by peering with it using the
VCID Notification procedures in draft-ietf-mpls-vcid-atm-05.txt.
In this model, though the MPLS directly peers with the ATM cloud
but uses the ATM signaling for establishing the VCs for the LSP.

>And are there other MPLS over ATM models that I haven't listed?
>Thanks in advance,
>Paul

-mukul


From owner-mpls@UU.NET  Wed Aug 23 19:59:01 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24391
	for <mpls-archive@lists.ietf.org>; Wed, 23 Aug 2000 19:59:01 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdnz23229;
	Wed, 23 Aug 2000 23:58:55 GMT
Received: by mail-control.mail.uu.net 
	id QQjdnz17225
	for mpls-outgoing; Wed, 23 Aug 2000 23:58:33 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjdnz17219
	for <mpls@mail-control.mail.uu.net>; Wed, 23 Aug 2000 23:58:28 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjdnz18067
	for <mpls@uu.net>; Wed, 23 Aug 2000 19:58:23 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjdnz22803
	for <mpls@uu.net>; Wed, 23 Aug 2000 23:58:22 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id TAA06920
	for mpls@uu.net; Wed, 23 Aug 2000 19:58:22 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjdnz17210
	for <mpls@mail-control.mail.uu.net>; Wed, 23 Aug 2000 23:57:57 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjdnz14123
	for <mpls@UU.NET>; Wed, 23 Aug 2000 19:57:45 -0400 (EDT)
Received: from dnsmx2pya.telcordia.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: dnsmx2pya.telcordia.com [128.96.20.32])
	id QQjdnz22177
	for <mpls@UU.NET>; Wed, 23 Aug 2000 23:57:15 GMT
Received: from notes949.cc.telcordia.com (notes949a.cc.telcordia.com [128.96.246.8])
	by dnsmx2pya.telcordia.com (8.9.3/8.9.3) with SMTP id TAA03932
	for <mpls@UU.NET>; Wed, 23 Aug 2000 19:56:14 -0400 (EDT)
Received: by notes949.cc.telcordia.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 85256944.00837B8E ; Wed, 23 Aug 2000 19:56:08 -0400
X-Lotus-FromDomain: TELCORDIA
From: "Ellen Chang" <echang@telcordia.com>
To: mpls@UU.NET
Message-ID: <85256944.0083799D.00@notes949.cc.telcordia.com>
Date: Wed, 23 Aug 2000 19:55:07 -0400
Subject: mpls LDP questions
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-mpls@UU.NET
Precedence: bulk



Hi,

Is there any suggestion on 'how much the subsequent delay should grow for the
session establishment setup attempt after the second NAK'd Initialization
message'?

Is there a Shutdown msg in the LDP spec?  It is indicated in the initialization
state transition table and diagram, but I couldn't find it in the spec.

Thank you
Ellen




From owner-mpls@UU.NET  Wed Aug 23 20:17:24 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24600
	for <mpls-archive@lists.ietf.org>; Wed, 23 Aug 2000 20:17:23 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdob04364;
	Thu, 24 Aug 2000 00:17:19 GMT
Received: by mail-control.mail.uu.net 
	id QQjdob00436
	for mpls-outgoing; Thu, 24 Aug 2000 00:16:33 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjdob00426
	for <mpls@mail-control.mail.uu.net>; Thu, 24 Aug 2000 00:16:23 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjdob16416
	for <mpls@uu.net>; Wed, 23 Aug 2000 20:16:17 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88])
	id QQjdob06110
	for <mpls@uu.net>; Thu, 24 Aug 2000 00:15:47 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id RAA18755
	for <mpls@uu.net>; Wed, 23 Aug 2000 17:16:05 -0700 (PDT)
Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id UAA12936 for mpls@uu.net; Wed, 23 Aug 2000 20:15:45 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjdmt05762
	for <mpls@mail-control.mail.uu.net>; Wed, 23 Aug 2000 15:56:40 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjdmt26570
	for <mpls@UU.NET>; Wed, 23 Aug 2000 11:56:32 -0400 (EDT)
Received: from rottweiler.cwusa.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rottweiler-dmz.cwusa.com [146.135.88.50])
	id QQjdmt22316
	for <mpls@UU.NET>; Wed, 23 Aug 2000 15:56:12 GMT
Received: from us-cwi-exc-a10.cwusa.com (us-cwi-exc-a10.cwusa.com [146.135.85.143])
	by rottweiler.cwusa.com (8.9.1/8.9.1) with ESMTP id LAA21834;
	Wed, 23 Aug 2000 11:55:26 -0400 (EDT)
Received: from cwusa.com (204.71.42.60 [204.71.42.60]) by us-cwi-exc-a10.cwusa.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id QS7WQLBM; Wed, 23 Aug 2000 11:55:23 -0400
Message-ID: <39A3F463.50B3ECD4@cwusa.com>
Date: Wed, 23 Aug 2000 11:57:23 -0400
From: Aditya Bhatnagar <Aditya.Bhatnagar@cwusa.com>
Organization: Cable & Wireless
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Samantha Quadros <SQuadros@narus.com>
CC: "'mpls@UU.NET'" <mpls@UU.NET>,
        "'mpls-ops@mplsrc.com'" <mpls-ops@mplsrc.com>
Subject: Re: Port
References: <D233CC5C9935D311A1AA00A0C9E45B0B01175016@hermes.narus.com>
Content-Type: multipart/mixed;
 boundary="------------6D2E2BE32F79EDDAF89C07C0"
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.
--------------6D2E2BE32F79EDDAF89C07C0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

MPLS resides at Layer 2.  Why would there be a port number?

Aditya

Samantha Quadros wrote:

> Hi
>
> Has a port number been permanantly for MPLS?
>
> Samantha

--------------6D2E2BE32F79EDDAF89C07C0
Content-Type: text/x-vcard; charset=us-ascii;
 name="Aditya.Bhatnagar.vcf"
Content-Description: Card for Aditya Bhatnagar
Content-Disposition: attachment;
 filename="Aditya.Bhatnagar.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Bhatnagar;Aditya
tel;fax:+1 (703) 292-2444
tel;work:+1 (703) 292-2038
x-mozilla-html:TRUE
url:www.cablewireless.com
org:Cable & Wireless;Data Network Engineering
version:2.1
email;internet:Aditya.Bhatnagar@cwusa.com
title:Network Architect
adr;quoted-printable:;;Mail Stop RES3/10=0D=0A11700 Plaza America Drive, Rm 1065;Reston;VA;20190;USA
fn:Aditya Bhatnagar
end:vcard

--------------6D2E2BE32F79EDDAF89C07C0--



From owner-mpls@UU.NET  Wed Aug 23 20:42:42 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24856
	for <mpls-archive@lists.ietf.org>; Wed, 23 Aug 2000 20:42:42 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdoc21621;
	Thu, 24 Aug 2000 00:42:37 GMT
Received: by mail-control.mail.uu.net 
	id QQjdoc01602
	for mpls-outgoing; Thu, 24 Aug 2000 00:41:53 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjdoc01597
	for <mpls@mail-control.mail.uu.net>; Thu, 24 Aug 2000 00:41:43 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjdoc19302
	for <mpls@uu.net>; Wed, 23 Aug 2000 20:41:34 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjdoc19384
	for <mpls@uu.net>; Thu, 24 Aug 2000 00:41:33 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id UAA10750
	for mpls@uu.net; Wed, 23 Aug 2000 20:41:33 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjdoc01478
	for <mpls@mail-control.mail.uu.net>; Thu, 24 Aug 2000 00:40:50 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjdoc23461
	for <mpls@UU.NET>; Wed, 23 Aug 2000 20:40:46 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11])
	id QQjdoc18878
	for <mpls@UU.NET>; Thu, 24 Aug 2000 00:40:46 GMT
Received: from bulkrate.cisco.com (bulkrate.cisco.com [171.71.160.24])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id RAA03577;
	Wed, 23 Aug 2000 17:41:03 -0700 (PDT)
Received: from jlawrenc-pc.cisco.com (dhcp-71-56-188.cisco.com [171.71.56.188])
	by bulkrate.cisco.com (Mirapoint)
	with ESMTP id ABU07335;
	Wed, 23 Aug 2000 17:40:52 -0700 (PDT)
Message-Id: <4.3.2.7.2.20000823173433.00b05720@bulkrate.cisco.com>
X-Sender: jlawrenc@bulkrate.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 23 Aug 2000 17:40:03 -0700
To: "Paul Tasillo" <Paul.tasillo@tivoli.com>
From: Jeremy Lawrence <jlawrenc@cisco.com>
Subject: Re: FW: basic MPLS ATM question
Cc: <mpls@UU.NET>
In-Reply-To: <NDBBIBIGNKNLFBNPNPAIKEGKCFAA.Paul.tasillo@tivoli.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-mpls@UU.NET
Precedence: bulk

At 17:54 08/23/2000 -0400, Paul Tasillo wrote:


>Hi-
>        In draft-ietf-mpls-ldp-applic-02.txt it says,
>
>  LDP, together with an IP routing plane and software to program ATM
>   switch or Frame Relay switch cross-connect tables, can implement IP
>   in a network of ATM and/or Frame Relay switches without requiring an
>   overlay or the use of ATM-specific or Frame Relay-specific addressing
>   or routing.
>
>In the absence of ATM/FR specific addressing or routing, what is being used
>for addressing? If the answer is IP, then am I safe in assuming that this
>requires each ATM switch to have an IP address? 

Yes, in the same way that a router does, for the purposes of
participating in an IP routing protocol. (From the perspective
of an IP routing protocol, an ATM-LSR is indistinguishable from
a router.) The links may also have IP addresses.

>I understand the ATM
>switches will be participating in L3 routing protocols (BGP, OSPF, etc).
>
>Is there also an overlay MPLS model? Where MPLS make decisions on a frame
>basis rather then cell and uses ATM/FR specifc addressing and routing?

Aside from VCID (covered in another email), MPLS-enabled routers
can be connected by RFC 1483 (or whatever the latest RFC number is)
PVCs. This is like ordinary IP over ATM, except that it is
frame-based MPLS over ATM. The PVCs act like any other non-channelized
point-to-point link between frame-based LSRs.

Regards,

Jeremy Lawrence



From owner-mpls@UU.NET  Wed Aug 23 21:09:16 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25109
	for <mpls-archive@lists.ietf.org>; Wed, 23 Aug 2000 21:09:16 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdoe07329;
	Thu, 24 Aug 2000 01:09:11 GMT
Received: by mail-control.mail.uu.net 
	id QQjdoe14773
	for mpls-outgoing; Thu, 24 Aug 2000 01:08:36 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjdoe14741
	for <mpls@mail-control.mail.uu.net>; Thu, 24 Aug 2000 01:08:24 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjdoe22285
	for <mpls@uu.net>; Wed, 23 Aug 2000 21:08:11 -0400 (EDT)
Received: from hotmail.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: f33.pav1.hotmail.com [64.4.31.33])
	id QQjdoe06530
	for <mpls@uu.net>; Thu, 24 Aug 2000 01:07:56 GMT
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Wed, 23 Aug 2000 18:07:55 -0700
Received: from 207.53.175.35 by pv1fd.pav1.hotmail.msn.com with HTTP;	Thu, 24 Aug 2000  GMT
X-Originating-IP: [207.53.175.35]
From: "Mark Dewey" <deweymark@hotmail.com>
To: mpls@UU.NET
Subject: Bandwidth reservation in MPLS tunnels
Date: Thu, 24 Aug 2000 01:07:55 GMT
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F33JSFsxf4yp8ARf3sl0000004a@hotmail.com>
X-OriginalArrivalTime: 24 Aug 2000 01:07:55.0758 (UTC) FILETIME=[BC4190E0:01C00D67]
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

I have few questions regarding bandwidth provisioning for LSP tunnels.

1. What is the mechanism used for bandwidth reservation in traffic 
engineered MPLS tunnels? Assuming RSVP-TE is used for signalling, is the 
tunnel bandwidth conveyed as an intserv parameter? If yes, does the LSR 
behave like an intserv node, and what is the parameter used to convey the 
tunnel's bandwidth requirement?

2. The draft "draft-rk-diffserv-rsvp-sig-00.txt" talks about using RSVP for 
provisioning diffserv networks. Is it intended for use with MPLS/DIFFSERV 
LSPs (E-LSP,L-LSPs)?

Thanks,
Mark.


________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com



From owner-mpls@UU.NET  Wed Aug 23 23:48:53 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28538
	for <mpls-archive@lists.ietf.org>; Wed, 23 Aug 2000 23:48:52 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdop05153;
	Thu, 24 Aug 2000 03:48:46 GMT
Received: by mail-control.mail.uu.net 
	id QQjdop18004
	for mpls-outgoing; Thu, 24 Aug 2000 03:48:20 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjdop17999
	for <mpls@mail-control.mail.uu.net>; Thu, 24 Aug 2000 03:48:15 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjdop10827
	for <mpls@uu.net>; Wed, 23 Aug 2000 23:48:14 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjdop04595
	for <mpls@uu.net>; Thu, 24 Aug 2000 03:47:57 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id XAA21979
	for mpls@uu.net; Wed, 23 Aug 2000 23:47:57 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjdop17979
	for <mpls@mail-control.mail.uu.net>; Thu, 24 Aug 2000 03:47:37 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjdop15783
	for <mpls@UU.NET>; Wed, 23 Aug 2000 23:47:21 -0400 (EDT)
Received: from mailgate.sbell.com.cn by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.sbell.com.cn [202.96.203.173])
	id QQjdop04304
	for <mpls@UU.NET>; Thu, 24 Aug 2000 03:47:19 GMT
Received: from sdc.sbell.com.cn (sdc.sbell.com.cn [138.203.222.11])
	by mailgate.sbell.com.cn (8.9.2/8.9.2) with ESMTP id LAA11411
	for <mpls@UU.NET>; Thu, 24 Aug 2000 11:40:29 +0800 (CST)
Received: from bbx015.sbell.com.cn (bbx015 [138.203.222.185])
	by sdc.sbell.com.cn (8.9.1/8.9.1) with ESMTP id LAA27638
	for <mpls@UU.NET>; Thu, 24 Aug 2000 11:46:46 +0800 (CST)
Received: from sbell.com.cn (localhost [127.0.0.1])
	by bbx015.sbell.com.cn (8.9.1/8.9.1) with ESMTP id UAA02821
	for <mpls@UU.NET>; Wed, 23 Aug 2000 20:42:37 -0700 (PDT)
Message-ID: <39A499AD.B16D1C70@sbell.com.cn>
Date: Thu, 24 Aug 2000 11:42:37 +0800
From: Yuan Gu <guy@sh.bel.alcatel.be>
X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: questions on mpls-ldp-09
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Dear All:

I have some questions on  mpls-ldp-09.txt:

1.How many LSPs can be setup in same session?  If session fails for some
reason, do all LSPs in this session have to be released?

2. In section 3.5.2.1 Hello Message Procedures
Configuration Sequence Number:
What kind of session parameter can be changed by passive LSR without
noticed by active LSR? If receiving LSR detects a change in the
configuration in the sending LSR by detecting the change of
Configuration Sequence Number, beside clearing the session setup backoff
delay, what else the receiving LSR does? If receiving LSR playing the
passive role and detect the change, what does it do?

Thanks alot.
Yuan Gu




From owner-mpls@UU.NET  Wed Aug 23 23:58:57 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28607
	for <mpls-archive@lists.ietf.org>; Wed, 23 Aug 2000 23:58:57 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdop13901;
	Thu, 24 Aug 2000 03:58:51 GMT
Received: by mail-control.mail.uu.net 
	id QQjdop18426
	for mpls-outgoing; Thu, 24 Aug 2000 03:58:36 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjdop18421
	for <mpls@mail-control.mail.uu.net>; Thu, 24 Aug 2000 03:58:28 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjdop12192
	for <mpls@UU.NET>; Wed, 23 Aug 2000 23:58:24 -0400 (EDT)
Received: from NOD.RESTON.MCI.NET by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [166.60.6.38])
	id QQjdop13453
	for <mpls@UU.NET>; Thu, 24 Aug 2000 03:58:23 GMT
Received: from boni ([166.60.18.132])
 by shoe.reston.mci.net (PMDF V5.2-32 #40475)
 with SMTP id <01JTBTLJ3SKQ9LVBPH@shoe.reston.mci.net> for mpls@UU.NET; Wed,
 23 Aug 2000 23:58:23 EST
Date: Wed, 23 Aug 2000 23:58:00 -0500
From: Ron Bonica <rbonica@mci.net>
Subject: RE: Last Call: ICMP Extensions for MultiProtocol Label Switching
 toProposed Standard
In-reply-to: <Pine.BSF.4.21.0008201133080.15611-100000@shell16.ba.best.com>
To: "C. M. Heard" <heard@vvnet.com>, IETF <ietf@ietf.org>
Cc: IESG <iesg@ietf.org>, MPLS <mpls@UU.NET>
Message-id: <NBBBJGONOLIJDDNHNNBEKEAPEFAA.rbonica@mci.net>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7BIT

Mike,

The issue of RFC 1122/1812 compatibility was raised during WG last call.
Specifically, we considered the possibility that some existing applications
might rely upon information contained in the later bytes of the field in
question. (For the purposes of this message, let us refer to that field as
the "user data" field).

In response to this issue, the authors increased the length of the "user
data" field from 28 bytes to 128 bytes. Now we must consider the possibility
that some existing application still might be adversely effected in a
*significant* way.

As you stated, we have not identified any adversely effected applications.
Therefore, we can only speculate upon the kinds of data that applications
might glean from the ICMP user data field. Our best guess is that they would
be looking for routing and session identification information.

Therefore, if the user data field were long enough to contain all network
and transport layer headers, it would be long enough. This is in keeping
with the spirit, if not the letter, of RFC 1812.

A 128 byte length was chosen to accomodate this. It supports a few layers of
IP-in-IP tunneling with moderate use of IP options.

That said, I accept your comments regarding:

	-> renaming the document
	-> IANA control of Class-Num and C-Type
	-> adding verbage wrt the starting displacement of the common header in the
presence of options on the ICMP header

                                   Ron


> -----Original Message-----
> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of C. M.
> Heard
> Sent: Monday, August 21, 2000 1:13 AM
> To: IETF
> Cc: IESG; MPLS
> Subject: Re: Last Call: ICMP Extensions for MultiProtocol Label
> Switching toProposed Standard
>
>
> On Fri, 11 Aug 2000, The IESG wrote:
>
> > The IESG has received a request from the Multiprotocol Label Switching
> > Working Group to consider ICMP Extensions for MultiProtocol Label
> > Switching <draft-ietf-mpls-icmp-02.txt> as a Proposed Standard.
>
> The IESG and the IETF community are urged to carefully evaluate
> the above-referenced draft, as the ICMP extensions that it proposes
> require *modification of the format* of the ICMPv4 Destination
> Unreachable, Time Exceeded, Parameter Problem, Source Quench, and
> Redirect messages, and the proposed modifications are not entirely
> backward compatible with RFC 1122 and RFC 1812.
>
> The details of the proposal and the rationale for it are in the draft.
> Here is a quick overview.  The format of ICMPv4 error messages, as
> defined in RFCs 792, 1122, and 1812 is as follows:
>
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |     Type      |     Code      |          Checksum             |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                 varies according to message type              |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |Internet Header + at least 8 data octets from original datagram|
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> RFC 792 specifies that an ICMP error message must contain the Internet
> header plus 64 bits of the original datagram's data.  RFC 1122 specifies
> that an ICMP error message must contain the Internet header and at least
> the first 8 data octets of the datagram that triggered the error;  more
> than 8 octets MAY be sent;  this header and data MUST be unchanged
> from the received datagram.  RFC 1812 specifies that an ICMP error
> message SHOULD contain as much of the original datagram as possible
> without the length of the ICMP datagram exceeding 576 bytes.  The
> returned IP header (and user data) MUST be identical to that which
> was received, except that a router is not required to undo any
> modifications to the IP header that are normally performed in forwarding
> that were performed before the error was detected (e.g., decrementing
> the TTL, or updating options).
>
> The draft proposes to change this as follows:  the first 128 bytes
> following the 8-octet ICMP header will contain the original datagram's
> Internet header plus as much data as will fit in 128 bytes;  if the
> original datagram is shorter than 128 bytes then it will be padded
> with 0's.  Immediately after the 128 bytes of data from the original
> datagram there will be a checjsummed data structure containing TLV-encoded
> objects such as an MPLS label stack or additional returned user data.
>
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |     Type      |     Code      |          Checksum             |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                 varies according to message type              |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |Internet Header + as many data octets from original datagram as|
>    |will fit in 128 bytes (zero padded to 128 bytes if necessary)  |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                     Extension Data Structure                  |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> The proposed modification breaks the rule that the returned user data
> MUST be unchanged from the received datagram.
>
> The IESG and the IETF community are requested to carefully consider
> whether breaking this rule is likely to have adverse effects on
> deployed implementations.  I have not been able to find any applications
> that would be adversely affected, but I would like others who are more
> knowledgeable to have a hard look.
>
> Assuming that this proposal to modify ICMPv4 is accepted for
> standardization, I would suggest that the title of the draft
> be changed to reflect the fact that the extension data structure
> is not limited to MPLS-specific extensions, but can in principle
> accomodate other extensions as well.  Also, the extension header
> version and extension object Class-Num and C-Type fields will need
> to be under IANA control, and the document should have an "IANA
> Considerations" section (cf. RFC 2434).
>
> There are also some minor technical issues that I would like to point out.
>
> %  According to RFC-792, bytes 0 through 19 of any ICMP message contain
> %  a header whose format is analogous to that of the IP datagram. Bytes
> %  20 through 23 contain an ICMP message type, code and checksum. Bytes
> %  24 through 27 contain message specific data.
>
> I think that bytes 0 through 19 are supposed to be the Internet header
> of the IP datagram containing the ICMP message.  There may be more than
> 20 bytes if IP options are present, and the draft should mention this.
>
> %  Also according to RFC-792, the final field contained by each of the
> %  ICMP message types listed above begins at byte 28. It reflects the
> %  IP header and leading 64 bits of the original datagram. [RFC-1812]
> %  recommends that this final field be extended to include as much of
> %  the original datagram as possible.
>
> The final field is at offset 28 from the start of the IP datagram
> only in the absence if IP options.
>
> [ ... ]
>
> %  When an LSR appends the data structure defined herein to an ICMP
> %  message, the ICMP "total length" MUST be equal to the data structure
> %  length plus 156. The first octet of the data structure must be
> %  displaced 156 octets from the beginning of the ICMP message.
>
> The number 156 is accurate only in the absence of IP options.
>
> Cordially,
>
> C. M. Heard
> heard@vvnet.com
>
>
>



From owner-mpls@UU.NET  Thu Aug 24 01:49:04 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04776
	for <mpls-archive@lists.ietf.org>; Thu, 24 Aug 2000 01:49:04 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdox11396;
	Thu, 24 Aug 2000 05:48:55 GMT
Received: by mail-control.mail.uu.net 
	id QQjdox18360
	for mpls-outgoing; Thu, 24 Aug 2000 05:48:37 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjdox18355
	for <mpls@mail-control.mail.uu.net>; Thu, 24 Aug 2000 05:48:24 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjdox00832
	for <mpls@uu.net>; Thu, 24 Aug 2000 01:48:22 -0400 (EDT)
From: seenu@samsung.co.kr
Received: from omail01.samsung.co.kr by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: omail01.samsung.co.kr [203.254.197.73])
	id QQjdox10892
	for <mpls@uu.net>; Thu, 24 Aug 2000 05:48:21 GMT
Received: from localhost (root@localhost)
	by gp_xman. (8.8.8H1/8.8.8) with ESMTP id OAA20270
	for <mpls@uu.net>; Thu, 24 Aug 2000 14:49:10 +0900 (KST)
X-OpenMail-Hops: 3
Date: Thu, 24 Aug 2000 14:50:23 +0900
Message-Id: <H0000e6501cfe083.0967095251.secsw0@MHS>
Subject: Re : mpls LDP questions
MIME-Version: 1.0
TO: mpls@UU.NET
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline; filename="mail.txt"
	;Creation-Date="Thu, 24 Aug 2000 14:34:17 +0900"
	;Modification-Date="Thu, 24 Aug 2000 14:50:07 +0900"
Content-Transfer-Encoding: 8bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit


Hi Ellen,

>Is there any suggestion on 'how much the subsequent delay should grow for the
>session establishment setup attempt after the second NAK'd Initialization
>message'?

If the initial back-off timer is 15 sec , then it follows..... 15 30 60 120 ,...... seconds 
(exponential rise or power of 2 [as in BGP] )

>Is there a Shutdown msg in the LDP spec?  It is indicated in the initialization
>state transition table and diagram, but I couldn't find it in the spec.

There is no Shutdown msg in LDP, as such. But, it provides a Session Shutdown status code.
So, whenever an LSR needs to send a shutdown msg, it can do  so through Notification msg (with Shutdown status Code)
This is a fatal error msg. So, After sending this notification msg, the LSR should close the transport session and release all the 
label bindings. The receiving  LSR also should close the transport session and release all the label bindings.

regards
seenu

Thank you
Ellen



From owner-mpls@UU.NET  Thu Aug 24 11:31:06 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19234
	for <mpls-archive@lists.ietf.org>; Thu, 24 Aug 2000 11:31:06 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdqk27449;
	Thu, 24 Aug 2000 15:30:59 GMT
Received: by mail-control.mail.uu.net 
	id QQjdqk21960
	for mpls-outgoing; Thu, 24 Aug 2000 15:30:38 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjdqk21955
	for <mpls@mail-control.mail.uu.net>; Thu, 24 Aug 2000 15:30:27 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjdqk13864
	for <mpls@uu.net>; Thu, 24 Aug 2000 11:30:12 -0400 (EDT)
Received: from devmail.dev.tivoli.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: devmail.dev.tivoli.com [208.230.244.136])
	id QQjdqj26336
	for <mpls@uu.net>; Thu, 24 Aug 2000 15:29:42 GMT
Received: from madev-dns.ma.dev.tivoli.com (madev-dns.ma.dev.tivoli.com [146.84.242.19])
	by devmail.dev.tivoli.com (8.9.1/8.8.8) with ESMTP id KAA15132
	for <mpls@uu.net>; Thu, 24 Aug 2000 10:29:37 -0500 (CDT)
Received: from ptasillo (ptasillo.ma.dev.tivoli.com [146.84.242.70])
	by madev-dns.ma.dev.tivoli.com (8.8.8/8.8.8) with SMTP id LAA11174
	for <mpls@uu.net>; Thu, 24 Aug 2000 11:31:48 -0400 (EDT)
From: "Paul Tasillo" <Paul.tasillo@tivoli.com>
To: <mpls@UU.NET>
Subject: FW: FW: basic MPLS ATM question
Date: Thu, 24 Aug 2000 11:29:25 -0400
Message-ID: <NEBBIBNGLENPLIBOMGAMGEDPCAAA.Paul.tasillo@tivoli.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Thank you for the insight.
So if I understand correctly, there are three possible MPLS over ATM
schemes:
1. ATM-LSR: Here the the LSR (maybe all of the links) has a IP address and
participates in L3 routing protocols. MPLS controls signaling and assigns
VPI/VCIs in a meaningful way to create VC to next hops.
2. The ATM cloud has a mesh of PVC which MPLS uses as ptp links. This is
frame based not cell based. This is an overlay model where MPLS works on top
of CLIP or LANE? And the LSR still participate in L3 routing protocols? (as
well as ATM routing protocols being run).
3. the VCID case. Again an overlay model where there exists CLIP or LANE
except here MPLS coordinates with ATM signaling to create SVCs as needed. L3
& ATM routing protocols are run.

Is this correct? If so case 1 would seem to be the preferable solution in
order for MPLS to allow ATM to scale and to reduce configuration headaches.

-Paul
-----Original Message-----
From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Jeremy
Lawrence
Sent: Wednesday, August 23, 2000 8:40 PM
To: Paul Tasillo
Cc: mpls@UU.NET
Subject: Re: FW: basic MPLS ATM question


At 17:54 08/23/2000 -0400, Paul Tasillo wrote:


>Hi-
>        In draft-ietf-mpls-ldp-applic-02.txt it says,
>
>  LDP, together with an IP routing plane and software to program ATM
>   switch or Frame Relay switch cross-connect tables, can implement IP
>   in a network of ATM and/or Frame Relay switches without requiring an
>   overlay or the use of ATM-specific or Frame Relay-specific addressing
>   or routing.
>
>In the absence of ATM/FR specific addressing or routing, what is being used
>for addressing? If the answer is IP, then am I safe in assuming that this
>requires each ATM switch to have an IP address?

Yes, in the same way that a router does, for the purposes of
participating in an IP routing protocol. (From the perspective
of an IP routing protocol, an ATM-LSR is indistinguishable from
a router.) The links may also have IP addresses.

>I understand the ATM
>switches will be participating in L3 routing protocols (BGP, OSPF, etc).
>
>Is there also an overlay MPLS model? Where MPLS make decisions on a frame
>basis rather then cell and uses ATM/FR specifc addressing and routing?

Aside from VCID (covered in another email), MPLS-enabled routers
can be connected by RFC 1483 (or whatever the latest RFC number is)
PVCs. This is like ordinary IP over ATM, except that it is
frame-based MPLS over ATM. The PVCs act like any other non-channelized
point-to-point link between frame-based LSRs.

Regards,

Jeremy Lawrence




From owner-mpls@UU.NET  Thu Aug 24 11:42:12 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19408
	for <mpls-archive@lists.ietf.org>; Thu, 24 Aug 2000 11:42:12 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdqk06413;
	Thu, 24 Aug 2000 15:42:05 GMT
Received: by mail-control.mail.uu.net 
	id QQjdqk23209
	for mpls-outgoing; Thu, 24 Aug 2000 15:41:39 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjdqk23199
	for <mpls@mail-control.mail.uu.net>; Thu, 24 Aug 2000 15:41:31 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjdqk15752
	for <mpls@UU.NET>; Thu, 24 Aug 2000 11:41:25 -0400 (EDT)
Received: from icarian.ZAFFIRE.COM by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ATHM-64-232-xxx-132.home.net [64.232.69.132] (may be forged))
	id QQjdqk05444
	for <mpls@UU.NET>; Thu, 24 Aug 2000 15:40:55 GMT
Received: by ICARIAN with Internet Mail Service (5.5.2650.21)
	id <QX145MKG>; Thu, 24 Aug 2000 08:49:04 -0700
Message-ID: <4D3F9F2BEC58D4118FCE009027B0A6621361C6@ICARIAN>
From: Eric Gray <EGray@zaffire.com>
To: "'Yuan Gu'" <guy@sh.bel.alcatel.be>, mpls@UU.NET
Subject: RE: questions on mpls-ldp-09
Date: Thu, 24 Aug 2000 08:49:04 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Yuan,

	Please see embedded comments below.

> -----Original Message-----
> From: Yuan Gu [mailto:guy@sh.bel.alcatel.be]
> Sent: Wednesday, August 23, 2000 8:43 PM
> To: mpls@UU.NET
> Subject: questions on mpls-ldp-09
> 
> 
> Dear All:
> 
> I have some questions on  mpls-ldp-09.txt:
> 
> 1.How many LSPs can be setup in same session?  

As many as the two LSRs can maintain state for.
There is no artificially imposed limit.

> If session fails for some reason, do all LSPs in 
> this session have to be released?

Currently, yes.  See the draft on Fault Tolerant 
LDP - which was accepted as a working group draft
at the last IETF meeting - for how LSP state may
be preserved across LDP sessions.
 
> 2. In section 3.5.2.1 Hello Message Procedures
> Configuration Sequence Number:
> What kind of session parameter can be changed by passive LSR without
> noticed by active LSR? If receiving LSR detects a change in the
> configuration in the sending LSR by detecting the change of
> Configuration Sequence Number, beside clearing the session 
> setup backoff
> delay, what else the receiving LSR does? If receiving LSR playing the
> passive role and detect the change, what does it do?

The intent of the configuration sequence number is
to allow the active peer to be able to find out that
the passive peer has been re-configured.  

Why do we want to allow this?  

Because we can assume that a likely reason why two 
peers are unable to establish a session is that they 
have been configured with session parameters that are 
incompatible.  In this event, each repeated attempt
will fail and - with exponential back-off - each
new attempt will be delayed by an interval that is
twice what it was in the immediate prior attempt.
Obviously, this delay can grow to be quite large.
The inclusion of a changed configuration sequence 
number in a Hello message from the passive peer 
signals the active peer that it might ignore the
current retry delay and try again immediately.

Since the passive peer does not control when an
attempt will be made (it does not initiate LDP
session establishment), it does not matter if it
detects a change in the configuration sequence
number.  If the active peer has been re-configured,
it can initiate LDP session establishment on its
own (without sending a configuration sequence
number to its passive peer or peers).

> 
> Thanks alot.
> Yuan Gu
> 
> 


From owner-mpls@UU.NET  Thu Aug 24 12:14:16 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19903
	for <mpls-archive@lists.ietf.org>; Thu, 24 Aug 2000 12:14:16 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdqm28731;
	Thu, 24 Aug 2000 16:14:11 GMT
Received: by mail-control.mail.uu.net 
	id QQjdqm07802
	for mpls-outgoing; Thu, 24 Aug 2000 16:13:38 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjdqm07791
	for <mpls@mail-control.mail.uu.net>; Thu, 24 Aug 2000 16:13:20 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjdqm14901
	for <mpls@UU.NET>; Thu, 24 Aug 2000 12:13:17 -0400 (EDT)
From: mukul@texas.cplane.com
Received: from cplane.com by wodc7mr2.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: jersey.cplane.com [63.193.105.226])
	id QQjdqm29936
	for <mpls@UU.NET>; Thu, 24 Aug 2000 16:13:16 GMT
Received: (qmail 29007 invoked from network); 24 Aug 2000 14:53:05 -0000
Received: from unknown (HELO texas.cplane.com) (unknown)
  by unknown with SMTP; 24 Aug 2000 14:53:05 -0000
Received: (qmail 27373 invoked by uid 1038); 24 Aug 2000 16:13:07 -0000
Message-ID: <20000824161307.27372.qmail@texas.cplane.com>
Subject: Re: FW: FW: basic MPLS ATM question
To: Paul.tasillo@tivoli.com (Paul Tasillo)
Date: Thu, 24 Aug 2000 09:13:07 -0700 (PDT)
Cc: mpls@UU.NET
In-Reply-To: <NEBBIBNGLENPLIBOMGAMGEDPCAAA.Paul.tasillo@tivoli.com> from "Paul Tasillo" at Aug 24, 2000 11:29:25 AM
X-Mailer: ELM [version 2.5 PL3]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


> 
> Thank you for the insight.
> So if I understand correctly, there are three possible MPLS over ATM
> schemes:

Yes..

> 1. ATM-LSR: Here the the LSR (maybe all of the links) has a IP address and
> participates in L3 routing protocols. MPLS controls signaling and assigns
> VPI/VCIs in a meaningful way to create VC to next hops.

 In the first case the ATM switch could also be running ATM protocols
 and participate in a ATM cloud (ships in Night mode). 

> 2. The ATM cloud has a mesh of PVC which MPLS uses as ptp links. This is
> frame based not cell based. This is an overlay model where MPLS works on top
> of CLIP or LANE? And the LSR still participate in L3 routing protocols? (as
> well as ATM routing protocols being run).


   The third model is not an overlay case, rather in this the 
  MPLS LSP is established with direct peering with the ATM.  
  
 Regards
 - Mukul

> 3. the VCID case. Again an overlay model where there exists CLIP or LANE
> except here MPLS coordinates with ATM signaling to create SVCs as needed. L3
> & ATM routing protocols are run.
> 
  
> Is this correct? If so case 1 would seem to be the preferable solution in
> order for MPLS to allow ATM to scale and to reduce configuration headaches.
> 
> -Paul
> -----Original Message-----
> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Jeremy
> Lawrence
> Sent: Wednesday, August 23, 2000 8:40 PM
> To: Paul Tasillo
> Cc: mpls@UU.NET
> Subject: Re: FW: basic MPLS ATM question
> 
> 
> At 17:54 08/23/2000 -0400, Paul Tasillo wrote:
> 
> 
> >Hi-
> >        In draft-ietf-mpls-ldp-applic-02.txt it says,
> >
> >  LDP, together with an IP routing plane and software to program ATM
> >   switch or Frame Relay switch cross-connect tables, can implement IP
> >   in a network of ATM and/or Frame Relay switches without requiring an
> >   overlay or the use of ATM-specific or Frame Relay-specific addressing
> >   or routing.
> >
> >In the absence of ATM/FR specific addressing or routing, what is being used
> >for addressing? If the answer is IP, then am I safe in assuming that this
> >requires each ATM switch to have an IP address?
> 
> Yes, in the same way that a router does, for the purposes of
> participating in an IP routing protocol. (From the perspective
> of an IP routing protocol, an ATM-LSR is indistinguishable from
> a router.) The links may also have IP addresses.
> 
> >I understand the ATM
> >switches will be participating in L3 routing protocols (BGP, OSPF, etc).
> >
> >Is there also an overlay MPLS model? Where MPLS make decisions on a frame
> >basis rather then cell and uses ATM/FR specifc addressing and routing?
> 
> Aside from VCID (covered in another email), MPLS-enabled routers
> can be connected by RFC 1483 (or whatever the latest RFC number is)
> PVCs. This is like ordinary IP over ATM, except that it is
> frame-based MPLS over ATM. The PVCs act like any other non-channelized
> point-to-point link between frame-based LSRs.
> 
> Regards,
> 
> Jeremy Lawrence
> 
> 
> 



From owner-mpls@UU.NET  Thu Aug 24 14:39:27 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22113
	for <mpls-archive@lists.ietf.org>; Thu, 24 Aug 2000 14:39:26 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdqw13825;
	Thu, 24 Aug 2000 18:39:20 GMT
Received: by mail-control.mail.uu.net 
	id QQjdqw11201
	for mpls-outgoing; Thu, 24 Aug 2000 18:38:58 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjdqw11196
	for <mpls@mail-control.mail.uu.net>; Thu, 24 Aug 2000 18:38:55 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjdqw10590
	for <mpls@uu.net>; Thu, 24 Aug 2000 14:38:49 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjdqw12483
	for <mpls@uu.net>; Thu, 24 Aug 2000 18:38:48 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA04794
	for mpls@uu.net; Thu, 24 Aug 2000 14:38:47 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjdqw11110
	for <mpls@mail-control.mail.uu.net>; Thu, 24 Aug 2000 18:38:23 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjdqw17165
	for <mpls@UU.NET>; Thu, 24 Aug 2000 14:38:14 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88])
	id QQjdqw11824
	for <mpls@UU.NET>; Thu, 24 Aug 2000 18:37:59 GMT
Received: from bulkrate.cisco.com (bulkrate.cisco.com [171.71.160.24])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id LAA12253;
	Thu, 24 Aug 2000 11:38:17 -0700 (PDT)
Received: from jlawrenc-pc.cisco.com (dhcp-71-56-188.cisco.com [171.71.56.188])
	by bulkrate.cisco.com (Mirapoint)
	with ESMTP id ABU12328;
	Thu, 24 Aug 2000 11:38:05 -0700 (PDT)
Message-Id: <4.3.2.7.2.20000824110025.00b05160@bulkrate.cisco.com>
X-Sender: jlawrenc@bulkrate.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 24 Aug 2000 11:37:16 -0700
To: "Paul Tasillo" <Paul.tasillo@tivoli.com>
From: Jeremy Lawrence <jlawrenc@cisco.com>
Subject: Re: FW: FW: basic MPLS ATM question
Cc: <mpls@UU.NET>
In-Reply-To: <NEBBIBNGLENPLIBOMGAMGEDPCAAA.Paul.tasillo@tivoli.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-mpls@UU.NET
Precedence: bulk

At 11:29 08/24/2000 -0400, Paul Tasillo wrote:
>Thank you for the insight.
>So if I understand correctly, there are three possible MPLS over ATM
>schemes:

Actually four: I'll add one at the end.

>1. ATM-LSR: Here the the LSR (maybe all of the links) has a IP address and
>participates in L3 routing protocols. MPLS controls signaling and assigns
>VPI/VCIs in a meaningful way to create VC to next hops.

True.

>2. The ATM cloud has a mesh of PVC which MPLS uses as ptp links. This is
>frame based not cell based. This is an overlay model where MPLS works on top
>of CLIP or LANE? 

Yes and no. This mode is vaguely similar to CLIP: MPLS just runs over
RFC2684 (successor to RFC1483) over a PVC. However MPLS-over-PVCs is
not MPLS-over-CLIP (i.e. MPLS over IP over ATM), it is something
different: frame-based MPLS over ATM. It has nothing to do with LANE.

>And the LSR still participate in L3 routing protocols? (as
>well as ATM routing protocols being run).

In this model, the ATM switches are not LSRs. The LSRs are the
routers at the end of the (S)PVCs, which do run IP routing protocols.
The ATM switches do whatever they do to route (S)PVCs, but that is
invisible to MPLS. 

>3. the VCID case. Again an overlay model where there exists CLIP or LANE

Same answer as #2: similar but not identical to CLIP, nothing to
do with LANE. 

>except here MPLS coordinates with ATM signaling to create SVCs as needed. L3
>& ATM routing protocols are run.

That's not really true. The routing situation is actually very similar
to #2. The ATM switches, or most of them, are not LSRs, and just run an
SVC routing protocol (typically PNNI). The LSRs run IP routing,
but don't really participate in PNNI, except to request SVC
set-ups.

The major difference between #2 and #3 is that VCID adds some hooks to
support SVCs as well as PVCs. Otherwise, they're fairly similar.


Here's the other one:

4. Virtual Trunks. This is similar to #2, except that PVPs or SPVPs
are used instead of (S)PVCs. This means several things:
- The LSRs at the ends of the PVPs use ATM MPLS encapsulation, with
  distinct VCs within the PVP signifying distinct labels.
- The PVPs are 'virtual trunks', performing much the same function
  as a physical ATM link between the LSRs terminating the PVPs.
- Again, not all ATM switches are LSRs.
- The PVPs may terminate on ATM-LSRs, which may switch between
  ordinary ATM MPLS links (scheme #1) and virtual trunks. These
  ATM-LSRs run both IP routing and whatever the switch uses for
  (S)PVPs, but there is no interaction between the two.


For interworking between CLIP or LANE and ATM MPLS, any of these
schemes can be used, with the edge LSRs having some CLIP or LANE
interfaces and some ATM MPLS. CLIP or LANE and ATM MPLS are 
quite different IP-over-ATM schemes, and a full layer 3 routing
function (e.g. in an edge LSR) is usually required to interwork
between them.

Regards,

Jeremy Lawrence



From owner-mpls@UU.NET  Thu Aug 24 15:45:39 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22990
	for <mpls-archive@lists.ietf.org>; Thu, 24 Aug 2000 15:45:39 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdrb00300;
	Thu, 24 Aug 2000 19:45:32 GMT
Received: by mail-control.mail.uu.net 
	id QQjdra27967
	for mpls-outgoing; Thu, 24 Aug 2000 19:44:55 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjdra27959
	for <mpls@mail-control.mail.uu.net>; Thu, 24 Aug 2000 19:44:46 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjdra29924
	for <mpls@UU.NET>; Thu, 24 Aug 2000 15:44:34 -0400 (EDT)
Received: from cplane.com by wodc7mr1.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: jersey.cplane.com [63.193.105.226])
	id QQjdra29551
	for <mpls@UU.NET>; Thu, 24 Aug 2000 19:44:33 GMT
Received: (qmail 30000 invoked from network); 24 Aug 2000 18:24:24 -0000
Received: from unknown (HELO texas.cplane.com) (unknown)
  by unknown with SMTP; 24 Aug 2000 18:24:24 -0000
Received: (qmail 31789 invoked from network); 24 Aug 2000 19:44:26 -0000
Received: from unknown (HELO cplane.com) (unknown)
  by unknown with SMTP; 24 Aug 2000 19:44:26 -0000
Message-ID: <39A57B1A.44DE3F5F@cplane.com>
Date: Thu, 24 Aug 2000 12:44:26 -0700
From: Mukul Katiyar <mukul@cplane.com>
Reply-To: mukul@cplane.com
Organization: Cplane Inc
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Jeremy Lawrence <jlawrenc@cisco.com>, mpls@UU.NET, mukul@cplane.com
Subject: Re: FW: FW: basic MPLS ATM question
References: <4.3.2.7.2.20000824110025.00b05160@bulkrate.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Jeremy,

> 
> >3. the VCID case. Again an overlay model where there exists CLIP or LANE
> 
> Same answer as #2: similar but not identical to CLIP, nothing to
> do with LANE.
> 
> >except here MPLS coordinates with ATM signaling to create SVCs as needed. L3
> >& ATM routing protocols are run.
> 
> That's not really true. The routing situation is actually very similar
> to #2. The ATM switches, or most of them, are not LSRs, and just run an
> SVC routing protocol (typically PNNI). The LSRs run IP routing,
> but don't really participate in PNNI, except to request SVC
> set-ups.
> 
> The major difference between #2 and #3 is that VCID adds some hooks to
> support SVCs as well as PVCs. Otherwise, they're fairly similar.
> 

I think #2 and #3 are similar only from the point
of view of mix of ATM and MPLS signalling & routing
protocols used for setting up the channels,
but they differ fundamentally with respect to their models. 
While #2 is a classical overlay model, the MPLS network
remains unaware of the existence of
ATM switched connections, and multiple LSPs "share" the same ATM
virtual connection using it as a virtual link. 

The #3 is a peer model whereby the LSP is tunneled through the
ATM network using ATM signalling. The edge LSRs in this case are
certainly aware of existance of the ATM switched connections and
trigger the tunnel establishment for the LSP.
The encapsulation used for #3 is similar to #1 as specified in 
draft-ietf-mpls-atm-04.txt, rather then that of #2 which shall
use what ever has been established by CLIP or LANE.
I think this makes the case #3 to be similar to #1 rather then #2.
please correct me if I am missing something.

regards
Mukul

> Here's the other one:
> 
> 4. Virtual Trunks. This is similar to #2, except that PVPs or SPVPs
> are used instead of (S)PVCs. This means several things:
> - The LSRs at the ends of the PVPs use ATM MPLS encapsulation, with
>   distinct VCs within the PVP signifying distinct labels.
> - The PVPs are 'virtual trunks', performing much the same function
>   as a physical ATM link between the LSRs terminating the PVPs.
> - Again, not all ATM switches are LSRs.
> - The PVPs may terminate on ATM-LSRs, which may switch between
>   ordinary ATM MPLS links (scheme #1) and virtual trunks. These
>   ATM-LSRs run both IP routing and whatever the switch uses for
>   (S)PVPs, but there is no interaction between the two.
> 
> For interworking between CLIP or LANE and ATM MPLS, any of these
> schemes can be used, with the edge LSRs having some CLIP or LANE
> interfaces and some ATM MPLS. CLIP or LANE and ATM MPLS are
> quite different IP-over-ATM schemes, and a full layer 3 routing
> function (e.g. in an edge LSR) is usually required to interwork
> between them.
> 
> Regards,
> 
> Jeremy Lawrence


From owner-mpls@UU.NET  Thu Aug 24 16:48:03 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23780
	for <mpls-archive@lists.ietf.org>; Thu, 24 Aug 2000 16:48:03 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdrf21733;
	Thu, 24 Aug 2000 20:47:57 GMT
Received: by mail-control.mail.uu.net 
	id QQjdrf17289
	for mpls-outgoing; Thu, 24 Aug 2000 20:47:31 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjdrf17280
	for <mpls@mail-control.mail.uu.net>; Thu, 24 Aug 2000 20:47:24 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjdrf05099
	for <mpls@UU.NET>; Thu, 24 Aug 2000 16:45:50 -0400 (EDT)
Received: from brick.setuidzero.org by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: brick.setuidzero.org [209.183.207.172])
	id QQjdrf17695
	for <mpls@UU.NET>; Thu, 24 Aug 2000 20:45:42 GMT
Received: from ebwin2k (gdffw1.denver1.level3.net [209.244.1.161])
	by brick.setuidzero.org (8.9.3/8.8.7) with SMTP id QAA06303;
	Thu, 24 Aug 2000 16:39:13 -0400
From: "Edward Brookhouse" <ebroo@setuidzero.org>
To: "Eric Gray" <EGray@zaffire.com>, "'Yuan Gu'" <guy@sh.bel.alcatel.be>,
        <mpls@UU.NET>
Subject: RE: questions on mpls-ldp-09
Date: Thu, 24 Aug 2000 14:35:05 -0600
Message-ID: <PAEDJBCFFBIIBEJLEEBCOEGECAAA.ebroo@setuidzero.org>
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
In-Reply-To: <4D3F9F2BEC58D4118FCE009027B0A6621361C6@ICARIAN>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


Is the draft-farrel-mpls-ldp-ft-00.txt the latest version of the draft ??

Thanks 

Edward


-----Original Message-----
From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Eric Gray
Sent: Thursday, August 24, 2000 9:49 AM
To: 'Yuan Gu'; mpls@UU.NET
Subject: RE: questions on mpls-ldp-09


Yuan,

	Please see embedded comments below.

> -----Original Message-----
> From: Yuan Gu [mailto:guy@sh.bel.alcatel.be]
> Sent: Wednesday, August 23, 2000 8:43 PM
> To: mpls@UU.NET
> Subject: questions on mpls-ldp-09
> 
> 
> Dear All:
> 
> I have some questions on  mpls-ldp-09.txt:
> 
> 1.How many LSPs can be setup in same session?  

As many as the two LSRs can maintain state for.
There is no artificially imposed limit.

> If session fails for some reason, do all LSPs in 
> this session have to be released?

Currently, yes.  See the draft on Fault Tolerant 
LDP - which was accepted as a working group draft
at the last IETF meeting - for how LSP state may
be preserved across LDP sessions.
 
> 2. In section 3.5.2.1 Hello Message Procedures
> Configuration Sequence Number:
> What kind of session parameter can be changed by passive LSR without
> noticed by active LSR? If receiving LSR detects a change in the
> configuration in the sending LSR by detecting the change of
> Configuration Sequence Number, beside clearing the session 
> setup backoff
> delay, what else the receiving LSR does? If receiving LSR playing the
> passive role and detect the change, what does it do?

The intent of the configuration sequence number is
to allow the active peer to be able to find out that
the passive peer has been re-configured.  

Why do we want to allow this?  

Because we can assume that a likely reason why two 
peers are unable to establish a session is that they 
have been configured with session parameters that are 
incompatible.  In this event, each repeated attempt
will fail and - with exponential back-off - each
new attempt will be delayed by an interval that is
twice what it was in the immediate prior attempt.
Obviously, this delay can grow to be quite large.
The inclusion of a changed configuration sequence 
number in a Hello message from the passive peer 
signals the active peer that it might ignore the
current retry delay and try again immediately.

Since the passive peer does not control when an
attempt will be made (it does not initiate LDP
session establishment), it does not matter if it
detects a change in the configuration sequence
number.  If the active peer has been re-configured,
it can initiate LDP session establishment on its
own (without sending a configuration sequence
number to its passive peer or peers).

> 
> Thanks alot.
> Yuan Gu
> 
> 



From owner-mpls@UU.NET  Thu Aug 24 19:32:35 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25367
	for <mpls-archive@lists.ietf.org>; Thu, 24 Aug 2000 19:32:35 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdrq17542;
	Thu, 24 Aug 2000 23:32:29 GMT
Received: by mail-control.mail.uu.net 
	id QQjdrq25413
	for mpls-outgoing; Thu, 24 Aug 2000 23:31:51 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjdrq25401
	for <mpls@mail-control.mail.uu.net>; Thu, 24 Aug 2000 23:31:34 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjdrq14029
	for <mpls@UU.NET>; Thu, 24 Aug 2000 19:31:32 -0400 (EDT)
Received: from inet-tsb.toshiba.co.jp by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: inet-tsb.toshiba.co.jp [202.33.96.40])
	id QQjdrq18250
	for <mpls@UU.NET>; Thu, 24 Aug 2000 23:31:01 GMT
Received: from tis2.tis.toshiba.co.jp (tis2 [133.199.160.66])
	by inet-tsb.toshiba.co.jp (3.7W:TOSHIBA-ISC-2000030918) with ESMTP id IAA19479;
	Fri, 25 Aug 2000 08:30:54 +0900 (JST)
Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp (8.8.4+2.7Wbeta4/3.3W9-95082317)
	id IAA15704; Fri, 25 Aug 2000 08:30:54 +0900 (JST)
Received: from chappy.cns.fuchu.toshiba.co.jp by toshiba.co.jp (8.7.1+2.6Wbeta4/3.3W9-TOSHIBA-GLOBAL SERVER) id IAA13581; Fri, 25 Aug 2000 08:30:53 +0900 (JST)
Received: from localhost (localhost [127.0.0.1])
	by chappy.cns.fuchu.toshiba.co.jp (8.9.3/8.9.3) with ESMTP id IAA24505;
	Fri, 25 Aug 2000 08:34:04 +0900 (JST)
	(envelope-from nagami@cns.fuchu.toshiba.co.jp)
Date: Fri, 25 Aug 2000 08:33:58 +0900
Message-ID: <ydcaee2fd3t.wl@chappy.cns.fuchu.toshiba.co.jp>
From: Ken Nagami <ken.nagami@toshiba.co.jp>
To: mukul@cplane.com
Cc: jlawrenc@cisco.com, mpls@UU.NET
Subject: Re: FW: FW: basic MPLS ATM question
In-Reply-To: In your message of "Thu, 24 Aug 2000 12:44:26 -0700"
	<39A57B1A.44DE3F5F@cplane.com>
References: <4.3.2.7.2.20000824110025.00b05160@bulkrate.cisco.com>
	<39A57B1A.44DE3F5F@cplane.com>
User-Agent: Wanderlust/1.1.1 (Purple Rain) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.4 (i386-unknown-freebsdelf3.3) MULE/4.0 (HANANOEN)
Organization: Toshiba
MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu")
Content-Type: text/plain; charset=US-ASCII
X-Dispatcher: imput version 990905(IM130)
Lines: 43
Sender: owner-mpls@UU.NET
Precedence: bulk

Mukul, 

VCID is used on a cell based LSR not a frame based LSR. So, in this
point, the #3 is similar to the #1. The major differnce between #1 and
#3 is that ATM-LSRs are connected through ATM switches and 
VCID procedure adds some hooks to support SVCs/PVCs through ATM switches.

Regards, 
Ken Nagami

> > >3. the VCID case. Again an overlay model where there exists CLIP or LANE
> > >except here MPLS coordinates with ATM signaling to create SVCs as needed. L3
> > >& ATM routing protocols are run.
> > 
> > That's not really true. The routing situation is actually very similar
> > to #2. The ATM switches, or most of them, are not LSRs, and just run an
> > SVC routing protocol (typically PNNI). The LSRs run IP routing,
> > but don't really participate in PNNI, except to request SVC
> > set-ups.
> > 
> > The major difference between #2 and #3 is that VCID adds some hooks to
> > support SVCs as well as PVCs. Otherwise, they're fairly similar.
> > 
> 
> I think #2 and #3 are similar only from the point
> of view of mix of ATM and MPLS signalling & routing
> protocols used for setting up the channels,
> but they differ fundamentally with respect to their models. 
> While #2 is a classical overlay model, the MPLS network
> remains unaware of the existence of
> ATM switched connections, and multiple LSPs "share" the same ATM
> virtual connection using it as a virtual link. 
> 
> The #3 is a peer model whereby the LSP is tunneled through the
> ATM network using ATM signalling. The edge LSRs in this case are
> certainly aware of existance of the ATM switched connections and
> trigger the tunnel establishment for the LSP.
> The encapsulation used for #3 is similar to #1 as specified in 
> draft-ietf-mpls-atm-04.txt, rather then that of #2 which shall
> use what ever has been established by CLIP or LANE.
> I think this makes the case #3 to be similar to #1 rather then #2.
> please correct me if I am missing something.



From owner-mpls@UU.NET  Fri Aug 25 06:44:53 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15361
	for <mpls-archive@lists.ietf.org>; Fri, 25 Aug 2000 06:44:53 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdti06913;
	Fri, 25 Aug 2000 10:44:42 GMT
Received: by mail-control.mail.uu.net 
	id QQjdti13609
	for mpls-outgoing; Fri, 25 Aug 2000 10:44:11 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjdti13601
	for <mpls@mail-control.mail.uu.net>; Fri, 25 Aug 2000 10:44:00 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjdti18051
	for <mpls@uu.net>; Fri, 25 Aug 2000 06:43:58 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjdti06339
	for <mpls@uu.net>; Fri, 25 Aug 2000 10:43:57 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA14528
	for mpls@uu.net; Fri, 25 Aug 2000 06:43:57 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjdti13582
	for <mpls@mail-control.mail.uu.net>; Fri, 25 Aug 2000 10:43:35 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjdti17997
	for <mpls@uu.net>; Fri, 25 Aug 2000 06:43:33 -0400 (EDT)
Received: from ietf.org by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: odin.ietf.org [132.151.1.176])
	id QQjdti06073
	for <mpls@uu.net>; Fri, 25 Aug 2000 10:43:32 GMT
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15311;
	Fri, 25 Aug 2000 06:43:34 -0400 (EDT)
Message-Id: <200008251043.GAA15311@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;
Cc: mpls@UU.NET
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mpls-ldp-11.txt
Date: Fri, 25 Aug 2000 06:43:33 -0400
Sender: owner-mpls@UU.NET
Precedence: bulk

--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		: LDP Specification
	Author(s)	: L. Andersson, P. Doolan, N. Feldman,
                          A. Fredette, B. Thomas
	Filename	: draft-ietf-mpls-ldp-11.txt
	Pages		: 135
	Date		: 24-Aug-00
	
The architecture for Multi Protocol Label Switching (MPLS) is
described in [ARCH].  A fundamental concept in MPLS is that two Label
Switching Routers (LSRs) must agree on the meaning of the labels used
to forward traffic between and through them.  This common
understanding is achieved by using a set of procedures, called a
label distribution protocol, by which one LSR informs another of
label bindings it has made.  This document defines a set of such
procedures called LDP (for Label Distribution Protocol) by which LSRs
distribute labels to support MPLS forwarding along normally routed
paths [LDPAPPLIC].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-11.txt

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-ldp-11.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-ldp-11.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:	<20000824100418.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mpls-ldp-11.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mpls-ldp-11.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000824100418.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-mpls@UU.NET  Fri Aug 25 06:45:38 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15375
	for <mpls-archive@lists.ietf.org>; Fri, 25 Aug 2000 06:45:38 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdtj12303;
	Fri, 25 Aug 2000 10:45:25 GMT
Received: by mail-control.mail.uu.net 
	id QQjdti13622
	for mpls-outgoing; Fri, 25 Aug 2000 10:44:52 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjdti13617
	for <mpls@mail-control.mail.uu.net>; Fri, 25 Aug 2000 10:44:35 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjdti18127
	for <mpls@uu.net>; Fri, 25 Aug 2000 06:44:31 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjdti06520
	for <mpls@uu.net>; Fri, 25 Aug 2000 10:44:16 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA14552
	for mpls@uu.net; Fri, 25 Aug 2000 06:44:15 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjdti13599
	for <mpls@mail-control.mail.uu.net>; Fri, 25 Aug 2000 10:43:59 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjdti29517
	for <mpls@uu.net>; Fri, 25 Aug 2000 06:43:58 -0400 (EDT)
Received: from ietf.org by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: odin.ietf.org [132.151.1.176])
	id QQjdti06022
	for <mpls@uu.net>; Fri, 25 Aug 2000 10:43:28 GMT
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15297;
	Fri, 25 Aug 2000 06:43:29 -0400 (EDT)
Message-Id: <200008251043.GAA15297@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;
Cc: mpls@UU.NET
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mpls-rsvp-lsp-tunnel-07.txt
Date: Fri, 25 Aug 2000 06:43:29 -0400
Sender: owner-mpls@UU.NET
Precedence: bulk

--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		: RSVP-TE: Extensions to RSVP for LSP Tunnels
	Author(s)	: D. Awduche, L. Berger, D. Gan, T. Li, 
                          V. Srinivasan, G. Swallow
	Filename	: draft-ietf-mpls-rsvp-lsp-tunnel-07.txt
	Pages		: 62
	Date		: 24-Aug-00
	
This document describes the use of RSVP, including all the necessary
extensions, to establish label-switched paths (LSPs) in MPLS.  Since
the flow along an LSP is completely identified by the label applied
at the ingress node of the path, these paths may be treated as
tunnels.  A key application of LSP tunnels is traffic engineering
with MPLS as specified in [3].
We propose several additional objects that extend RSVP, allowing the
establishment of explicitly routed label switched paths using RSVP as
a signaling protocol.  The result is the instantiation of label-
switched tunnels which can be automatically routed  away from network
failures, congestion, and bottlenecks.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-lsp-tunnel-07.txt

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-rsvp-lsp-tunnel-07.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mpls-rsvp-lsp-tunnel-07.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20000824100408.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mpls-rsvp-lsp-tunnel-07.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mpls-rsvp-lsp-tunnel-07.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000824100408.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-mpls@UU.NET  Fri Aug 25 09:03:35 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19471
	for <mpls-archive@lists.ietf.org>; Fri, 25 Aug 2000 09:03:35 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdts05961;
	Fri, 25 Aug 2000 13:03:22 GMT
Received: by mail-control.mail.uu.net 
	id QQjdts24492
	for mpls-outgoing; Fri, 25 Aug 2000 13:02:52 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjdts24473
	for <mpls@mail-control.mail.uu.net>; Fri, 25 Aug 2000 13:02:51 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjdts05514
	for <mpls@uu.net>; Fri, 25 Aug 2000 09:02:34 -0400 (EDT)
From: seenu@samsung.co.kr
Received: from omail01.samsung.co.kr by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: omail01.samsung.co.kr [203.254.197.73])
	id QQjdts05305
	for <mpls@uu.net>; Fri, 25 Aug 2000 13:02:28 GMT
Received: from localhost (root@localhost)
	by gp_xman. (8.8.8H1/8.8.8) with ESMTP id WAA08786
	for <mpls@uu.net>; Fri, 25 Aug 2000 22:03:19 +0900 (KST)
X-OpenMail-Hops: 3
Date: Fri, 25 Aug 2000 22:04:37 +0900
Message-Id: <H0000e6501d4d671.0967208583.secsw0@MHS>
Subject: differences between ldp-10 and ldp-11 pls
MIME-Version: 1.0
TO: mpls@UU.NET
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline; filename="mail.txt"
	;Creation-Date="Fri, 25 Aug 2000 22:03:07 +0900"
	;Modification-Date="Fri, 25 Aug 2000 22:04:33 +0900"
Content-Transfer-Encoding: 8bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit

Hi,

Where can I find the differences between ldp-10 and ldp-11.

Thanks

Regards
Seenu


From owner-mpls@UU.NET  Fri Aug 25 09:21:56 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19897
	for <mpls-archive@lists.ietf.org>; Fri, 25 Aug 2000 09:21:56 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdtt12751;
	Fri, 25 Aug 2000 13:21:47 GMT
Received: by mail-control.mail.uu.net 
	id QQjdtt28653
	for mpls-outgoing; Fri, 25 Aug 2000 13:21:27 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjdtt28648
	for <mpls@mail-control.mail.uu.net>; Fri, 25 Aug 2000 13:21:16 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjdtt19650
	for <mpls@uu.net>; Fri, 25 Aug 2000 09:21:10 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjdtt11995
	for <mpls@uu.net>; Fri, 25 Aug 2000 13:20:54 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA25913
	for mpls@uu.net; Fri, 25 Aug 2000 09:20:54 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjdtt28518
	for <mpls@mail-control.mail.uu.net>; Fri, 25 Aug 2000 13:20:21 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjdtt19495
	for <mpls@UU.NET>; Fri, 25 Aug 2000 09:20:18 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11])
	id QQjdtt11539
	for <mpls@UU.NET>; Fri, 25 Aug 2000 13:20:17 GMT
Received: from rhthomas-sun2.cisco.com (rhthomas-sun2.cisco.com [161.44.134.47])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id GAA00238;
	Fri, 25 Aug 2000 06:20:34 -0700 (PDT)
Received: from localhost (rhthomas@localhost) by rhthomas-sun2.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id JAA10949; Fri, 25 Aug 2000 09:20:16 -0400 (EDT)
Message-Id: <200008251320.JAA10949@rhthomas-sun2.cisco.com>
X-Authentication-Warning: rhthomas-sun2.cisco.com: rhthomas owned process doing -bs
To: seenu@samsung.co.kr
cc: mpls@UU.NET
Subject: Re: differences between ldp-10 and ldp-11 pls 
In-reply-to: Your message of "Fri, 25 Aug 2000 22:04:37 +0900."
             <H0000e6501d4d671.0967208583.secsw0@MHS> 
Date: Fri, 25 Aug 2000 09:20:14 -0400
From: Bob Thomas <rhthomas@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

> Where can I find the differences between ldp-10 and ldp-11.

The change was posted in an email on 8/23/00 which can retrieved
from the "Current Month" link on MPLS WG archive:

  http://cell.onecall.net/cell-relay/archives/mpls/mpls.index.html

Message header is:

 Date: Wed, 23 Aug 2000 13:41:34 -0400 (EDT)
 From: Bob Thomas <rhthomas@cisco.com>
 To: mpls@UU.NET
 Subject: Clarification of LDP session establishment procedure


Bob



From owner-mpls@UU.NET  Fri Aug 25 09:46:37 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20493
	for <mpls-archive@lists.ietf.org>; Fri, 25 Aug 2000 09:46:37 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdtv06371;
	Fri, 25 Aug 2000 13:46:30 GMT
Received: by mail-control.mail.uu.net 
	id QQjdtv00596
	for mpls-outgoing; Fri, 25 Aug 2000 13:46:08 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjdtv00582
	for <mpls@mail-control.mail.uu.net>; Fri, 25 Aug 2000 13:46:07 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjdtv12948
	for <mpls@uu.net>; Fri, 25 Aug 2000 09:45:58 -0400 (EDT)
Received: from iol.unh.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mars.iol.unh.edu [132.177.121.222])
	id QQjdtv29708
	for <mpls@uu.net>; Fri, 25 Aug 2000 13:45:27 GMT
Received: from localhost (jzou@localhost)
	by iol.unh.edu (8.9.3/8.9.3) with ESMTP id JAA18328
	for <mpls@uu.net>; Fri, 25 Aug 2000 09:45:27 -0400 (EDT)
Date: Fri, 25 Aug 2000 09:45:27 -0400
From: Jie Zou <jzou@mars.iol.unh.edu>
To: mpls@UU.NET
Subject: Difference between RSVP-TE 6 and 7
Message-ID: <Pine.SGI.4.20.0008250943330.18306-100000@mars.iol.unh.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk


Hi,

Could somebody tell me the difference between RSVP-TE 06 and 07(Aug
24,00)?


Thanks
Jie Zou
IOL,UNH





From owner-mpls@UU.NET  Fri Aug 25 10:48:47 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21768
	for <mpls-archive@lists.ietf.org>; Fri, 25 Aug 2000 10:48:47 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdtz15531;
	Fri, 25 Aug 2000 14:48:33 GMT
Received: by mail-control.mail.uu.net 
	id QQjdtz18309
	for mpls-outgoing; Fri, 25 Aug 2000 14:48:08 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjdtz18298
	for <mpls@mail-control.mail.uu.net>; Fri, 25 Aug 2000 14:48:02 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjdtz05068
	for <mpls@uu.net>; Fri, 25 Aug 2000 10:47:57 -0400 (EDT)
Received: from miles.datcon.co.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtp2.datcon.co.uk [192.91.191.8])
	id QQjdtz14935
	for <mpls@uu.net>; Fri, 25 Aug 2000 14:47:56 GMT
Received: by miles.datcon.co.uk with Internet Mail Service (5.5.2650.21)
	id <RL2N9H6D>; Fri, 25 Aug 2000 15:47:55 +0100
Message-ID: <6DEA508A9A0ED31192E80000F6CC176E387C09@monk.datcon.co.uk>
From: Nick Weeds <NPW@datcon.co.uk>
To: "'Edward Brookhouse'" <ebroo@setuidzero.org>
Cc: "MPLS Mailing List (E-mail)" <mpls@UU.NET>
Subject: RE: questions on mpls-ldp-09
Date: Fri, 25 Aug 2000 15:47:44 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Edward,

The draft you mention has been superceded.  The latest draft is
draft-brittain-mpls-ldp-ft-00.txt.  (This latest draft combines the earlier
farrel and matthews drafts).

	Nick.

> Nick Weeds
> Software Developer
> Network Convergence Group
> Data Connection Ltd
> Tel:	+44 1244 313440		Fax:	+44 1244 312422
> Email:	npw@datcon.co.uk		Web:
http://www.datcon.co.uk
> 


> -----Original Message-----
> From: Edward Brookhouse [mailto:ebroo@setuidzero.org]
> Sent: 24 August 2000 21:35
> To: Eric Gray; 'Yuan Gu'; mpls@UU.NET
> Subject: RE: questions on mpls-ldp-09
> 
> 
> 
> Is the draft-farrel-mpls-ldp-ft-00.txt the latest version of 
> the draft ??
> 
> Thanks 
> 
> Edward
> 
> 
> -----Original Message-----
> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf 
> Of Eric Gray
> Sent: Thursday, August 24, 2000 9:49 AM
> To: 'Yuan Gu'; mpls@UU.NET
> Subject: RE: questions on mpls-ldp-09
> 
> 
> Yuan,
> 
> 	Please see embedded comments below.
> 
> > -----Original Message-----
> > From: Yuan Gu [mailto:guy@sh.bel.alcatel.be]
> > Sent: Wednesday, August 23, 2000 8:43 PM
> > To: mpls@UU.NET
> > Subject: questions on mpls-ldp-09
> > 
> > 
> > Dear All:
> > 
> > I have some questions on  mpls-ldp-09.txt:
> > 
> > 1.How many LSPs can be setup in same session?  
> 
> As many as the two LSRs can maintain state for.
> There is no artificially imposed limit.
> 
> > If session fails for some reason, do all LSPs in 
> > this session have to be released?
> 
> Currently, yes.  See the draft on Fault Tolerant 
> LDP - which was accepted as a working group draft
> at the last IETF meeting - for how LSP state may
> be preserved across LDP sessions.
>  
> > 2. In section 3.5.2.1 Hello Message Procedures
> > Configuration Sequence Number:
> > What kind of session parameter can be changed by passive LSR without
> > noticed by active LSR? If receiving LSR detects a change in the
> > configuration in the sending LSR by detecting the change of
> > Configuration Sequence Number, beside clearing the session 
> > setup backoff
> > delay, what else the receiving LSR does? If receiving LSR 
> playing the
> > passive role and detect the change, what does it do?
> 
> The intent of the configuration sequence number is
> to allow the active peer to be able to find out that
> the passive peer has been re-configured.  
> 
> Why do we want to allow this?  
> 
> Because we can assume that a likely reason why two 
> peers are unable to establish a session is that they 
> have been configured with session parameters that are 
> incompatible.  In this event, each repeated attempt
> will fail and - with exponential back-off - each
> new attempt will be delayed by an interval that is
> twice what it was in the immediate prior attempt.
> Obviously, this delay can grow to be quite large.
> The inclusion of a changed configuration sequence 
> number in a Hello message from the passive peer 
> signals the active peer that it might ignore the
> current retry delay and try again immediately.
> 
> Since the passive peer does not control when an
> attempt will be made (it does not initiate LDP
> session establishment), it does not matter if it
> detects a change in the configuration sequence
> number.  If the active peer has been re-configured,
> it can initiate LDP session establishment on its
> own (without sending a configuration sequence
> number to its passive peer or peers).
> 
> > 
> > Thanks alot.
> > Yuan Gu
> > 
> > 
> 


From owner-mpls@UU.NET  Fri Aug 25 19:18:07 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01572
	for <mpls-archive@lists.ietf.org>; Fri, 25 Aug 2000 19:18:06 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjduv25551;
	Fri, 25 Aug 2000 20:17:19 GMT
Received: by mail-control.mail.uu.net 
	id QQjduv03166
	for mpls-outgoing; Fri, 25 Aug 2000 20:16:45 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjduv03153
	for <mpls@mail-control.mail.uu.net>; Fri, 25 Aug 2000 20:16:37 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjduv04025
	for <mpls@UU.NET>; Fri, 25 Aug 2000 16:16:27 -0400 (EDT)
Received: from maplenetworks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: w082.z216112072.sjc-ca.dsl.cnc.net [216.112.72.82])
	id QQjduv11770
	for <mpls@UU.NET>; Fri, 25 Aug 2000 20:16:11 GMT
Received: from prasuncomp (farhad_pc [192.168.10.239])
	by maplenetworks.com (8.9.3+Sun/8.9.3/jcm Maplenetworks hub 1.4) with SMTP id NAA23238
	for <mpls@UU.NET>; Fri, 25 Aug 2000 13:16:01 -0700 (PDT)
Message-ID: <01ed01c00ed1$a8e7ef60$ef0aa8c0@maplenetworks.com>
From: "Sudhanshu Jain" <sjain@maplenetworks.com>
To: <mpls@UU.NET>
Subject: How to Map Lambda/Labels
Date: Fri, 25 Aug 2000 13:18:40 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_01EA_01C00E96.FBF38E20"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_01EA_01C00E96.FBF38E20
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi All,

In pure optical network, I need to setup a cross connect which map a =
specific Lambda/Label ( at the ingress of MPLS domain) to specific =
Lambda/Label ( at the egress of MPLS domain).

To setup such kind of LSP, we can use standard TE MIB. But to configure =
and signal such specific information what is the suggested way in RSVP =
and LDP.

One way could be to overload tunnel name in proprietary manner.=20

Any input will be highly appreciated.

Thanks,
-Sudhanshu

------=_NextPart_000_01EA_01C00E96.FBF38E20
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4134.600" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi All,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>In pure optical network, I&nbsp;need to =
setup a=20
cross connect which map a specific Lambda/Label ( at the ingress of MPLS =
domain)=20
to specific Lambda/Label ( at the egress of MPLS domain).</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>To setup such kind of LSP, we can use =
standard TE=20
MIB. But to configure&nbsp;and signal such specific information what is =
the=20
suggested way in RSVP and LDP.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>One way could be to overload tunnel =
name in=20
proprietary manner. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Any input will be highly =
appreciated.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thanks,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>-Sudhanshu</FONT></DIV></BODY></HTML>

------=_NextPart_000_01EA_01C00E96.FBF38E20--



From owner-mpls@UU.NET  Sat Aug 26 02:12:48 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19297
	for <mpls-archive@lists.ietf.org>; Sat, 26 Aug 2000 02:12:47 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjdwi06418;
	Sat, 26 Aug 2000 06:12:35 GMT
Received: by mail-control.mail.uu.net 
	id QQjdwi18157
	for mpls-outgoing; Sat, 26 Aug 2000 06:12:07 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjdwi18149
	for <mpls@mail-control.mail.uu.net>; Sat, 26 Aug 2000 06:12:03 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjdwi13797
	for <mpls@UU.NET>; Sat, 26 Aug 2000 02:11:56 -0400 (EDT)
Received: from mx2.tellabs.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mx2.tellabs.com [204.68.180.51])
	id QQjdwi05947
	for <mpls@UU.NET>; Sat, 26 Aug 2000 06:11:56 GMT
Received: from mail.hq.tellabs.com (tlab-138-111-51-100.tellabs.com [138.111.51.100] (may be forged))
	by mx2.tellabs.com (8.8.8/8.8.8) with ESMTP id BAA21815;
	Sat, 26 Aug 2000 01:11:01 -0500 (CDT)
Received: from vsharma (cis1host63.bb.tellabs.com [172.16.51.63])
	by mail.hq.tellabs.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id BAA15575;
	Sat, 26 Aug 2000 01:11:52 -0500 (CDT)
Reply-To: <Vishal.Sharma@tellabs.com>
From: "Vishal Sharma" <Vishal.Sharma@tellabs.com>
To: <sjain@maplenetworks.com>, <mpls@UU.NET>
Subject: RE: How to Map Lambda/Labels
Date: Sat, 26 Aug 2000 02:17:02 -0400
Message-ID: <000201c00f25$411a1990$3f3310ac@vsharma.hq.tellabs.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700
Importance: Normal
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Sudhanshu,

Please take a look at the generalized signaling draft
draft-ashwood-generalized-mpls-signaling-00.txt

and, in particular, please look at Section 6 on
egress control.

-Vishal

> -----Original Message-----
> From: sjain@maplenetworks.com [mailto:sjain@maplenetworks.com]
> Sent: Friday, August 25, 2000 4:19 PM
> To: mpls@UU.NET
> Subject: How to Map Lambda/Labels
>
>
> Hi All,

In pure optical network, I need to setup a cross connect which map a
specific Lambda/Label ( at the ingress of MPLS domain) to specific
Lambda/Label ( at the egress of MPLS domain).

To setup such kind of LSP, we can use standard TE MIB. But to configure and
signal such specific information what is the suggested way in RSVP and LDP.

One way could be to overload tunnel name in proprietary manner.

Any input will be highly appreciated.

Thanks,
-Sudhanshu



From owner-mpls@UU.NET  Mon Aug 28 07:20:58 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03417
	for <mpls-archive@lists.ietf.org>; Mon, 28 Aug 2000 07:20:57 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjeen25087;
	Mon, 28 Aug 2000 11:20:46 GMT
Received: by mail-control.mail.uu.net 
	id QQjeen01912
	for mpls-outgoing; Mon, 28 Aug 2000 11:20:15 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjeen01905
	for <mpls@mail-control.mail.uu.net>; Mon, 28 Aug 2000 11:20:08 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjeen24719
	for <mpls@UU.NET>; Mon, 28 Aug 2000 07:20:06 -0400 (EDT)
Received: from smtp1.cluster.oleane.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtp1.cluster.oleane.net [195.25.12.16])
	id QQjeen24541
	for <mpls@UU.NET>; Mon, 28 Aug 2000 11:20:05 GMT
Received: from oleane  (dyn-1-1-234.Vin.dialup.oleane.fr [195.25.4.234])  by smtp1.cluster.oleane.net  with SMTP id NAA60453; Mon, 28 Aug 2000 13:20:04 +0200 (CEST)
Message-ID: <020001c010e1$df343300$0401a8c0@oleane.com>
From: "Peter Lewis" <peter.lewis@upperside.fr>
To: <Undisclosed-Recipient:@smtp1.cluster.oleane.net;>
Subject: MPLS World
Date: Mon, 28 Aug 2000 13:17:11 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_01F4_01C010F2.4659E380"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_01F4_01C010F2.4659E380
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

MPLS World, third edition, Paris 6-9 February.
The most important conference, with more than 700 delegates.
Speakers may still submit papers untill september 15th.
=20
MPLS World is also the largest exhibition in this area.
=20
Please take a look on:

http://www.upperside.fr/congress/conf.htm
=20

------=_NextPart_000_01F4_01C010F2.4659E380
Content-Type: text/html;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Dwindows-1252" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT color=3D#000000 size=3D2>MPLS World, third edition, Paris 6-9 =

February.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT><FONT size=3D2>The most =
important=20
conference, with more than 700 delegates.</FONT></DIV>
<DIV><FONT size=3D2></FONT><FONT color=3D#000000 size=3D2>Speakers may =
still submit=20
papers untill september 15th.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>MPLS World is also the largest exhibition in this=20
area.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Please take a look on:</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2><A=20
href=3D"http://www.upperside.fr/congress/conf.htm">http://www.upperside.f=
r/congress/conf.htm</A></FONT></DIV>
<DIV><FONT color=3D#000000 =
size=3D2></FONT>&nbsp;</DIV></FONT></DIV></BODY></HTML>

------=_NextPart_000_01F4_01C010F2.4659E380--



From owner-mpls@UU.NET  Mon Aug 28 11:11:15 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12279
	for <mpls-archive@lists.ietf.org>; Mon, 28 Aug 2000 11:11:15 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjefc13563;
	Mon, 28 Aug 2000 15:11:00 GMT
Received: by mail-control.mail.uu.net 
	id QQjefc10835
	for mpls-outgoing; Mon, 28 Aug 2000 15:10:15 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjefc10808
	for <mpls@mail-control.mail.uu.net>; Mon, 28 Aug 2000 15:10:01 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjefc03798
	for <mpls@UU.NET>; Mon, 28 Aug 2000 11:09:48 -0400 (EDT)
Received: from mizar.ftl.telematics.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailhost.telematics.com [147.137.1.7])
	id QQjefc12448
	for <mpls@UU.NET>; Mon, 28 Aug 2000 15:09:47 GMT
Received: from go.ecitele.com (pcpdev06 [147.137.23.23])
	by mizar.ftl.telematics.com (8.9.1/8.9.1) with ESMTP id LAA16939
	for <mpls@UU.NET>; Mon, 28 Aug 2000 11:09:44 -0400 (EDT)
Message-ID: <39AA92E5.684800DB@go.ecitele.com>
Date: Mon, 28 Aug 2000 12:27:18 -0400
From: Nick Williamson <Nick.Williamson@go.ecitele.com>
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: MPLS <mpls@UU.NET>
Subject: OSPF TE
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

OSPF TE draft "draft-katz-yeung-ospf-traffic-02.txt" has expired.
Has work ceased on this draft?
Is "draft-fujita-ospf-te-summary-00.txt" expected to replace it?
If so, how is bandwidth tracked on a per CoS level?

Thanks,
--
==================================
Nicholas Williamson (Nick.Williamson@go.ecitele.com)

ECI Telecom (http://www.ecitele.com/)
1201 Cypress Creek Road
Ft Lauderdale, FL 33309
(954) 772-3070 x 4545




From owner-mpls@UU.NET  Mon Aug 28 16:41:55 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20233
	for <mpls-archive@lists.ietf.org>; Mon, 28 Aug 2000 16:41:55 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjefy01138;
	Mon, 28 Aug 2000 20:41:41 GMT
Received: by mail-control.mail.uu.net 
	id QQjefy17104
	for mpls-outgoing; Mon, 28 Aug 2000 20:41:18 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjefy17064
	for <mpls@mail-control.mail.uu.net>; Mon, 28 Aug 2000 20:41:10 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjefy11318
	for <mpls@UU.NET>; Mon, 28 Aug 2000 16:40:49 -0400 (EDT)
Received: from mps3.leeds.ac.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sunserv5.leeds.ac.uk [129.11.16.35])
	id QQjefy08285
	for <mpls@UU.NET>; Mon, 28 Aug 2000 20:40:48 GMT
Received: from electeng.leeds.ac.uk (electeng.leeds.ac.uk [129.11.178.99])
	by mps3.leeds.ac.uk (8.9.3/8.9.3) with ESMTP id VAA17173;
	Mon, 28 Aug 2000 21:40:29 +0100 (BST)
Received: from ELECTENG/SpoolDir by electeng.leeds.ac.uk (Mercury 1.43);
    28 Aug 100 22:12:58 GMT
Received: from SpoolDir by ELECTENG (Mercury 1.43); 28 Aug 100 22:12:34 GMT
Received: from default (129.11.176.219) by electeng.leeds.ac.uk (Mercury 1.40);
    28 Aug 100 22:12:32 GMT
From: "Erickson Trejo-Reyes" <eenet@electeng.leeds.ac.uk>
To: <curtis@avici.com>, <david.charlap@marconi.com>
Cc: <mpls@UU.NET>
Subject: Fw: MPLS and CAC 
Date: Mon, 28 Aug 2000 21:42:43 +0100
Message-ID: <01c01130$842fc740$dbb00b81@default.leeds.ac.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_00AD_01C01138.E5F42F40"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.71.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_00AD_01C01138.E5F42F40
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Thank you both David and Curtis for your kind answers. Refering the =
following statement in the possible configuration:

> While CAC is fully supported it can essentially be ignored by setting =
a very high overbooking factor...=20

> With the high overbooking, these tunnels come up anyway.  If there are =
preferred services, they get preferred treatment so the overbooking =
doesn't matter to them.  Best effort services temporarily get =
squeezed... therefore oversubscribing is much more preferrable to having =
CAC kick in and losing 100% of the traffic until things settle down.

By overbooking you mean that, for example, if a voice source can be =
treated as a VBR source with 64 KB peak bit rate and activity factor of =
0.4, then the reservation should be made to a higher value than the =
computed effective bandwidth (and obviously higher than the average bit =
rate of 0.4 times 64KB)?

I had thought that, if an MPLS node is due to use only certain =
percentage of its total capacity to serve, for example, guaranteed =
services, it would not be too harmful to make reservations (up to the =
available percentage) only based on the sustained rate, with the only =
possible consequence of temporary squeezing the throughput of =
best-effort services. Comments?

Again, thanks in advanced,


Erickson

------=_NextPart_000_00AD_01C01138.E5F42F40
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.71.1712.3"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3D"Bookman Old Style" size=3D2>Thank you both David and =
Curtis for=20
your kind answers. Refering the following statement in the possible=20
configuration:</FONT></DIV>
<DIV><FONT face=3D"Bookman Old Style" size=3D2></FONT>&nbsp;</DIV>
<DIV>&gt; While CAC is fully supported it can essentially be ignored by =
setting=20
a very high overbooking factor...&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&gt; With the high overbooking, these tunnels come up anyway.&nbsp; =
If=20
there are preferred services, they get preferred treatment so the =
overbooking=20
doesn't matter to them.&nbsp; Best effort services temporarily get =
squeezed...=20
therefore oversubscribing is much more preferrable to having CAC kick in =
and=20
losing 100% of the traffic until things settle down.</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=3D#000000 face=3D"Bookman Old Style" size=3D2>By =
overbooking you mean=20
that, for example, if a voice source can be treated as a VBR source with =
64 KB=20
peak bit rate and activity factor of 0.4, then the reservation should be =
made to=20
a higher value than the computed effective bandwidth (and obviously =
higher than=20
the average bit rate of 0.4 times 64KB)?</FONT></DIV>
<DIV><FONT color=3D#000000 face=3D"Bookman Old Style" =
size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Bookman Old Style" size=3D2>I had thought that, if an =
MPLS node=20
is due to use only certain percentage of its total capacity to serve, =
for=20
example, guaranteed services, it would not be too harmful to make =
reservations=20
(up to the available percentage) only based on the sustained rate, with =
the only=20
possible consequence of temporary squeezing the throughput of =
best-effort=20
services. Comments?</FONT></DIV>
<DIV><FONT face=3D"Bookman Old Style" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Bookman Old Style" size=3D2>Again, thanks in=20
advanced,</FONT></DIV>
<DIV><FONT face=3D"Bookman Old Style" size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Bookman Old Style" =
size=3D2>Erickson</FONT></DIV></BODY></HTML>

------=_NextPart_000_00AD_01C01138.E5F42F40--



From owner-mpls@UU.NET  Mon Aug 28 16:54:46 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20418
	for <mpls-archive@lists.ietf.org>; Mon, 28 Aug 2000 16:54:45 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjefz11438;
	Mon, 28 Aug 2000 20:54:31 GMT
Received: by mail-control.mail.uu.net 
	id QQjefz18090
	for mpls-outgoing; Mon, 28 Aug 2000 20:54:13 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjefz18083
	for <mpls@mail-control.mail.uu.net>; Mon, 28 Aug 2000 20:54:11 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjefz13898
	for <mpls@UU.NET>; Mon, 28 Aug 2000 16:54:07 -0400 (EDT)
Received: from nec.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail1.nec.com [143.101.112.2])
	id QQjefz18293
	for <mpls@UU.NET>; Mon, 28 Aug 2000 20:54:04 GMT
Received: from aslws01.asl.dl.nec.com (aslws01-hme0.asl.dl.nec.com [143.101.10.1])
	by nec.com (8.9.3/8.9.3) with ESMTP id PAA13742;
	Mon, 28 Aug 2000 15:51:50 -0500 (CDT)
Received: by aslws01.asl.dl.nec.com (8.7.3/YDL1.9.1-940729.15)
	id PAA12233(aslws01.asl.dl.nec.com); Mon, 28 Aug 2000 15:51:48 -0500 (CDT)
Received: by aslws220.asl.dl.nec.com (8.7.3/YDL1.9.1-940729.15)
	id PAA11273(aslws220.asl.dl.nec.com); Mon, 28 Aug 2000 15:51:48 -0500 (CDT)
Message-ID: <39AAD0DA.8FDDB63E@asl.dl.nec.com>
Date: Mon, 28 Aug 2000 15:51:38 -0500
From: "C. Chen" <cchen@asl.dl.nec.com>
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Erickson Trejo-Reyes <eenet@electeng.leeds.ac.uk>
CC: curtis@avici.com, david.charlap@marconi.com, mpls@UU.NET
Subject: Re: Fw: MPLS and CAC
References: <01c01130$842fc740$dbb00b81@default.leeds.ac.uk>
Content-Type: multipart/alternative;
 boundary="------------A629C2746A47152CD1A21850"
Sender: owner-mpls@UU.NET
Precedence: bulk


--------------A629C2746A47152CD1A21850
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Mr.  Erickson,

It seems to me that overbooking factor determination is not simply PCR *
activity factor (e.g., .4). I was wondering wether there is a IETF draft
defining overbooking factor that you know of ? If not, I would like to
suggest that we work together with people who might be interested in
participating to make a draft contribution on this suject.


Best Regards,



Cheng C. Chen


Erickson Trejo-Reyes wrote:

>  Thank you both David and Curtis for your kind answers. Refering the
> following statement in the possible configuration: > While CAC is
> fully supported it can essentially be ignored by setting a very high
> overbooking factor... > With the high overbooking, these tunnels come
> up anyway.  If there are preferred services, they get preferred
> treatment so the overbooking doesn't matter to them.  Best effort
> services temporarily get squeezed... therefore oversubscribing is much
> more preferrable to having CAC kick in and losing 100% of the traffic
> until things settle down. By overbooking you mean that, for example,
> if a voice source can be treated as a VBR source with 64 KB peak bit
> rate and activity factor of 0.4, then the reservation should be made
> to a higher value than the computed effective bandwidth (and obviously
> higher than the average bit rate of 0.4 times 64KB)? I had thought
> that, if an MPLS node is due to use only certain percentage of its
> total capacity to serve, for example, guaranteed services, it would
> not be too harmful to make reservations (up to the available
> percentage) only based on the sustained rate, with the only possible
> consequence of temporary squeezing the throughput of best-effort
> services. Comments? Again, thanks in advanced,  Erickson

--------------A629C2746A47152CD1A21850
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<body bgcolor="#FFFFFF">
Mr.&nbsp; Erickson,
<p>It seems to me that overbooking factor determination is not simply PCR
* activity factor (e.g., .4). I was wondering wether there is a IETF draft
defining overbooking factor that you know of ? If not, I would like to
suggest that we work together with people who might be interested in participating
to make a draft contribution on this suject.
<br>&nbsp;
<p>Best Regards,
<br>&nbsp;
<br>&nbsp;
<p>Cheng C. Chen
<br>&nbsp;
<p>Erickson Trejo-Reyes wrote:
<blockquote TYPE=CITE>&nbsp;<font face="Bookman Old Style"><font size=-1>Thank
you both David and Curtis for your kind answers. Refering the following
statement in the possible configuration:</font></font>&nbsp;> While CAC
is fully supported it can essentially be ignored by setting a very high
overbooking factor...&nbsp;> With the high overbooking, these tunnels come
up anyway.&nbsp; If there are preferred services, they get preferred treatment
so the overbooking doesn't matter to them.&nbsp; Best effort services temporarily
get squeezed... therefore oversubscribing is much more preferrable to having
CAC kick in and losing 100% of the traffic until things settle down.&nbsp;<font face="Bookman Old Style"><font color="#000000"><font size=-1>By
overbooking you mean that, for example, if a voice source can be treated
as a VBR source with 64 KB peak bit rate and activity factor of 0.4, then
the reservation should be made to a higher value than the computed effective
bandwidth (and obviously higher than the average bit rate of 0.4 times
64KB)?</font></font></font>&nbsp;<font face="Bookman Old Style"><font size=-1>I
had thought that, if an MPLS node is due to use only certain percentage
of its total capacity to serve, for example, guaranteed services, it would
not be too harmful to make reservations (up to the available percentage)
only based on the sustained rate, with the only possible consequence of
temporary squeezing the throughput of best-effort services. Comments?</font></font>&nbsp;<font face="Bookman Old Style"><font size=-1>Again,
thanks in advanced,</font></font>&nbsp;&nbsp;<font face="Bookman Old Style"><font size=-1>Erickson</font></font></blockquote>

</body>
</html>

--------------A629C2746A47152CD1A21850--



From owner-mpls@UU.NET  Mon Aug 28 17:05:53 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20583
	for <mpls-archive@lists.ietf.org>; Mon, 28 Aug 2000 17:05:53 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjega26419;
	Mon, 28 Aug 2000 21:05:26 GMT
Received: by mail-control.mail.uu.net 
	id QQjega00458
	for mpls-outgoing; Mon, 28 Aug 2000 21:04:58 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjega00445
	for <mpls@mail-control.mail.uu.net>; Mon, 28 Aug 2000 21:04:55 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjega04704
	for <mpls@UU.NET>; Mon, 28 Aug 2000 17:04:43 -0400 (EDT)
Received: from mps3.leeds.ac.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sunserv5.leeds.ac.uk [129.11.16.35])
	id QQjega25532
	for <mpls@UU.NET>; Mon, 28 Aug 2000 21:04:13 GMT
Received: from electeng.leeds.ac.uk (electeng.leeds.ac.uk [129.11.178.99])
	by mps3.leeds.ac.uk (8.9.3/8.9.3) with ESMTP id WAA17980;
	Mon, 28 Aug 2000 22:03:47 +0100 (BST)
Received: from ELECTENG/SpoolDir by electeng.leeds.ac.uk (Mercury 1.43);
    28 Aug 100 22:36:16 GMT
Received: from SpoolDir by ELECTENG (Mercury 1.43); 28 Aug 100 22:35:48 GMT
Received: from default (129.11.176.219) by electeng.leeds.ac.uk (Mercury 1.40);
    28 Aug 100 22:35:38 GMT
From: "Erickson Trejo-Reyes" <eenet@electeng.leeds.ac.uk>
To: "C. Chen" <cchen@asl.dl.nec.com>
Cc: <curtis@avici.com>, <david.charlap@marconi.com>, <mpls@UU.NET>
Subject: Re: Fw: MPLS and CAC
Date: Mon, 28 Aug 2000 22:05:50 +0100
Message-ID: <01c01133$be995ce0$dbb00b81@default.leeds.ac.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_00CC_01C0113C.205DC4E0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.71.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_00CC_01C0113C.205DC4E0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Mr Chen,

No, I certainly don't know if there is any document that speaks of the =
subject. I would certainly try to find something in the literature, and =
yes, I agree with you that having others' impressions of this would be =
rather constructive. Thanks for your answer and we'll keep in touch.


Best regards,


Erickson Trejo

-----Original Message-----
From: C. Chen <cchen@asl.dl.nec.com>
To: Erickson Trejo-Reyes <eenet@electeng.leeds.ac.uk>
Cc: curtis@avici.com <curtis@avici.com>; david.charlap@marconi.com =
<david.charlap@marconi.com>; mpls@UU.NET <mpls@UU.NET>
Date: Monday, August 28, 2000 9:51 PM
Subject: Re: Fw: MPLS and CAC


Mr.  Erickson,=20
It seems to me that overbooking factor determination is not simply PCR * =
activity factor (e.g., .4). I was wondering wether there is a IETF draft =
defining overbooking factor that you know of ? If not, I would like to =
suggest that we work together with people who might be interested in =
participating to make a draft contribution on this suject.=20
 =20

Best Regards,=20
 =20
 =20

Cheng C. Chen=20
 =20

Erickson Trejo-Reyes wrote:=20

 Thank you both David and Curtis for your kind answers. Refering the =
following statement in the possible configuration: > While CAC is fully =
supported it can essentially be ignored by setting a very high =
overbooking factor... > With the high overbooking, these tunnels come up =
anyway.  If there are preferred services, they get preferred treatment =
so the overbooking doesn't matter to them.  Best effort services =
temporarily get squeezed... therefore oversubscribing is much more =
preferrable to having CAC kick in and losing 100% of the traffic until =
things settle down. By overbooking you mean that, for example, if a =
voice source can be treated as a VBR source with 64 KB peak bit rate and =
activity factor of 0.4, then the reservation should be made to a higher =
value than the computed effective bandwidth (and obviously higher than =
the average bit rate of 0.4 times 64KB)? I had thought that, if an MPLS =
node is due to use only certain percentage of its total capacity to =
serve, for example, guaranteed services, it would not be too harmful to =
make reservations (up to the available percentage) only based on the =
sustained rate, with the only possible consequence of temporary =
squeezing the throughput of best-effort services. Comments? Again, =
thanks in advanced,  Erickson

------=_NextPart_000_00CC_01C0113C.205DC4E0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type><!doctype html public "-//w3c//dtd html 4.0 =
transitional//en">
<META content=3D'"MSHTML 4.71.1712.3"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000 face=3D"Bookman Old Style" size=3D2>Mr =
Chen,</FONT></DIV>
<DIV><FONT color=3D#000000 face=3D"Bookman Old Style" =
size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 face=3D"Bookman Old Style" size=3D2>No, I =
certainly don't=20
know if there is any document that speaks of the subject. I would =
certainly try=20
to find something in the literature, and yes, I agree with you that =
having=20
others' impressions of this would be rather constructive. Thanks for =
your answer=20
and we'll keep in touch.</FONT></DIV>
<DIV><FONT color=3D#000000 face=3D"Bookman Old Style" =
size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Bookman Old Style" size=3D2>Best =
regards,</FONT></DIV>
<DIV><FONT face=3D"Bookman Old Style" size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Bookman Old Style" size=3D2>Erickson =
Trejo</FONT></DIV>
<DIV><FONT face=3D"Bookman Old Style" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><B>-----Original =
Message-----</B><BR><B>From:=20
</B>C. Chen &lt;<A=20
href=3D"mailto:cchen@asl.dl.nec.com">cchen@asl.dl.nec.com</A>&gt;<BR><B>T=
o:=20
</B>Erickson Trejo-Reyes &lt;<A=20
href=3D"mailto:eenet@electeng.leeds.ac.uk">eenet@electeng.leeds.ac.uk</A>=
&gt;<BR><B>Cc:=20
</B><A href=3D"mailto:curtis@avici.com">curtis@avici.com</A> &lt;<A=20
href=3D"mailto:curtis@avici.com">curtis@avici.com</A>&gt;; <A=20
href=3D"mailto:david.charlap@marconi.com">david.charlap@marconi.com</A> =
&lt;<A=20
href=3D"mailto:david.charlap@marconi.com">david.charlap@marconi.com</A>&g=
t;; <A=20
href=3D"mailto:mpls@UU.NET">mpls@UU.NET</A> &lt;<A=20
href=3D"mailto:mpls@UU.NET">mpls@UU.NET</A>&gt;<BR><B>Date: </B>Monday, =
August 28,=20
2000 9:51 PM<BR><B>Subject: </B>Re: Fw: MPLS and=20
CAC<BR><BR></DIV></FONT>Mr.&nbsp; Erickson,=20
<P>It seems to me that overbooking factor determination is not simply =
PCR *=20
activity factor (e.g., .4). I was wondering wether there is a IETF draft =

defining overbooking factor that you know of ? If not, I would like to =
suggest=20
that we work together with people who might be interested in =
participating to=20
make a draft contribution on this suject. <BR>&nbsp;=20
<P>Best Regards, <BR>&nbsp; <BR>&nbsp;=20
<P>Cheng C. Chen <BR>&nbsp;=20
<P>Erickson Trejo-Reyes wrote:=20
<BLOCKQUOTE TYPE =3D CITE>&nbsp;<FONT face=3D"Bookman Old Style"><FONT=20
    size=3D-1>Thank you both David and Curtis for your kind answers. =
Refering the=20
    following statement in the possible =
configuration:</FONT></FONT>&nbsp;&gt;=20
    While CAC is fully supported it can essentially be ignored by =
setting a very=20
    high overbooking factor...&nbsp;&gt; With the high overbooking, =
these=20
    tunnels come up anyway.&nbsp; If there are preferred services, they =
get=20
    preferred treatment so the overbooking doesn't matter to them.&nbsp; =
Best=20
    effort services temporarily get squeezed... therefore =
oversubscribing is=20
    much more preferrable to having CAC kick in and losing 100% of the =
traffic=20
    until things settle down.&nbsp;<FONT face=3D"Bookman Old =
Style"><FONT=20
    color=3D#000000><FONT size=3D-1>By overbooking you mean that, for =
example, if a=20
    voice source can be treated as a VBR source with 64 KB peak bit rate =
and=20
    activity factor of 0.4, then the reservation should be made to a =
higher=20
    value than the computed effective bandwidth (and obviously higher =
than the=20
    average bit rate of 0.4 times 64KB)?</FONT></FONT></FONT>&nbsp;<FONT =

    face=3D"Bookman Old Style"><FONT size=3D-1>I had thought that, if an =
MPLS node=20
    is due to use only certain percentage of its total capacity to =
serve, for=20
    example, guaranteed services, it would not be too harmful to make=20
    reservations (up to the available percentage) only based on the =
sustained=20
    rate, with the only possible consequence of temporary squeezing the=20
    throughput of best-effort services. =
Comments?</FONT></FONT>&nbsp;<FONT=20
    face=3D"Bookman Old Style"><FONT size=3D-1>Again, thanks in=20
    advanced,</FONT></FONT>&nbsp;&nbsp;<FONT face=3D"Bookman Old =
Style"><FONT=20
    size=3D-1>Erickson</FONT></FONT></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_00CC_01C0113C.205DC4E0--



From owner-mpls@UU.NET  Mon Aug 28 19:44:42 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22272
	for <mpls-archive@lists.ietf.org>; Mon, 28 Aug 2000 19:44:42 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjegk14558;
	Mon, 28 Aug 2000 23:44:28 GMT
Received: by mail-control.mail.uu.net 
	id QQjegk08715
	for mpls-outgoing; Mon, 28 Aug 2000 23:43:56 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjegk08704
	for <mpls@mail-control.mail.uu.net>; Mon, 28 Aug 2000 23:43:47 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjegk29742
	for <mpls@UU.NET>; Mon, 28 Aug 2000 19:43:44 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQjegk13863
	for <mpls@UU.NET>; Mon, 28 Aug 2000 23:43:24 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA11676
	for <mpls@UU.NET>; Mon, 28 Aug 2000 19:43:22 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA07799
	for <mpls@UU.NET>; Mon, 28 Aug 2000 19:43:22 -0400 (EDT)
Message-ID: <39AAF934.C9C21EEA@marconi.com>
Date: Mon, 28 Aug 2000 19:43:48 -0400
From: David Charlap <david.charlap@marconi.com>
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: Fw: MPLS and CAC
References: <01c01130$842fc740$dbb00b81@default.leeds.ac.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Erickson Trejo-Reyes wrote:
> 
> By overbooking you mean that, for example, if a voice source can be
> treated as a VBR source with 64 KB peak bit rate and activity factor
> of 0.4, then the reservation should be made to a higher value than the
> computed effective bandwidth (and obviously higher than the average
> bit rate of 0.4 times 64KB)?

The idea behind overbooking is simple.  You accept requests for
resources that you don't have.

Under certain circumstances, this is OK.  For instance:

- You know that the overbooked reservations are temporary and will go
  away (eg. the overload is due to a failure somewhre and will be moved
  to another switch when the rest of the network realizes this and
  reroutes the tunnels.)

- You know that most of these tunnels aren't going to be running at peak
  capacity.  This is dangerous for an ISP to assume - especially when
  legal contracts demand a certain service level and you don't know the
  nature of the data, but it can be acceptible in a situation where you
  do know what kind of data will be flowing through the tunnels.

- You know that the tunnesl aren't used much during certain times of the
  day.  For instance, many corporate links (especially those that are
  not behind a publicly-accessible server) almost go idle at night, when
  most employees have gone home.  Again, you have to know your customers
  here.

> I had thought that, if an MPLS node is due to use only certain
> percentage of its total capacity to serve, for example, guaranteed
> services, it would not be too harmful to make reservations (up to the
> available percentage) only based on the sustained rate, with the only
> possible consequence of temporary squeezing the throughput of
> best-effort services. Comments?

Squeezing best-effor services due to a lot of reservations is not
overbooking.  That's just the nature of best-effort traffic.

Overbooking is where (for instance) a 10G switch grants an aggregate of
20G among all of its tunnels.  If the tunnels don't actually use more
than 10G total, you're OK - if not, then you cause their guarantees to
be violated.

Whether or not this is acceptible will depend on why you're overbooking
(is it something transitory that will quickly go away, or is it a
deliberate management decision), and what kind of service your customers
are actually paying for.

-- David


From owner-mpls@UU.NET  Mon Aug 28 21:05:21 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23024
	for <mpls-archive@lists.ietf.org>; Mon, 28 Aug 2000 21:05:21 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjegq04697;
	Tue, 29 Aug 2000 01:05:07 GMT
Received: by mail-control.mail.uu.net 
	id QQjegq09052
	for mpls-outgoing; Tue, 29 Aug 2000 01:04:36 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjegq09021
	for <mpls@mail-control.mail.uu.net>; Tue, 29 Aug 2000 01:04:27 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjegq21343
	for <Mpls@Uu.Net>; Mon, 28 Aug 2000 21:04:14 -0400 (EDT)
From: Sam.Ng@sita.int
Received: from wjao001.sita.int by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wjao001.sita.int [57.250.224.18])
	id QQjegq04150
	for <Mpls@Uu.Net>; Tue, 29 Aug 2000 01:04:14 GMT
Received: by wjao001.sita.int (Smap/SITAnet-firewall-2.1) id BAA26336
	for <Mpls@Uu.Net>; Tue, 29 Aug 2000 01:05:11 GMT
Received: from mx1.sita.int(57.6.21.105) by wjao001 via smap (3.2)
	id xma026329; Tue, 29 Aug 00 01:05:02 GMT
Received: from sydney1.syd.sita.int (sydney1.syd.sita.int [57.4.198.10])
	by mx.sita.int with SMTP id e7T142I27426
	for <Mpls@Uu.Net>; Tue, 29 Aug 2000 01:04:02 GMT
Received: by sydney1.syd.sita.int(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 4A25694A.000B57CF ; Tue, 29 Aug 2000 12:03:53 +1000
X-Lotus-FromDomain: SITA
To: Mpls@UU.NET
Message-ID: <4A25694A.000B569B.00@sydney1.syd.sita.int>
Date: Tue, 29 Aug 2000 12:03:50 +1000
Subject: Similarity
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-mpls@UU.NET
Precedence: bulk




  i am reading about mpls features, the more i read the more i realise it looks
like very familiar
  the traditional telephone network in term of route traffic away from congested
path. In traditional
  telephone network, we have dynamic alternate routing strategy to route traffic
during Christmas
  or New Year & we route traffic to different time zone to alleivate the
congested path.  If it is what
  i think then can those parameters (e.g. holding time, blocking , optimisation)
would be applied to
  mpls traffic engineering.. can we look at those principles applied to
traditional telephone network
  to mpls in term of traffic engineering..

  Cheers
  Sam

  Sita Equant Operation
  Fault Management Unit
  Phone  : 61-02-92401408
  CVN     : 72391408




From owner-mpls@UU.NET  Tue Aug 29 09:59:30 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18113
	for <mpls-archive@lists.ietf.org>; Tue, 29 Aug 2000 09:59:29 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjeip07137;
	Tue, 29 Aug 2000 13:59:13 GMT
Received: by mail-control.mail.uu.net 
	id QQjeip10317
	for mpls-outgoing; Tue, 29 Aug 2000 13:58:42 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjeip10312
	for <mpls@mail-control.mail.uu.net>; Tue, 29 Aug 2000 13:58:27 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjeip14805
	for <Mpls@UU.NET>; Tue, 29 Aug 2000 09:58:17 -0400 (EDT)
Received: from hoemail2.firewall.lucent.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: hoemail2.lucent.com [192.11.226.163])
	id QQjeip12466
	for <Mpls@UU.NET>; Tue, 29 Aug 2000 13:58:17 GMT
Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1])
	by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id JAA18656
	for <Mpls@UU.NET>; Tue, 29 Aug 2000 09:58:16 -0400 (EDT)
Received: from hotair.hobl.lucent.com (h199-118-135-2.lucent.com [199.118.135.2])
	by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id JAA18648;
	Tue, 29 Aug 2000 09:58:16 -0400 (EDT)
Received: from hotair.hobl.lucent.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2)
	id JAA27544; Tue, 29 Aug 2000 09:58:16 -0400
Message-ID: <39ABC1D7.4884650B@hotair.hobl.lucent.com>
Date: Tue, 29 Aug 2000 09:59:52 -0400
From: Ramesh Bhandari <bhandari1@lucent.com>
X-Mailer: Mozilla 4.73 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Sam.Ng@sita.int
CC: Mpls@UU.NET
Subject: Re: Similarity
References: <4A25694A.000B569B.00@sydney1.syd.sita.int>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Sam

MPLS is just a mechanism for creating alternate paths. All the old traffic
engineering principles are applicable to the analysis of the MPLS networks.

Ramesh

Lucent Technologies
Optical Networking Group
1-732-949-8754

Sam.Ng@sita.int wrote:

>   i am reading about mpls features, the more i read the more i realise it looks
> like very familiar
>   the traditional telephone network in term of route traffic away from congested
> path. In traditional
>   telephone network, we have dynamic alternate routing strategy to route traffic
> during Christmas
>   or New Year & we route traffic to different time zone to alleivate the
> congested path.  If it is what
>   i think then can those parameters (e.g. holding time, blocking , optimisation)
> would be applied to
>   mpls traffic engineering.. can we look at those principles applied to
> traditional telephone network
>   to mpls in term of traffic engineering..
>
>   Cheers
>   Sam
>
>   Sita Equant Operation
>   Fault Management Unit
>   Phone  : 61-02-92401408
>   CVN     : 72391408



From owner-mpls@UU.NET  Tue Aug 29 10:54:32 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20380
	for <mpls-archive@lists.ietf.org>; Tue, 29 Aug 2000 10:54:32 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjeit19096;
	Tue, 29 Aug 2000 14:54:07 GMT
Received: by mail-control.mail.uu.net 
	id QQjeit26600
	for mpls-outgoing; Tue, 29 Aug 2000 14:53:37 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjeit26593
	for <mpls@mail-control.mail.uu.net>; Tue, 29 Aug 2000 14:53:29 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjeit24938
	for <mpls@uu.net>; Tue, 29 Aug 2000 10:53:10 -0400 (EDT)
Received: from iol.unh.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mars.iol.unh.edu [132.177.121.222])
	id QQjeit22360
	for <mpls@uu.net>; Tue, 29 Aug 2000 14:53:07 GMT
Received: from localhost (mmeara@localhost)
	by iol.unh.edu (8.9.3/8.9.3) with ESMTP id KAA12859
	for <mpls@uu.net>; Tue, 29 Aug 2000 10:53:03 -0400 (EDT)
Date: Tue, 29 Aug 2000 10:53:03 -0400
From: "Michael H. O'Meara" <mmeara@mars.iol.unh.edu>
To: mpls@UU.NET
Subject: RSVP Explicit_Route object question 
Message-ID: <Pine.SGI.4.20.0008291052020.12843-100000@mars.iol.unh.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk


LER_A ----- LSR_A ----- LSR_B ---- LER_B
-------------LSP/1 ----------------->

In the above topology, LER_A specifies a strict explicit route along
LSP/1. Can LER_A specify LSR_A's egress interface as it's first hop or,
does the RSVP-TE protocol require that the hop can only be either the
ingress interface or the routerId of LSR_A.

Thanks in advance,
 Mike

***************************
Michael O'Meara
Technician
MPLS Consortium	
InterOperability Lab
University of New Hampshire
***************************





From owner-mpls@UU.NET  Tue Aug 29 11:20:46 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21660
	for <mpls-archive@lists.ietf.org>; Tue, 29 Aug 2000 11:20:46 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjeiv13704;
	Tue, 29 Aug 2000 15:20:13 GMT
Received: by mail-control.mail.uu.net 
	id QQjeiv10427
	for mpls-outgoing; Tue, 29 Aug 2000 15:19:54 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjeiv10418
	for <mpls@mail-control.mail.uu.net>; Tue, 29 Aug 2000 15:19:53 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjeiv11570
	for <mpls@UU.NET>; Tue, 29 Aug 2000 11:19:27 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQjeiv12542
	for <mpls@UU.NET>; Tue, 29 Aug 2000 15:18:52 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA24327
	for <mpls@UU.NET>; Tue, 29 Aug 2000 11:18:47 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA24889
	for <mpls@UU.NET>; Tue, 29 Aug 2000 11:18:47 -0400 (EDT)
Message-ID: <39ABD473.7AC1691E@marconi.com>
Date: Tue, 29 Aug 2000 11:19:15 -0400
From: David Charlap <david.charlap@marconi.com>
Reply-To: mpls@UU.NET
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: RSVP Explicit_Route object question
References: <Pine.SGI.4.20.0008291052020.12843-100000@mars.iol.unh.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

"Michael H. O'Meara" wrote:
> 
> LER_A ----- LSR_A ----- LSR_B ---- LER_B
> -------------LSP/1 ----------------->
> 
> In the above topology, LER_A specifies a strict explicit route along
> LSP/1. Can LER_A specify LSR_A's egress interface as it's first hop
> or, does the RSVP-TE protocol require that the hop can only be either
> the ingress interface or the routerId of LSR_A.

If you use a loose-hop in the explicit-route object, then there's
definitely no problem.  LER_A would look at the ERO and ask its routing
table "what's the next hop to get to the egress interface of LSR_A". 
The routing table will probably respond with "the ingress interface of
LSR_A".

As for whether this will work with a strict route or not, I'm not sure. 
My understanding of the draft is that it will.

If I'm wrong about this, hopefully someone will correct me here.

I've always understood the processing of an ERO with strict routes to be
something along the lines of:

	1: Strip all instances of your own addresses from the front of
           the list.

	2: The address that's now at the top of the list is your next-
           hop.  Use whatever means are necessary to find out if the
           switch owning this address (whether it's ingress, egress, or
           otherwise) is directly attached.  If so, send a Path to that
           switch, otherwise return PathErr.

So, for a topology like this:
                    ______
         /\        /\13      /\        /\
    ____/  \______/  \______/  \______/  \____
       5\1 /6    7\2 /8    9\3 /10  11\4 /12
         \/        \/        \/        \/

Where 1, 2, 3, and 4 are router IDs, 5-12 are interfaces along the path,
and 13 is an interface that's not on the path, all of these are
theoretically valid strict EROs:

	1, 2, 3, 4
	5, 7, 9, 11, 12
	5, 6, 7, 8, 9, 10, 11, 12
	5, 1, 6, 7, 2, 8, 9, 3, 10, 11, 4, 12
	6, 8, 9, 11, 4, 12

In all cases a switch will start by stripping off all of its own
addresses, and act based on whatever address is next.  When the next
switch receives the Path, it will do the same.

As a matter of fact, because of this, I think even this goofy ERO should
work, even though it is not actually describing the path the data will
follow:

	5, 13, 9, 11, 12

In this case, the first router strips off its own address (5) and does a
lookup for 13 - which is a neighbor address, since it's part of switch
2, which is directly attached.  When switch 2 gets the packet, it sees
13 as one of its own addresses and strips it, and does a lookup for the
next-hop address (9), and sends the Path there.  etc.

It all works because a transit router doesn't know (or doesn't have to
know) the topology of the network beyond its neighbors, and the first
thing a router does on receipt of an ERO is to strip its own addresses
off the front of it.

-- David


From owner-mpls@UU.NET  Tue Aug 29 11:26:14 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21905
	for <mpls-archive@lists.ietf.org>; Tue, 29 Aug 2000 11:26:14 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjeiv18197;
	Tue, 29 Aug 2000 15:25:50 GMT
Received: by mail-control.mail.uu.net 
	id QQjeiv10784
	for mpls-outgoing; Tue, 29 Aug 2000 15:25:14 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjeiv10779
	for <mpls@mail-control.mail.uu.net>; Tue, 29 Aug 2000 15:25:11 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjeiv12865
	for <mpls@UU.NET>; Tue, 29 Aug 2000 11:24:47 -0400 (EDT)
Received: from manchaca.ece.utexas.edu by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: manchaca.ece.utexas.edu [128.83.59.38])
	id QQjeiv13038
	for <mpls@UU.NET>; Tue, 29 Aug 2000 15:24:31 GMT
Received: from tick.ece.utexas.edu (tick.ece.utexas.edu [128.83.59.31])
	by manchaca.ece.utexas.edu (8.9.3/8.9.3) with SMTP id KAA04361;
	Tue, 29 Aug 2000 10:24:30 -0500 (CDT)
Date: Tue, 29 Aug 2000 10:24:29 -0500 (CDT)
From: Aimin Sang <sang@ece.utexas.edu>
To: David Charlap <david.charlap@marconi.com>
cc: mpls@UU.NET
Subject: Re: Fw: MPLS and CAC
In-Reply-To: <39AAF934.C9C21EEA@marconi.com>
Message-ID: <Pine.SOL.3.93.1000829094103.5030c-100000@tick.ece.utexas.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

Dear David,

Thanks for your good insights regarding the overbooking factor. I have
several questions:


> Erickson Trejo-Reyes wrote:
> > 
> > By overbooking you mean that, for example, if a voice source can be
> > treated as a VBR source with 64 KB peak bit rate and activity factor
> > of 0.4, then the reservation should be made to a higher value than the
> > computed effective bandwidth (and obviously higher than the average
> > bit rate of 0.4 times 64KB)?
> 
> The idea behind overbooking is simple.  You accept requests for
> resources that you don't have.
> 
> Under certain circumstances, this is OK.  For instance:
> 
> - You know that the overbooked reservations are temporary and will go
>   away (eg. the overload is due to a failure somewhre and will be moved
>   to another switch when the rest of the network realizes this and
>   reroutes the tunnels.)
>

Could you please give us a more detailed example (when "this is OK") to
set overbooking factor? Say: The overbooked reservation is temporary
because of the re-routing, but who set the overbooking factor and how? 
It is set by the network operator from time to time, or the CAC algorithm
automatically?

Further, I guess you mean that the CAC's decision of overbooking can be
balanced by traffic engineering. If that is right, are these two control 
at the same time-scale?

Given the GCAC in PNNI 1.0, should the overbooking factor be a coeffient
of AvCR (e.g. 120% * AvCR), or of the actual allocated bandwidth (or
effective bandwidth) to each flow? By functionality, they should bring the
same effect.

Considering the highly non-stationarity of real network traffic, the
overbooking factor can hardly works well (with high utilization and low
loss) all the time. So does the overbooking factor reflect the real
"over- reservation of the bandwidth resources", or it is just a tuning
knob of the specific CAC algorithm?

 
> - You know that most of these tunnels aren't going to be running at peak
>   capacity.  This is dangerous for an ISP to assume - especially when
>   legal contracts demand a certain service level and you don't know the
>   nature of the data, but it can be acceptible in a situation where you
>   do know what kind of data will be flowing through the tunnels.
> 
This is a very good point.

> - You know that the tunnesl aren't used much during certain times of the
>   day.  For instance, many corporate links (especially those that are
>   not behind a publicly-accessible server) almost go idle at night, when
>   most employees have gone home.  Again, you have to know your customers
>   here.
> 
> > I had thought that, if an MPLS node is due to use only certain
> > percentage of its total capacity to serve, for example, guaranteed
> > services, it would not be too harmful to make reservations (up to the
> > available percentage) only based on the sustained rate, with the only
> > possible consequence of temporary squeezing the throughput of
> > best-effort services. Comments?
> 
> Squeezing best-effor services due to a lot of reservations is not
> overbooking.  That's just the nature of best-effort traffic.
> 
> Overbooking is where (for instance) a 10G switch grants an aggregate of
> 20G among all of its tunnels.  If the tunnels don't actually use more
> than 10G total, you're OK - if not, then you cause their guarantees to
> be violated.
> 
> Whether or not this is acceptible will depend on why you're overbooking
> (is it something transitory that will quickly go away, or is it a
> deliberate management decision), and what kind of service your customers
> are actually paying for.
> 

The last paragraph gave me very good insights, but I still do know how to
overbook in case of something transitory. Maybe you mean the traffic burst
which comes and goes very quickly, and the overbooking factor is just
fixed during that period.

If a local CAC gives the network operator an interface to tune the
overbooking factor, I think the corresponding tuning guideline should
follows tightly. Could you please comment on this, or give some example
about the tuning guideline?


Many thanks,

Sincerely,

Aimin
****************************************************************
                Aimin Sang, Ph.D Candidate
                Telecommunication Networks
                ENS 106, ECE Department
                Univ. of Texas at Austin

                Mailing/Home Address:
                1515 Rio Grand Dr., Apt. 723, Plano, TX 75075

                Fax:   (214)-291-2280
                Phone: (972)-943-3285 (Home)
                       (214)-291-2375 (Office)

                URL:   http://www.ece.utexas.edu/~sang

"You can never be too rich, too thin, or have too much bandwidth"
*****************************************************************




From owner-mpls@UU.NET  Tue Aug 29 11:32:58 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22294
	for <mpls-archive@lists.ietf.org>; Tue, 29 Aug 2000 11:32:58 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjeiw19565;
	Tue, 29 Aug 2000 15:32:29 GMT
Received: by mail-control.mail.uu.net 
	id QQjeiw11457
	for mpls-outgoing; Tue, 29 Aug 2000 15:31:57 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjeiw11446
	for <mpls@mail-control.mail.uu.net>; Tue, 29 Aug 2000 15:31:44 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjeiw02492
	for <mpls@UU.NET>; Tue, 29 Aug 2000 11:31:28 -0400 (EDT)
Received: from cain.telindusk.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail.telindusk.net [212.134.79.3])
	id QQjeiw18678
	for <mpls@UU.NET>; Tue, 29 Aug 2000 15:31:27 GMT
Received: by CAIN with Internet Mail Service (5.5.2650.21)
	id <RLGKBR1G>; Tue, 29 Aug 2000 16:31:25 +0100
Message-ID: <356D1F13C9C9D311A16800508B715DBD37874E@CAIN>
From: Guy Davies <Guy.Davies@telindusk.net>
To: "'mpls@UU.NET'" <mpls@UU.NET>
Subject: RE: RSVP Explicit_Route object question
Date: Tue, 29 Aug 2000 16:31:24 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Dave and Mike,

There are certainly implementations out there which will not permit you to
use anything other than an interface on a directly connected network when
describing strictly routed LSPs.  When you think about it, this makes sense
because the point of a strictly routed LSP is that you describe each hop
(without the possibility of any other hops being introduced).  If you
specify the loopback (or, indeed, any other non-ingress interface of the
next LSR) then each LSR would have to resort to using it's routing table to
select the path to the next hop and that introduces the possibility of other
LSRs being traversed between the two supposedly adjacent LSRs.

So, to make my ramblings short...  to me, it makes no sense to use any
address other than that of the ingress interface of each LSR on the path
when using strict explicit routing of LSPs.

Regards,

Guy

> -----Original Message-----
> From: David Charlap [mailto:david.charlap@marconi.com]
> Sent: Tuesday, August 29, 2000 4:19 PM
> To: mpls@UU.NET
> Subject: Re: RSVP Explicit_Route object question
> 
> 
> "Michael H. O'Meara" wrote:
> > 
> > LER_A ----- LSR_A ----- LSR_B ---- LER_B
> > -------------LSP/1 ----------------->
> > 
> > In the above topology, LER_A specifies a strict explicit route along
> > LSP/1. Can LER_A specify LSR_A's egress interface as it's first hop
> > or, does the RSVP-TE protocol require that the hop can only 
> be either
> > the ingress interface or the routerId of LSR_A.
> 
> If you use a loose-hop in the explicit-route object, then there's
> definitely no problem.  LER_A would look at the ERO and ask 
> its routing
> table "what's the next hop to get to the egress interface of LSR_A". 
> The routing table will probably respond with "the ingress interface of
> LSR_A".
> 
> As for whether this will work with a strict route or not, I'm 
> not sure. 
> My understanding of the draft is that it will.
> 
> If I'm wrong about this, hopefully someone will correct me here.
> 
> I've always understood the processing of an ERO with strict 
> routes to be
> something along the lines of:
> 
> 	1: Strip all instances of your own addresses from the front of
>            the list.
> 
> 	2: The address that's now at the top of the list is your next-
>            hop.  Use whatever means are necessary to find out if the
>            switch owning this address (whether it's ingress, 
> egress, or
>            otherwise) is directly attached.  If so, send a 
> Path to that
>            switch, otherwise return PathErr.
> 
> So, for a topology like this:
>                     ______
>          /\        /\13      /\        /\
>     ____/  \______/  \______/  \______/  \____
>        5\1 /6    7\2 /8    9\3 /10  11\4 /12
>          \/        \/        \/        \/
> 
> Where 1, 2, 3, and 4 are router IDs, 5-12 are interfaces 
> along the path,
> and 13 is an interface that's not on the path, all of these are
> theoretically valid strict EROs:
> 
> 	1, 2, 3, 4
> 	5, 7, 9, 11, 12
> 	5, 6, 7, 8, 9, 10, 11, 12
> 	5, 1, 6, 7, 2, 8, 9, 3, 10, 11, 4, 12
> 	6, 8, 9, 11, 4, 12
> 
> In all cases a switch will start by stripping off all of its own
> addresses, and act based on whatever address is next.  When the next
> switch receives the Path, it will do the same.
> 
> As a matter of fact, because of this, I think even this goofy 
> ERO should
> work, even though it is not actually describing the path the data will
> follow:
> 
> 	5, 13, 9, 11, 12
> 
> In this case, the first router strips off its own address (5) 
> and does a
> lookup for 13 - which is a neighbor address, since it's part of switch
> 2, which is directly attached.  When switch 2 gets the packet, it sees
> 13 as one of its own addresses and strips it, and does a 
> lookup for the
> next-hop address (9), and sends the Path there.  etc.
> 
> It all works because a transit router doesn't know (or doesn't have to
> know) the topology of the network beyond its neighbors, and the first
> thing a router does on receipt of an ERO is to strip its own addresses
> off the front of it.
> 
> -- David
> 
This e-mail and any attachments may contain privileged, confidential and/or
copyright information and is for the sole use of the intended addressee. If
you are not the named recipient, please notify the sender immediately and do
not disclose the contents to another person, use it for any purpose, or
store or copy the information in any medium.This message is subject to and
does not create or vary any contractual relationship between Telindus K-NET
Ltd and you.


From owner-mpls@UU.NET  Tue Aug 29 12:00:56 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23512
	for <mpls-archive@lists.ietf.org>; Tue, 29 Aug 2000 12:00:56 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjeiy14237;
	Tue, 29 Aug 2000 16:00:35 GMT
Received: by mail-control.mail.uu.net 
	id QQjeix13917
	for mpls-outgoing; Tue, 29 Aug 2000 15:59:58 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjeix13912
	for <mpls@mail-control.mail.uu.net>; Tue, 29 Aug 2000 15:59:54 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjeix19962
	for <mpls@UU.NET>; Tue, 29 Aug 2000 11:59:49 -0400 (EDT)
Received: from red.juniper.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: natint.juniper.net [207.17.136.129])
	id QQjeix09512
	for <mpls@UU.NET>; Tue, 29 Aug 2000 15:59:34 GMT
Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90])
	by red.juniper.net (8.9.3/8.9.3) with ESMTP id IAA21708;
	Tue, 29 Aug 2000 08:59:01 -0700 (PDT)
Received: (from kireeti@localhost) by kummer.juniper.net (8.8.7/8.7.3) id IAA12258; Tue, 29 Aug 2000 08:57:56 -0700 (PDT)
Date: Tue, 29 Aug 2000 08:57:56 -0700 (PDT)
From: Kireeti Kompella <kireeti@juniper.net>
Message-Id: <200008291557.IAA12258@kummer.juniper.net>
To: mpls@UU.NET, Nick.Williamson@go.ecitele.com
Subject: Re: OSPF TE
Sender: owner-mpls@UU.NET
Precedence: bulk

> OSPF TE draft "draft-katz-yeung-ospf-traffic-02.txt" has expired.

It was re-issued on Friday, Aug 25.  Hopefully, it should show up
soon.

Kireeti.


From owner-mpls@UU.NET  Tue Aug 29 12:56:02 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25810
	for <mpls-archive@lists.ietf.org>; Tue, 29 Aug 2000 12:56:01 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjejb22683;
	Tue, 29 Aug 2000 16:55:35 GMT
Received: by mail-control.mail.uu.net 
	id QQjejb29914
	for mpls-outgoing; Tue, 29 Aug 2000 16:55:03 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjejb29903
	for <mpls@mail-control.mail.uu.net>; Tue, 29 Aug 2000 16:54:54 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjejb17113
	for <mpls@UU.NET>; Tue, 29 Aug 2000 12:54:48 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQjejb22039
	for <mpls@UU.NET>; Tue, 29 Aug 2000 16:54:47 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA02865
	for <mpls@UU.NET>; Tue, 29 Aug 2000 12:54:41 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA17684
	for <mpls@UU.NET>; Tue, 29 Aug 2000 12:54:41 -0400 (EDT)
Message-ID: <39ABEAEE.436BB562@marconi.com>
Date: Tue, 29 Aug 2000 12:55:10 -0400
From: David Charlap <david.charlap@marconi.com>
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: Fw: MPLS and CAC
References: <Pine.SOL.3.93.1000829094103.5030c-100000@tick.ece.utexas.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Aimin Sang wrote:
> 
> Could you please give us a more detailed example (when "this is OK")
> to set overbooking factor? Say: The overbooked reservation is
> temporary because of the re-routing, but who set the overbooking
> factor and how? It is set by the network operator from time to time,
> or the CAC algorithm automatically?

I would hope that every implementation would require the operator to set
this factor.

> Further, I guess you mean that the CAC's decision of overbooking can
> be balanced by traffic engineering. If that is right, are these two
> control at the same time-scale?

The idea here is not that you want the switch to remain overbooked, but
that temporary overbooking is better than lost connections.

If a link fails, a fast-reroute algorithm may shunt the LSP onto another
router.  Later on, when the routing tables stabilize, the ingress router
(perhaps in response to an operator command) may choose to reroute that
LSP again, onto a less-heavily trafficked switch.

If a lot of LSPs get shunted onto a single fallback router, this router
may not have enough resources to maintain all of their original QoS
levels.  At this point, the failover switch has one of two choices.  It
can refuse to accept those LSPs that it can't satisfy, or it can
overbook them.

If it refuses to accept the LSPs, then those connections will go down
until the ingress router can re-signal with a new path.  The LSPs that
did get rerouted will continue to operate at their former QoS levels.

If it overbooks, then none of the connections will go down, but the QoS
on all of them will suffer until the ingress node can reroute them
elsewhere.

There are advantages to either scenario.  For some networks, it is
better that all connections remain up, at reduced quality.  For some
networks, it is better that some connections go down, so that the rest
remain at their normal quality levels.

As for how to actually implement overbooking, I'll leave that part of
the answer to someone with more experience in this area.

-- David


From owner-mpls@UU.NET  Tue Aug 29 13:46:16 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27005
	for <mpls-archive@lists.ietf.org>; Tue, 29 Aug 2000 13:46:15 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjejf23920;
	Tue, 29 Aug 2000 17:45:43 GMT
Received: by mail-control.mail.uu.net 
	id QQjejf16180
	for mpls-outgoing; Tue, 29 Aug 2000 17:45:05 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjeje15969
	for <mpls@mail-control.mail.uu.net>; Tue, 29 Aug 2000 17:44:50 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjeje25247
	for <mpls@UU.NET>; Tue, 29 Aug 2000 13:44:40 -0400 (EDT)
Received: from red.juniper.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: natint.juniper.net [207.17.136.129])
	id QQjeje27361
	for <mpls@UU.NET>; Tue, 29 Aug 2000 17:44:25 GMT
Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90])
	by red.juniper.net (8.9.3/8.9.3) with ESMTP id KAA00135;
	Tue, 29 Aug 2000 10:44:24 -0700 (PDT)
Received: (from kireeti@localhost) by kummer.juniper.net (8.8.7/8.7.3) id KAA12660; Tue, 29 Aug 2000 10:43:24 -0700 (PDT)
Date: Tue, 29 Aug 2000 10:43:24 -0700 (PDT)
From: Kireeti Kompella <kireeti@juniper.net>
Message-Id: <200008291743.KAA12660@kummer.juniper.net>
To: david.charlap@marconi.com, mpls@UU.NET
Subject: Re: Fw: MPLS and CAC
Sender: owner-mpls@UU.NET
Precedence: bulk

While we are on the subject of overbooking, let me point out two
things:
   a) it makes sense to traffic engineer best effort IP traffic,
      and assign it a bandwidth parameter (a point that I believe
      Curtis mentioned, but I'm speaking from memory);
   b) persistent overbooking is fairly common.
(a) is a common reason for (b).

One scenario for (b) is where you have bursty traffic (happens a
lot with IP): say that some traffic trunk averages 40Mbps, but peaks
to 70Mbps.  You could put two of these on a 100Mbps link, and most
of the time, you are just fine.  If the two trunks peak at the same
time, you have some dropped traffic, but on the whole, you come out
ahead (modulo the SLAs with your customers).

You may not want to do this with your Gold customers, but for best
effort IP, this should work just fine.

Kireeti.


From owner-mpls@UU.NET  Tue Aug 29 14:02:23 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27500
	for <mpls-archive@lists.ietf.org>; Tue, 29 Aug 2000 14:02:23 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjejg05503;
	Tue, 29 Aug 2000 18:01:08 GMT
Received: by mail-control.mail.uu.net 
	id QQjejg19253
	for mpls-outgoing; Tue, 29 Aug 2000 18:00:39 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjejg19211
	for <mpls@mail-control.mail.uu.net>; Tue, 29 Aug 2000 18:00:35 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjejg11699
	for <mpls@UU.NET>; Tue, 29 Aug 2000 14:00:17 -0400 (EDT)
Received: from nec.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail1.nec.com [143.101.112.2])
	id QQjejg04708
	for <mpls@UU.NET>; Tue, 29 Aug 2000 18:00:14 GMT
Received: from aslws01.asl.dl.nec.com (aslws01-hme0.asl.dl.nec.com [143.101.10.1])
	by nec.com (8.9.3/8.9.3) with ESMTP id NAA07705;
	Tue, 29 Aug 2000 13:00:09 -0500 (CDT)
Received: by aslws01.asl.dl.nec.com (8.7.3/YDL1.9.1-940729.15)
	id NAA08354(aslws01.asl.dl.nec.com); Tue, 29 Aug 2000 13:00:09 -0500 (CDT)
Received: by aslws220.asl.dl.nec.com (8.7.3/YDL1.9.1-940729.15)
	id NAA11392(aslws220.asl.dl.nec.com); Tue, 29 Aug 2000 13:00:09 -0500 (CDT)
Message-ID: <39ABFA1D.F0F805AE@asl.dl.nec.com>
Date: Tue, 29 Aug 2000 12:59:57 -0500
From: "C. Chen" <cchen@asl.dl.nec.com>
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: David Charlap <david.charlap@marconi.com>
CC: mpls@UU.NET
Subject: Re: Fw: MPLS and CAC
References: <Pine.SOL.3.93.1000829094103.5030c-100000@tick.ece.utexas.edu> <39ABEAEE.436BB562@marconi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

I agree with Mr. Charlap with few additional comments which will be marked
with ">>"

Best Regards,


Cheng C. Chen


David Charlap wrote:

> Aimin Sang wrote:
> >
> > Could you please give us a more detailed example (when "this is OK")
> > to set overbooking factor? Say: The overbooked reservation is
> > temporary because of the re-routing, but who set the overbooking
> > factor and how? It is set by the network operator from time to time,
> > or the CAC algorithm automatically?
>
> I would hope that every implementation would require the operator to set
> this factor.

>> It seems to me that for LSP set up using LDP is almost like ATM PVC and
hence overbooking is almost a necessity and has to be implemented in
conjunction with CAC and routing algorithm due to:
1. Inaccuracy of traffic descriptor supplied by customeror operator of
initial LSP setup
2. Traffic non-coincidence effect due to different time zone
3. Dynamic traffic changes
4. Not all traffic are in active busrst state simultaneously (This used to
call concentration ratio in voice switch) even during busy hour.


>
>
> > Further, I guess you mean that the CAC's decision of overbooking can
> > be balanced by traffic engineering. If that is right, are these two
> > control at the same time-scale?
>
> The idea here is not that you want the switch to remain overbooked, but
> that temporary overbooking is better than lost connections.

>
> >> OVerbooking can also be effective in increasing network utilization
> efficiency even during normal operations. In our experiences with our
> customer  network overbooking is aiming mostly on normal operation.

>
> If a link fails, a fast-reroute algorithm may shunt the LSP onto another
> router.  Later on, when the routing tables stabilize, the ingress router
> (perhaps in response to an operator command) may choose to reroute that
> LSP again, onto a less-heavily trafficked switch.
>
> If a lot of LSPs get shunted onto a single fallback router, this router
> may not have enough resources to maintain all of their original QoS
> levels.  At this point, the failover switch has one of two choices.  It
> can refuse to accept those LSPs that it can't satisfy, or it can
> overbook them.
>
> If it refuses to accept the LSPs, then those connections will go down
> until the ingress router can re-signal with a new path.  The LSPs that
> did get rerouted will continue to operate at their former QoS levels.
>
> If it overbooks, then none of the connections will go down, but the QoS
> on all of them will suffer until the ingress node can reroute them
> elsewhere.
>
> There are advantages to either scenario.  For some networks, it is
> better that all connections remain up, at reduced quality.  For some
> networks, it is better that some connections go down, so that the rest
> remain at their normal quality levels.
>
> As for how to actually implement overbooking, I'll leave that part of
> the answer to someone with more experience in this area.
>
> -- David



From owner-mpls@UU.NET  Tue Aug 29 14:09:59 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27637
	for <mpls-archive@lists.ietf.org>; Tue, 29 Aug 2000 14:09:59 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjejg11959;
	Tue, 29 Aug 2000 18:09:32 GMT
Received: by mail-control.mail.uu.net 
	id QQjejg29764
	for mpls-outgoing; Tue, 29 Aug 2000 18:08:58 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjejg29759
	for <mpls@mail-control.mail.uu.net>; Tue, 29 Aug 2000 18:08:56 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjejg29582
	for <mpls@UU.NET>; Tue, 29 Aug 2000 14:08:48 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQjejg11321
	for <mpls@UU.NET>; Tue, 29 Aug 2000 18:08:47 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA09120
	for <mpls@UU.NET>; Tue, 29 Aug 2000 14:08:45 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA04829
	for <mpls@UU.NET>; Tue, 29 Aug 2000 14:08:45 -0400 (EDT)
Message-ID: <39ABFC4A.EC9CF12B@marconi.com>
Date: Tue, 29 Aug 2000 14:09:14 -0400
From: David Charlap <david.charlap@marconi.com>
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: Fw: MPLS and CAC
References: <200008291743.KAA12660@kummer.juniper.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Kireeti Kompella wrote:
> 
> While we are on the subject of overbooking, let me point out two
> things:
>    a) it makes sense to traffic engineer best effort IP traffic,
>       and assign it a bandwidth parameter (a point that I believe
>       Curtis mentioned, but I'm speaking from memory);
>    b) persistent overbooking is fairly common.
> (a) is a common reason for (b).
> 
> One scenario for (b) is where you have bursty traffic (happens a lot
> with IP): say that some traffic trunk averages 40Mbps, but peaks to
> 70Mbps.  You could put two of these on a 100Mbps link, and most of the
> time, you are just fine.  If the two trunks peak at the same time, you
> have some dropped traffic, but on the whole, you come out ahead
> (modulo the SLAs with your customers).
> 
> You may not want to do this with your Gold customers, but for best
> effort IP, this should work just fine.

In the ATM world, you can signal this kind of bursty traffic with
VBR-style reservations.  Where you can guarantee a certain level, and
allow for intermittent spikes above that level.

Can this be signalled by RSVP as well?  The two IntServ reservation
styles (guaranteed service and controlled-load) don't seem to provide
for this.  If they really can't signal it, then perhaps it would make
sense for someone to propose a new standard service in the IntServ
working group.  (If one of the two existing styles is capable of
signalling this, then forget my suggestion.)

It seems to me that if you have an LSP where you know the traffic to be
bursty (average 40M, spiking to 70M), it would make more sense to signal
these characteristics, instead of trying to determine bandwidth and
overbooking parameters to get the same effect.

-- David


From owner-mpls@UU.NET  Tue Aug 29 14:10:31 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27684
	for <mpls-archive@lists.ietf.org>; Tue, 29 Aug 2000 14:10:31 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjejg15919;
	Tue, 29 Aug 2000 18:09:57 GMT
Received: by mail-control.mail.uu.net 
	id QQjejg29773
	for mpls-outgoing; Tue, 29 Aug 2000 18:09:17 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjejg29768
	for <mpls@mail-control.mail.uu.net>; Tue, 29 Aug 2000 18:09:08 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjejg29653
	for <mpls@UU.NET>; Tue, 29 Aug 2000 14:09:02 -0400 (EDT)
Received: from blsmsgims01.bls.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: iocfirewall2ext.bls.com [139.76.64.4])
	id QQjejg11267
	for <mpls@UU.NET>; Tue, 29 Aug 2000 18:08:45 GMT
Received: from SMTP (blsmsgims01.bls.com [139.76.86.20]) by blsmsgims01.bls.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id RFQQPXAT; Tue, 29 Aug 2000 14:08:43 -0400
Received: from snt.bellsouth.com ([90.30.215.1]) by 139.76.86.20
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Tue, 29 Aug 2000 18:08:42 0000 (GMT)
Received: from gf5142_gxsmlg (g0214070 [90.30.214.70])
	by snt.bellsouth.com (8.9.1b+Sun/8.9.1) with SMTP id OAA22880;
	Tue, 29 Aug 2000 14:08:31 -0400 (EDT)
From: "Steven Wright" <steven.wright@snt.BellSouth.com>
To: "'David Charlap'" <david.charlap@marconi.com>, <mpls@UU.NET>
Subject: RE: Fw: MPLS and CAC
Date: Tue, 29 Aug 2000 14:08:25 -0400
Message-ID: <000301c011e4$21705700$46d61e5a@gf5142_gxsmlg.snt.bst.bls.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
In-Reply-To: <39ABEAEE.436BB562@marconi.com>
Importance: Normal
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

When you talk of overbooking & CAC in an MPLS network are you talking about
the admission of flows to an LSP ( e.g. the packet classification) or the
admission/establishment of LSPs to an interface/link. These seem to be two
separate CAC decisions ...
regards
Steven Wright

> -----Original Message-----
> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of David
> Charlap
> Sent: Tuesday, August 29, 2000 12:55 PM
> To: mpls@UU.NET
> Subject: Re: Fw: MPLS and CAC
>
>
> Aimin Sang wrote:
> >
> > Could you please give us a more detailed example (when "this is OK")
> > to set overbooking factor? Say: The overbooked reservation is
> > temporary because of the re-routing, but who set the overbooking
> > factor and how? It is set by the network operator from time to time,
> > or the CAC algorithm automatically?
>
> I would hope that every implementation would require the
> operator to set
> this factor.
>
> > Further, I guess you mean that the CAC's decision of overbooking can
> > be balanced by traffic engineering. If that is right, are these two
> > control at the same time-scale?
>
> The idea here is not that you want the switch to remain
> overbooked, but
> that temporary overbooking is better than lost connections.
>
> If a link fails, a fast-reroute algorithm may shunt the LSP
> onto another
> router.  Later on, when the routing tables stabilize, the
> ingress router
> (perhaps in response to an operator command) may choose to
> reroute that
> LSP again, onto a less-heavily trafficked switch.
>
> If a lot of LSPs get shunted onto a single fallback router,
> this router
> may not have enough resources to maintain all of their original QoS
> levels.  At this point, the failover switch has one of two
> choices.  It
> can refuse to accept those LSPs that it can't satisfy, or it can
> overbook them.
>
> If it refuses to accept the LSPs, then those connections will go down
> until the ingress router can re-signal with a new path.  The LSPs that
> did get rerouted will continue to operate at their former QoS levels.
>
> If it overbooks, then none of the connections will go down,
> but the QoS
> on all of them will suffer until the ingress node can reroute them
> elsewhere.
>
> There are advantages to either scenario.  For some networks, it is
> better that all connections remain up, at reduced quality.  For some
> networks, it is better that some connections go down, so that the rest
> remain at their normal quality levels.
>
> As for how to actually implement overbooking, I'll leave that part of
> the answer to someone with more experience in this area.
>
> -- David
>
>




From owner-mpls@UU.NET  Tue Aug 29 14:17:29 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27853
	for <mpls-archive@lists.ietf.org>; Tue, 29 Aug 2000 14:17:28 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjejh18164;
	Tue, 29 Aug 2000 18:17:01 GMT
Received: by mail-control.mail.uu.net 
	id QQjejh00657
	for mpls-outgoing; Tue, 29 Aug 2000 18:16:21 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjejh00643
	for <mpls@mail-control.mail.uu.net>; Tue, 29 Aug 2000 18:16:14 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjejh14835
	for <mpls@UU.NET>; Tue, 29 Aug 2000 14:15:19 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQjejh16787
	for <mpls@UU.NET>; Tue, 29 Aug 2000 18:15:19 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA09867
	for <mpls@UU.NET>; Tue, 29 Aug 2000 14:15:16 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA07515
	for <mpls@UU.NET>; Tue, 29 Aug 2000 14:15:16 -0400 (EDT)
Message-ID: <39ABFDD1.D7142F9C@marconi.com>
Date: Tue, 29 Aug 2000 14:15:45 -0400
From: David Charlap <david.charlap@marconi.com>
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: Fw: MPLS and CAC
References: <000301c011e4$21705700$46d61e5a@gf5142_gxsmlg.snt.bst.bls.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Steven Wright wrote:
> 
> When you talk of overbooking & CAC in an MPLS network are you talking
> about the admission of flows to an LSP ( e.g. the packet
> classification) or the admission/establishment of LSPs to an
> interface/link. These seem to be two separate CAC decisions ...

I've been talking about overbooking resources used by transit routers
when making the reservations needed for LSP setup.

-- David


From owner-mpls@UU.NET  Tue Aug 29 14:52:06 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28523
	for <mpls-archive@lists.ietf.org>; Tue, 29 Aug 2000 14:52:06 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjejj22054;
	Tue, 29 Aug 2000 18:51:38 GMT
Received: by mail-control.mail.uu.net 
	id QQjejj02471
	for mpls-outgoing; Tue, 29 Aug 2000 18:51:15 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjejj02464
	for <mpls@mail-control.mail.uu.net>; Tue, 29 Aug 2000 18:51:11 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjejj11263
	for <mpls@UU.NET>; Tue, 29 Aug 2000 14:50:22 -0400 (EDT)
Received: from manchaca.ece.utexas.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: manchaca.ece.utexas.edu [128.83.59.38])
	id QQjejj23944
	for <mpls@UU.NET>; Tue, 29 Aug 2000 18:50:04 GMT
Received: from tick.ece.utexas.edu (tick.ece.utexas.edu [128.83.59.31])
	by manchaca.ece.utexas.edu (8.9.3/8.9.3) with SMTP id NAA21058;
	Tue, 29 Aug 2000 13:50:02 -0500 (CDT)
Date: Tue, 29 Aug 2000 13:50:02 -0500 (CDT)
From: Aimin Sang <sang@ece.utexas.edu>
To: David Charlap <david.charlap@marconi.com>
cc: mpls@UU.NET
Subject: Re: Fw: MPLS and CAC
In-Reply-To: <39ABEAEE.436BB562@marconi.com>
Message-ID: <Pine.SOL.3.93.1000829134343.5030k-100000@tick.ece.utexas.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

Thanks for the answer. I think it maybe better to have the re-routing
for link failure separated from the flow's QoS violation for overbooked
CAC. Of course if link failure is defined as a seriously violated QoS,
then they have to co-work together.

I am expecting someone to give me more insights
about overbooking implementation in CAC, especially for controlled load
service, or CBR/VBR in ATM.

Thanks.

Sincerely,

Aimin
****************************************************************
                Aimin Sang, Ph.D Candidate
                Telecommunication Networks
                ENS 106, ECE Department
                Univ. of Texas at Austin
		
                Mailing/Home Address: 
                1515 Rio Grand Dr., Apt. 723, Plano, TX 75075
		
                Fax:   (214)-291-2280 
                Phone: (972)-943-3285 (Home)
                       (214)-291-2375 (Office)
                URL:   http://www.ece.utexas.edu/~sang

"You can never be too rich, too thin, or have too much bandwidth"
*****************************************************************

On Tue, 29 Aug 2000, David Charlap wrote:

> Aimin Sang wrote:
> > 
> > Could you please give us a more detailed example (when "this is OK")
> > to set overbooking factor? Say: The overbooked reservation is
> > temporary because of the re-routing, but who set the overbooking
> > factor and how? It is set by the network operator from time to time,
> > or the CAC algorithm automatically?
> 
> I would hope that every implementation would require the operator to set
> this factor.
> 
> > Further, I guess you mean that the CAC's decision of overbooking can
> > be balanced by traffic engineering. If that is right, are these two
> > control at the same time-scale?
> 
> The idea here is not that you want the switch to remain overbooked, but
> that temporary overbooking is better than lost connections.
> 
> If a link fails, a fast-reroute algorithm may shunt the LSP onto another
> router.  Later on, when the routing tables stabilize, the ingress router
> (perhaps in response to an operator command) may choose to reroute that
> LSP again, onto a less-heavily trafficked switch.
> 
> If a lot of LSPs get shunted onto a single fallback router, this router
> may not have enough resources to maintain all of their original QoS
> levels.  At this point, the failover switch has one of two choices.  It
> can refuse to accept those LSPs that it can't satisfy, or it can
> overbook them.
> 
> If it refuses to accept the LSPs, then those connections will go down
> until the ingress router can re-signal with a new path.  The LSPs that
> did get rerouted will continue to operate at their former QoS levels.
> 
> If it overbooks, then none of the connections will go down, but the QoS
> on all of them will suffer until the ingress node can reroute them
> elsewhere.
> 
> There are advantages to either scenario.  For some networks, it is
> better that all connections remain up, at reduced quality.  For some
> networks, it is better that some connections go down, so that the rest
> remain at their normal quality levels.
> 
> As for how to actually implement overbooking, I'll leave that part of
> the answer to someone with more experience in this area.
> 
> -- David
> 



From owner-mpls@UU.NET  Tue Aug 29 18:23:30 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01892
	for <mpls-archive@lists.ietf.org>; Tue, 29 Aug 2000 18:23:30 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjejx14889;
	Tue, 29 Aug 2000 22:22:47 GMT
Received: by mail-control.mail.uu.net 
	id QQjejx08116
	for mpls-outgoing; Tue, 29 Aug 2000 22:22:15 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjejx08087
	for <mpls@mail-control.mail.uu.net>; Tue, 29 Aug 2000 22:22:09 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjejx15248
	for <mpls@uu.net>; Tue, 29 Aug 2000 18:21:55 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjejx14123
	for <mpls@uu.net>; Tue, 29 Aug 2000 22:21:39 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id SAA06050
	for mpls@uu.net; Tue, 29 Aug 2000 18:21:39 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjejx07941
	for <mpls@mail-control.mail.uu.net>; Tue, 29 Aug 2000 22:20:59 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjejx28748;
	Tue, 29 Aug 2000 18:20:44 -0400 (EDT)
From: Spencer.Giacalone@predictive.com
Received: from athena.predictive.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: athena.predictive.com [208.209.197.197])
	id QQjejx13219;
	Tue, 29 Aug 2000 22:20:29 GMT
To: mpls@UU.NET, ospf@discuss.microsoft.com, te-wg@UU.NET
Subject: new NEXT ID posted 
X-Mailer: Lotus Notes Release 5.0.2c (Intl) 2 February 2000
Message-ID: <OF3F711AAE.590B8BDA-ON8525694A.005BB0B8@predictive.com>
Date: Tue, 29 Aug 2000 18:22:32 -0400
X-MIMETrack: Serialize by Router on Athena/Predictive(Release 5.0.4a |July 24, 2000) at
 08/29/2000 06:22:36 PM,
	Serialize complete at 08/29/2000 06:22:36 PM
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-mpls@UU.NET
Precedence: bulk

FYI, 

A new revision of the Network Engineering Extensions for OSPFv3 ID (which 
was presented in Pittsburgh) has been posted. The new revision makes a 
first attempt to address concerns presented at the meeting, including:

-Reducing network resource consumption 
-Preventing topological oscillations

Additionally, the new ID separates dynamic TLVs into a new LSA called the 
NEXT-Dynamic LSA, and modifies a few sub-level TLVs. 

The abstract follows. The URL for the new draft is:
http://www.ietf.org/internet-drafts/draft-giacalone-te-optical-next-01.txt

-Spence


Abstract

   This memo defines extensions to OSPFv3 [2] to provide support for
   Network Engineering. This set of extensions is termed Network
   Engineering eXTensions for OSPFv3, or NEXT. The term network
   engineering was chosen to impart NEXT's wide scope of functionality.

   NEXT enables OSPFv3 to discern and advertise holistic state and
   capability data. NEXT may be used to build and present complex "best
   network paths" to outside protocols such as CR-LDP and RSVP-TE.
   NEXT may also be used to support other (perhaps unforeseen) advanced
   topological and administrative processes.

   NEXT is specifically designed to support Traffic Engineering and
   Optical Routing while providing new features and functionality. Note
   that NEXT does not intend to alter native packet routing.

   Since NEXT inter-operates with OSPFv3, it is essentially network
   protocol independent. Therefore, when used with OSPFv3, NEXT can
   support advanced services without limiting networks to IPv4




From owner-mpls@UU.NET  Tue Aug 29 19:57:32 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03048
	for <mpls-archive@lists.ietf.org>; Tue, 29 Aug 2000 19:57:32 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjekd23097;
	Tue, 29 Aug 2000 23:57:10 GMT
Received: by mail-control.mail.uu.net 
	id QQjekd00862
	for mpls-outgoing; Tue, 29 Aug 2000 23:56:36 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjekd00853
	for <mpls@mail-control.mail.uu.net>; Tue, 29 Aug 2000 23:56:32 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjekd14111
	for <mpls@UU.NET>; Tue, 29 Aug 2000 19:56:19 -0400 (EDT)
Received: from maplenetworks.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: w082.z216112072.sjc-ca.dsl.cnc.net [216.112.72.82])
	id QQjekd22649
	for <mpls@UU.NET>; Tue, 29 Aug 2000 23:56:19 GMT
Received: from prasuncomp (farhad_pc [192.168.10.239])
	by maplenetworks.com (8.9.3+Sun/8.9.3/jcm Maplenetworks hub 1.4) with SMTP id QAA15917;
	Tue, 29 Aug 2000 16:55:42 -0700 (PDT)
Message-ID: <011f01c01215$0ca7a360$ef0aa8c0@maplenetworks.com>
From: "Sudhanshu Jain" <sjain@maplenetworks.com>
To: <mpls@UU.NET>
Cc: <jplang@calient.com>
Subject: Query on LMP document?
Date: Tue, 29 Aug 2000 16:58:10 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_011C_01C011DA.4FD0CA80"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_011C_01C011DA.4FD0CA80
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi All,

I have following query on draft-lang-mpls-lmp.

1) If both control channel(s) (primary as well as backup) are not =
available, link goes into DEG state. In DEG state, how does the data =
channel LSP (e.g RSVP refresh) are going to be maintained?=20

2) As per the draft, for verification of the link, data (test message) =
is need to be read over the optical component link. Why do we need this =
kind of capability?=20

Is information gathered from power measurement and Optical Spectrum =
Analyzer (OSA) is not sufficient to declare link connectivity?

Is the Link verification capability in LMP is optional?


-Sudhanshu


------=_NextPart_000_011C_01C011DA.4FD0CA80
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4134.600" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi All,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I have following query on=20
draft-lang-mpls-lmp.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>1) If both control channel(s) (primary =
as well as=20
backup) are not available, link goes into DEG state. In DEG state, how =
does the=20
data channel LSP (e.g RSVP refresh) are going to be maintained? =
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>2) As per the draft, for verification =
of the link,=20
data (test message) is need to be read over the optical component link. =
Why do=20
we need this kind of capability? </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Is information gathered from power =
measurement and=20
Optical Spectrum Analyzer (OSA) is not sufficient to declare link=20
connectivity?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Is the Link verification capability in =
LMP is=20
optional?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>-Sudhanshu</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_011C_01C011DA.4FD0CA80--



From owner-mpls@UU.NET  Tue Aug 29 20:06:04 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03198
	for <mpls-archive@lists.ietf.org>; Tue, 29 Aug 2000 20:06:04 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjeke21996;
	Wed, 30 Aug 2000 00:05:09 GMT
Received: by mail-control.mail.uu.net 
	id QQjeke12900
	for mpls-outgoing; Wed, 30 Aug 2000 00:04:38 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjeke12880
	for <mpls@mail-control.mail.uu.net>; Wed, 30 Aug 2000 00:04:34 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjeke01689
	for <mpls@UU.NET>; Tue, 29 Aug 2000 20:04:10 -0400 (EDT)
Received: from exchsrv1.cosinecom.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail.cosinecom.com [63.88.104.16])
	id QQjeke21370
	for <mpls@UU.NET>; Wed, 30 Aug 2000 00:04:09 GMT
Received: by exchsrv1.cosinecom.com with Internet Mail Service (5.5.2650.21)
	id <RQ7KPH3R>; Tue, 29 Aug 2000 17:03:29 -0700
Message-ID: <7EB7C6B62C4FD41196A80090279A29110BD872@exchsrv1.cosinecom.com>
From: Anoop Ghanwani <anoop@cosinecom.com>
To: "'David Charlap'" <david.charlap@marconi.com>, mpls@UU.NET
Subject: RE: Fw: MPLS and CAC
Date: Tue, 29 Aug 2000 17:03:29 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C01215.B9F79E80"
Sender: owner-mpls@UU.NET
Precedence: bulk

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_01C01215.B9F79E80
Content-Type: text/plain;
	charset="iso-8859-1"



> -----Original Message-----
> From: David Charlap [mailto:david.charlap@marconi.com]
> Sent: Tuesday, August 29, 2000 11:09 AM
> To: mpls@UU.NET
> Subject: Re: Fw: MPLS and CAC
> 
> 
> Kireeti Kompella wrote:
> > 
> > While we are on the subject of overbooking, let me point out two
> > things:
> >    a) it makes sense to traffic engineer best effort IP traffic,
> >       and assign it a bandwidth parameter (a point that I believe
> >       Curtis mentioned, but I'm speaking from memory);
> >    b) persistent overbooking is fairly common.
> > (a) is a common reason for (b).
> > 
> > One scenario for (b) is where you have bursty traffic (happens a lot
> > with IP): say that some traffic trunk averages 40Mbps, but peaks to
> > 70Mbps.  You could put two of these on a 100Mbps link, and 
> most of the
> > time, you are just fine.  If the two trunks peak at the 
> same time, you
> > have some dropped traffic, but on the whole, you come out ahead
> > (modulo the SLAs with your customers).
> > 
> > You may not want to do this with your Gold customers, but for best
> > effort IP, this should work just fine.
> 
> In the ATM world, you can signal this kind of bursty traffic with
> VBR-style reservations.  Where you can guarantee a certain level, and
> allow for intermittent spikes above that level.
> 
> Can this be signalled by RSVP as well?  The two IntServ reservation
> styles (guaranteed service and controlled-load) don't seem to provide
> for this.  If they really can't signal it, then perhaps it would make
> sense for someone to propose a new standard service in the IntServ
> working group.  (If one of the two existing styles is capable of
> signalling this, then forget my suggestion.)
> 
> It seems to me that if you have an LSP where you know the 
> traffic to be
> bursty (average 40M, spiking to 70M), it would make more 
> sense to signal
> these characteristics, instead of trying to determine bandwidth and
> overbooking parameters to get the same effect.

By signaling these (I know CR-LDP allows you to do it, and I think
RSVP does as well), the problem only gets pushed to a later stage
in the process... at some time, the request needs to be translated 
into a real bandwidth value.  The same problem existed with ATM
(see tons of research on finding a good "equivalent capacity" for
a connection).  At that point, the overbooking ratio may be used as
one of the ways for ensuring efficient utilization of resources.

-Anoop

------_=_NextPart_001_01C01215.B9F79E80
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: Fw: MPLS and CAC</TITLE>
</HEAD>
<BODY>
<BR>
<BR>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: David Charlap [<A HREF="mailto:david.charlap@marconi.com">mailto:david.charlap@marconi.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Tuesday, August 29, 2000 11:09 AM</FONT>
<BR><FONT SIZE=2>&gt; To: mpls@UU.NET</FONT>
<BR><FONT SIZE=2>&gt; Subject: Re: Fw: MPLS and CAC</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Kireeti Kompella wrote:</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; While we are on the subject of overbooking, let me point out two</FONT>
<BR><FONT SIZE=2>&gt; &gt; things:</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; a) it makes sense to traffic engineer best effort IP traffic,</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; and assign it a bandwidth parameter (a point that I believe</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Curtis mentioned, but I'm speaking from memory);</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; b) persistent overbooking is fairly common.</FONT>
<BR><FONT SIZE=2>&gt; &gt; (a) is a common reason for (b).</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; One scenario for (b) is where you have bursty traffic (happens a lot</FONT>
<BR><FONT SIZE=2>&gt; &gt; with IP): say that some traffic trunk averages 40Mbps, but peaks to</FONT>
<BR><FONT SIZE=2>&gt; &gt; 70Mbps.&nbsp; You could put two of these on a 100Mbps link, and </FONT>
<BR><FONT SIZE=2>&gt; most of the</FONT>
<BR><FONT SIZE=2>&gt; &gt; time, you are just fine.&nbsp; If the two trunks peak at the </FONT>
<BR><FONT SIZE=2>&gt; same time, you</FONT>
<BR><FONT SIZE=2>&gt; &gt; have some dropped traffic, but on the whole, you come out ahead</FONT>
<BR><FONT SIZE=2>&gt; &gt; (modulo the SLAs with your customers).</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; You may not want to do this with your Gold customers, but for best</FONT>
<BR><FONT SIZE=2>&gt; &gt; effort IP, this should work just fine.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; In the ATM world, you can signal this kind of bursty traffic with</FONT>
<BR><FONT SIZE=2>&gt; VBR-style reservations.&nbsp; Where you can guarantee a certain level, and</FONT>
<BR><FONT SIZE=2>&gt; allow for intermittent spikes above that level.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Can this be signalled by RSVP as well?&nbsp; The two IntServ reservation</FONT>
<BR><FONT SIZE=2>&gt; styles (guaranteed service and controlled-load) don't seem to provide</FONT>
<BR><FONT SIZE=2>&gt; for this.&nbsp; If they really can't signal it, then perhaps it would make</FONT>
<BR><FONT SIZE=2>&gt; sense for someone to propose a new standard service in the IntServ</FONT>
<BR><FONT SIZE=2>&gt; working group.&nbsp; (If one of the two existing styles is capable of</FONT>
<BR><FONT SIZE=2>&gt; signalling this, then forget my suggestion.)</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; It seems to me that if you have an LSP where you know the </FONT>
<BR><FONT SIZE=2>&gt; traffic to be</FONT>
<BR><FONT SIZE=2>&gt; bursty (average 40M, spiking to 70M), it would make more </FONT>
<BR><FONT SIZE=2>&gt; sense to signal</FONT>
<BR><FONT SIZE=2>&gt; these characteristics, instead of trying to determine bandwidth and</FONT>
<BR><FONT SIZE=2>&gt; overbooking parameters to get the same effect.</FONT>
</P>

<P><FONT SIZE=2>By signaling these (I know CR-LDP allows you to do it, and I think</FONT>
<BR><FONT SIZE=2>RSVP does as well), the problem only gets pushed to a later stage</FONT>
<BR><FONT SIZE=2>in the process... at some time, the request needs to be translated </FONT>
<BR><FONT SIZE=2>into a real bandwidth value.&nbsp; The same problem existed with ATM</FONT>
<BR><FONT SIZE=2>(see tons of research on finding a good &quot;equivalent capacity&quot; for</FONT>
<BR><FONT SIZE=2>a connection).&nbsp; At that point, the overbooking ratio may be used as</FONT>
<BR><FONT SIZE=2>one of the ways for ensuring efficient utilization of resources.</FONT>
</P>

<P><FONT SIZE=2>-Anoop</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C01215.B9F79E80--


From owner-mpls@UU.NET  Tue Aug 29 21:50:01 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05130
	for <mpls-archive@lists.ietf.org>; Tue, 29 Aug 2000 21:50:01 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjekl23635;
	Wed, 30 Aug 2000 01:49:31 GMT
Received: by mail-control.mail.uu.net 
	id QQjekl05748
	for mpls-outgoing; Wed, 30 Aug 2000 01:49:03 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjekl05737
	for <mpls@mail-control.mail.uu.net>; Wed, 30 Aug 2000 01:48:58 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjekl27617
	for <mpls@UU.NET>; Tue, 29 Aug 2000 21:48:46 -0400 (EDT)
Received: from mailhost.avici.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.246.215.9])
	id QQjekl02902
	for <mpls@UU.NET>; Wed, 30 Aug 2000 01:48:30 GMT
Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37])
	by mailhost.avici.com (8.11.0/8.11.0) with ESMTP id e7U1mTn20391;
	Tue, 29 Aug 2000 21:48:29 -0400 (EDT)
Received: from curtis-lt.avici.com (localhost [127.0.0.1])
	by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id VAA36849;
	Tue, 29 Aug 2000 21:48:57 -0400 (EDT)
	(envelope-from curtis@curtis-lt.avici.com)
Message-Id: <200008300148.VAA36849@curtis-lt.avici.com>
To: "Erickson Trejo-Reyes" <eenet@electeng.leeds.ac.uk>
cc: curtis@avici.com, david.charlap@marconi.com, mpls@UU.NET
Reply-To: curtis@avici.com
Subject: Re: Fw: MPLS and CAC 
In-reply-to: Your message of "Mon, 28 Aug 2000 21:42:43 BST."
             <01c01130$842fc740$dbb00b81@default.leeds.ac.uk> 
Date: Tue, 29 Aug 2000 21:48:57 -0400
From: Curtis Villamizar <curtis@avici.com>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <01c01130$842fc740$dbb00b81@default.leeds.ac.uk>, "Erickson Trejo-Re
yes" writes:
> 
> By overbooking you mean that, for example, if a voice source can be =
> treated as a VBR source with 64 KB peak bit rate and activity factor of =
> 0.4, then the reservation should be made to a higher value than the =
> computed effective bandwidth (and obviously higher than the average bit =
> rate of 0.4 times 64KB)?

I meant that the allowable sum of reservations could greatly exceed
the desireable sum of reservations.  The ingress would have to be
smart enough to lay out trafffic such that load was well distributed
and was far below the values where CAC would limit the sum of
reservations.

> I had thought that, if an MPLS node is due to use only certain =
> percentage of its total capacity to serve, for example, guaranteed =
> services, it would not be too harmful to make reservations (up to the =
> available percentage) only based on the sustained rate, with the only =
> possible consequence of temporary squeezing the throughput of =
> best-effort services. Comments?

Instead of limiting the guaranteed services to 30% by setting the
reservable bandwidth very low, the ingress can be configured to avoid
any links which are approaching or have over 30% guaranteed service.
Right now the only way to know that it is guaranteed service and now
BE is to give then different holding priorities but that is changing.

Curtis



From owner-mpls@UU.NET  Tue Aug 29 22:37:01 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06439
	for <mpls-archive@lists.ietf.org>; Tue, 29 Aug 2000 22:37:01 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjeko20924;
	Wed, 30 Aug 2000 02:36:36 GMT
Received: by mail-control.mail.uu.net 
	id QQjeko23131
	for mpls-outgoing; Wed, 30 Aug 2000 02:36:08 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjeko23110
	for <mpls@mail-control.mail.uu.net>; Wed, 30 Aug 2000 02:36:06 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjeko02593
	for <mpls@UU.NET>; Tue, 29 Aug 2000 22:36:04 -0400 (EDT)
Received: from mailhost.avici.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.246.215.9])
	id QQjeko19080
	for <mpls@UU.NET>; Wed, 30 Aug 2000 02:35:49 GMT
Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37])
	by mailhost.avici.com (8.11.0/8.11.0) with ESMTP id e7U2Zmn23459;
	Tue, 29 Aug 2000 22:35:48 -0400 (EDT)
Received: from curtis-lt.avici.com (localhost [127.0.0.1])
	by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id WAA37043;
	Tue, 29 Aug 2000 22:36:16 -0400 (EDT)
	(envelope-from curtis@curtis-lt.avici.com)
Message-Id: <200008300236.WAA37043@curtis-lt.avici.com>
To: David Charlap <david.charlap@marconi.com>
cc: mpls@UU.NET
Reply-To: curtis@avici.com
Subject: Re: Fw: MPLS and CAC 
In-reply-to: Your message of "Tue, 29 Aug 2000 14:09:14 EDT."
             <39ABFC4A.EC9CF12B@marconi.com> 
Date: Tue, 29 Aug 2000 22:36:15 -0400
From: Curtis Villamizar <curtis@avici.com>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <39ABFC4A.EC9CF12B@marconi.com>, David Charlap writes:
> Kireeti Kompella wrote:
> > 
> > While we are on the subject of overbooking, let me point out two
> > things:
> >    a) it makes sense to traffic engineer best effort IP traffic,
> >       and assign it a bandwidth parameter (a point that I believe
> >       Curtis mentioned, but I'm speaking from memory);
> >    b) persistent overbooking is fairly common.
> > (a) is a common reason for (b).
> > 
> > One scenario for (b) is where you have bursty traffic (happens a lot
> > with IP): say that some traffic trunk averages 40Mbps, but peaks to
> > 70Mbps.  You could put two of these on a 100Mbps link, and most of the
> > time, you are just fine.  If the two trunks peak at the same time, you
> > have some dropped traffic, but on the whole, you come out ahead
> > (modulo the SLAs with your customers).
> > 
> > You may not want to do this with your Gold customers, but for best
> > effort IP, this should work just fine.
> 
> In the ATM world, you can signal this kind of bursty traffic with
> VBR-style reservations.  Where you can guarantee a certain level, and
> allow for intermittent spikes above that level.
> 
> Can this be signalled by RSVP as well?  The two IntServ reservation
> styles (guaranteed service and controlled-load) don't seem to provide
> for this.  If they really can't signal it, then perhaps it would make
> sense for someone to propose a new standard service in the IntServ
> working group.  (If one of the two existing styles is capable of
> signalling this, then forget my suggestion.)
> 
> It seems to me that if you have an LSP where you know the traffic to be
> bursty (average 40M, spiking to 70M), it would make more sense to signal
> these characteristics, instead of trying to determine bandwidth and
> overbooking parameters to get the same effect.
> 
> -- David


This is not PCR and SCR.  Different problem.  Square peg, round hole,
... etc, etc.

TCP backs off very nicely when congestion occurs so long duration
transfer get a little slow for a while (minutes, hours) and then go
faster as load lessens.  A fair amount of traffic is still
asynchronous bulk transfer (last I looked) and the majority (HTTP) is
interactive bulk transfer and is not perceptibly impacted by mild
congestion and only gets annoying when moderate congestion occurs.

Curtis



From owner-mpls@UU.NET  Wed Aug 30 01:14:18 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09480
	for <mpls-archive@lists.ietf.org>; Wed, 30 Aug 2000 01:14:18 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjeky21105;
	Wed, 30 Aug 2000 05:13:39 GMT
Received: by mail-control.mail.uu.net 
	id QQjeky15804
	for mpls-outgoing; Wed, 30 Aug 2000 05:13:08 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjeky15684
	for <mpls@mail-control.mail.uu.net>; Wed, 30 Aug 2000 05:13:00 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjeky07033
	for <mpls@uu.net>; Wed, 30 Aug 2000 01:12:51 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjeky16362
	for <mpls@uu.net>; Wed, 30 Aug 2000 05:12:51 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id BAA05394
	for mpls@uu.net; Wed, 30 Aug 2000 01:12:50 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjeky15622
	for <mpls@mail-control.mail.uu.net>; Wed, 30 Aug 2000 05:12:20 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjeky06986
	for <mpls@UU.NET>; Wed, 30 Aug 2000 01:12:08 -0400 (EDT)
Received: from yarilo.pluris.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pluris.com [208.227.9.12])
	id QQjeky20141
	for <mpls@UU.NET>; Wed, 30 Aug 2000 05:11:52 GMT
Received: from m3 (volsung.pluris.com [172.16.50.19])
	by yarilo.pluris.com (8.9.2/8.9.1) with SMTP id WAA08814;
	Tue, 29 Aug 2000 22:11:49 -0700 (PDT)
Message-ID: <005801c01240$f6682080$0300000a@pacbell.net>
From: "Bora Akyol" <akyol@pluris.com>
To: <curtis@avici.com>
Cc: <mpls@UU.NET>
References: <200008300148.VAA36849@curtis-lt.avici.com>
Subject: Re: Fw: MPLS and CAC 
Date: Tue, 29 Aug 2000 22:12:57 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Of course overbooking is a poor man's substitute for calculating the
equivalent capacity of the traffic that is passing through the tunnel.

Nevertheless, overbooking is commonly used and people like it (for many
reasons).

Bora


----- Original Message -----
From: "Curtis Villamizar" <curtis@avici.com>
To: "Erickson Trejo-Reyes" <eenet@electeng.leeds.ac.uk>
Cc: <curtis@avici.com>; <david.charlap@marconi.com>; <mpls@UU.NET>
Sent: Tuesday, August 29, 2000 6:48 PM
Subject: Re: Fw: MPLS and CAC



>
> In message <01c01130$842fc740$dbb00b81@default.leeds.ac.uk>, "Erickson
Trejo-Re
> yes" writes:
> >
> > By overbooking you mean that, for example, if a voice source can be =
> > treated as a VBR source with 64 KB peak bit rate and activity factor of
=
> > 0.4, then the reservation should be made to a higher value than the =
> > computed effective bandwidth (and obviously higher than the average bit
=
> > rate of 0.4 times 64KB)?
>
> I meant that the allowable sum of reservations could greatly exceed
> the desireable sum of reservations.  The ingress would have to be
> smart enough to lay out trafffic such that load was well distributed
> and was far below the values where CAC would limit the sum of
> reservations.
>
> > I had thought that, if an MPLS node is due to use only certain =
> > percentage of its total capacity to serve, for example, guaranteed =
> > services, it would not be too harmful to make reservations (up to the =
> > available percentage) only based on the sustained rate, with the only =
> > possible consequence of temporary squeezing the throughput of =
> > best-effort services. Comments?
>
> Instead of limiting the guaranteed services to 30% by setting the
> reservable bandwidth very low, the ingress can be configured to avoid
> any links which are approaching or have over 30% guaranteed service.
> Right now the only way to know that it is guaranteed service and now
> BE is to give then different holding priorities but that is changing.
>
> Curtis



From owner-mpls@UU.NET  Wed Aug 30 09:55:27 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29513
	for <mpls-archive@lists.ietf.org>; Wed, 30 Aug 2000 09:55:26 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjemh19308;
	Wed, 30 Aug 2000 13:55:01 GMT
Received: by mail-control.mail.uu.net 
	id QQjemh08908
	for mpls-outgoing; Wed, 30 Aug 2000 13:54:30 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjemh08901
	for <mpls@mail-control.mail.uu.net>; Wed, 30 Aug 2000 13:54:23 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjemh20097
	for <mpls@UU.NET>; Wed, 30 Aug 2000 09:54:08 -0400 (EDT)
Received: from mailhost.avici.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.246.215.9])
	id QQjemh25050
	for <mpls@UU.NET>; Wed, 30 Aug 2000 13:54:07 GMT
Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37])
	by mailhost.avici.com (8.11.0/8.11.0) with ESMTP id e7UDs6n08607;
	Wed, 30 Aug 2000 09:54:06 -0400 (EDT)
Received: from curtis-lt.avici.com (localhost [127.0.0.1])
	by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id JAA37535;
	Wed, 30 Aug 2000 09:54:35 -0400 (EDT)
	(envelope-from curtis@curtis-lt.avici.com)
Message-Id: <200008301354.JAA37535@curtis-lt.avici.com>
To: "Bora Akyol" <akyol@pluris.com>
cc: curtis@avici.com, mpls@UU.NET
Reply-To: curtis@avici.com
Subject: Re: Fw: MPLS and CAC 
In-reply-to: Your message of "Tue, 29 Aug 2000 22:12:57 PDT."
             <005801c01240$f6682080$0300000a@pacbell.net> 
Date: Wed, 30 Aug 2000 09:54:35 -0400
From: Curtis Villamizar <curtis@avici.com>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <005801c01240$f6682080$0300000a@pacbell.net>, "Bora Akyol" writes:
> Of course overbooking is a poor man's substitute for calculating the
> equivalent capacity of the traffic that is passing through the tunnel.

wrt equivalent capacity:

How do you propose calculating the equivalent capacity of best effort
Internet traffic?  What happens to your calculation when a peer
network (ie: some other AS not under your control) loses a link and
prefers a different inter-provider interconnect?  What happens to your
equivalent capacity predictions when a hot web site or other event
appears (sports events, major news events, etc)?

There is a great deal of unpredictability in Internet traffic
patterns.

wrt overbooking:

In addition to the MPLS usage that is analogous to equivalent capacity
in ATM, overbooking is there to handle the transient traffic layout
when a fault occurs.  The layout is then gradually optimized.

Curtis


From owner-mpls@UU.NET  Wed Aug 30 11:28:33 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01928
	for <mpls-archive@lists.ietf.org>; Wed, 30 Aug 2000 11:28:33 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjemn07118;
	Wed, 30 Aug 2000 15:28:01 GMT
Received: by mail-control.mail.uu.net 
	id QQjemn08915
	for mpls-outgoing; Wed, 30 Aug 2000 15:27:30 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjemn08904
	for <mpls@mail-control.mail.uu.net>; Wed, 30 Aug 2000 15:27:22 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjemn27412
	for <mpls@UU.NET>; Wed, 30 Aug 2000 11:27:14 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQjemn06433
	for <mpls@UU.NET>; Wed, 30 Aug 2000 15:27:14 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA16612
	for <mpls@UU.NET>; Wed, 30 Aug 2000 11:27:11 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA17318
	for <mpls@UU.NET>; Wed, 30 Aug 2000 11:27:14 -0400 (EDT)
Message-ID: <39AD27F1.CEE36138@marconi.com>
Date: Wed, 30 Aug 2000 11:27:45 -0400
From: David Charlap <david.charlap@marconi.com>
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: Fw: MPLS and CAC
References: <200008300236.WAA37043@curtis-lt.avici.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Curtis Villamizar wrote:
> 
> TCP backs off very nicely when congestion occurs so long duration
> transfer get a little slow for a while (minutes, hours) and then go
> faster as load lessens.  A fair amount of traffic is still
> asynchronous bulk transfer (last I looked) and the majority (HTTP) is
> interactive bulk transfer and is not perceptibly impacted by mild
> congestion and only gets annoying when moderate congestion occurs.

And what does this have to do with how a transit router makes
reservations?

Once data enters a tunnel, it is supposed to be opaque to the routers
until it exits that tunnel.  The fact that it may be using a layer-4
protocol with congestino control does not mean a switch can ignore its
reservations.

-- David


From owner-mpls@UU.NET  Wed Aug 30 12:27:14 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03840
	for <mpls-archive@lists.ietf.org>; Wed, 30 Aug 2000 12:27:14 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjemr20002;
	Wed, 30 Aug 2000 16:26:27 GMT
Received: by mail-control.mail.uu.net 
	id QQjemr24932
	for mpls-outgoing; Wed, 30 Aug 2000 16:26:09 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjemr24913
	for <mpls@mail-control.mail.uu.net>; Wed, 30 Aug 2000 16:26:04 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjemr18917
	for <mpls@UU.NET>; Wed, 30 Aug 2000 12:25:59 -0400 (EDT)
Received: from mailhost.avici.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.246.215.9])
	id QQjemr21330
	for <mpls@UU.NET>; Wed, 30 Aug 2000 16:25:56 GMT
Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37])
	by mailhost.avici.com (8.11.0/8.11.0) with ESMTP id e7UGPsn24774;
	Wed, 30 Aug 2000 12:25:54 -0400 (EDT)
Received: from curtis-lt.avici.com (localhost [127.0.0.1])
	by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id MAA37854;
	Wed, 30 Aug 2000 12:26:24 -0400 (EDT)
	(envelope-from curtis@curtis-lt.avici.com)
Message-Id: <200008301626.MAA37854@curtis-lt.avici.com>
To: David Charlap <david.charlap@marconi.com>
cc: mpls@UU.NET
Reply-To: curtis@avici.com
Subject: Re: Fw: MPLS and CAC 
In-reply-to: Your message of "Wed, 30 Aug 2000 11:27:45 EDT."
             <39AD27F1.CEE36138@marconi.com> 
Date: Wed, 30 Aug 2000 12:26:24 -0400
From: Curtis Villamizar <curtis@avici.com>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <39AD27F1.CEE36138@marconi.com>, David Charlap writes:
> Curtis Villamizar wrote:
> > 
> > TCP backs off very nicely when congestion occurs so long duration
> > transfer get a little slow for a while (minutes, hours) and then go
> > faster as load lessens.  A fair amount of traffic is still
> > asynchronous bulk transfer (last I looked) and the majority (HTTP) is
> > interactive bulk transfer and is not perceptibly impacted by mild
> > congestion and only gets annoying when moderate congestion occurs.
> 
> And what does this have to do with how a transit router makes
> reservations?

The reservation amounts are based on historic measurements (ie: over
the course of days or longer) of LSP utilization.  This is the way
many ISPs set the bandwidth parameter as reported in the TE WG.  These
bandwidth amounts can be significantly different from the actual
offerred load.  My first point (not quoted above) was that the
bandwidth on reservations is often wrong.  My second point (above) is
that things work even though the reservation amounts are wrong.
That's the only thing it has to do with making reservations.

> Once data enters a tunnel, it is supposed to be opaque to the routers
> until it exits that tunnel.  The fact that it may be using a layer-4
> protocol with congestino control does not mean a switch can ignore its
> reservations.

If a resource (a link or a queue implementing a shore on that link) is
overbooked, some data is lost.  That's where active queue management
(RED) comes into play.  This is an expected behaviour for BE and for
services such as AF.  My point was that the behavior observed by the
end user for mild congestion is imperceptibly different from
uncongested operation.  This is why it makes sense to an ISP as a
service offering and is in fact a very attractive service offering.

The Internet works and is a viable and growing business in case nobody
on this thread has noticed.  My comments above were just intended as
insights into why it works despite not offering guarentees.

Curtis


From owner-mpls@UU.NET  Wed Aug 30 13:55:52 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05886
	for <mpls-archive@lists.ietf.org>; Wed, 30 Aug 2000 13:55:52 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjemx09116;
	Wed, 30 Aug 2000 17:55:27 GMT
Received: by mail-control.mail.uu.net 
	id QQjemx13727
	for mpls-outgoing; Wed, 30 Aug 2000 17:54:55 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjemx13721
	for <mpls@mail-control.mail.uu.net>; Wed, 30 Aug 2000 17:54:53 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjemx04375
	for <mpls@uu.net>; Wed, 30 Aug 2000 13:54:52 -0400 (EDT)
Received: from hotmail.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: f208.pav1.hotmail.com [64.4.31.208])
	id QQjemx08625
	for <mpls@uu.net>; Wed, 30 Aug 2000 17:54:36 GMT
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Wed, 30 Aug 2000 10:54:36 -0700
Received: from 207.53.175.35 by pv1fd.pav1.hotmail.msn.com with HTTP;	Wed, 30 Aug 2000 17:54:36 GMT
X-Originating-IP: [207.53.175.35]
From: "Mark Dewey" <deweymark@hotmail.com>
To: mpls@UU.NET
Cc: rsvp@isi.edu, int-serv@isi.edu
Subject: CR-LDP traffic parameter TLV and RSVP
Date: Wed, 30 Aug 2000 17:54:36 GMT
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F2086lCPx33E1ioWwr20000196b@hotmail.com>
X-OriginalArrivalTime: 30 Aug 2000 17:54:36.0245 (UTC) FILETIME=[5C3AF850:01C012AB]
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

   I apologize for the wide distribution. I am not sure which mailing list 
this question belongs to.

   I understand, in CR-LDP, the qos characteristics(e.g bandwidth) of an LSP 
tunnel can be specified in traffic parameter (e.g CDR) TLV.

How is this value  specified in RSVP if it were used to establish a LSP 
tunnel with qos characteristics?


If sender TSPEC object is used, should the node implement integrated 
services (CL,GS)?

Thanks,
-Mark






_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at 
http://profiles.msn.com.



From owner-mpls@UU.NET  Wed Aug 30 14:39:37 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06632
	for <mpls-archive@lists.ietf.org>; Wed, 30 Aug 2000 14:39:37 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjena29471;
	Wed, 30 Aug 2000 18:39:09 GMT
Received: by mail-control.mail.uu.net 
	id QQjena29023
	for mpls-outgoing; Wed, 30 Aug 2000 18:38:39 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjena29012
	for <mpls@mail-control.mail.uu.net>; Wed, 30 Aug 2000 18:38:35 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjena04782
	for <mpls@UU.NET>; Wed, 30 Aug 2000 14:38:28 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQjena28706
	for <mpls@UU.NET>; Wed, 30 Aug 2000 18:38:27 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA03897;
	Wed, 30 Aug 2000 14:37:52 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA03438;
	Wed, 30 Aug 2000 14:37:55 -0400 (EDT)
Message-ID: <39AD54A2.2A62EFBB@marconi.com>
Date: Wed, 30 Aug 2000 14:38:26 -0400
From: David Charlap <david.charlap@marconi.com>
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
CC: rsvp@isi.edu, int-serv@isi.edu
Subject: Re: CR-LDP traffic parameter TLV and RSVP
References: <F2086lCPx33E1ioWwr20000196b@hotmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Mark Dewey wrote:
> 
>    I apologize for the wide distribution. I am not sure which mailing
> list this question belongs to.
> 
>    I understand, in CR-LDP, the qos characteristics(e.g bandwidth) of
> an LSP tunnel can be specified in traffic parameter (e.g CDR) TLV.
> 
> How is this value  specified in RSVP if it were used to establish a
> LSP tunnel with qos characteristics?
> 
> If sender TSPEC object is used, should the node implement integrated
> services (CL,GS)?

RSVP-TE defines new CTypes for the TSPEC and FLOWSPEC objects - the
"Class of service" type.  Best-effort is defined here.

For all QoS reservations, the IntServ variations of these objects are
used.

In all cases (best effor or otherwise), TSPEC is mandatory in Path
messages and FLOWSPEC is mandatory in Resv messages.

In terms of actual usage:

- The TSpec will define the level of QoS that the sender wants, as
  decscribed by the 5 generic token-bucket parameters: bucket rate (r),
  bucket size (b), peak data rate (p), minimum packet size (m) and
  maximum packet size (M).

- An ADSPEC object is optional, but strongly recommended in this
  situation.  The ADSPEC contains four generic parameters (hop count,
  bandwidth estimate, minimum latency, and composed MTU).  It also
  contains service-specific fragments - for guaranteed service (which
  includes the delay-factor parameters CTot, CSum, DTot and DSum) and
  controlled-load.

  The ADSPEC defines several things.  First off, its parameters are
  modified by the transit routers as it is passed from PHOP to NHOP, so
  that the parameters that arrive at the egress node contain the LUB of
  the parameters for all switches.  (For instance, the bandwidth
  estimate is reduced by each switch it passes through, resulting in
  the egress router seeing the amount of bandwidth available in the
  most-congested router.)

  Second, the ADSPEC defines which services the sender can handle a
  reservation in.  The presence of a service-specific fragment (GS or
  CL) indicates that the sender can handle that kind of reservation.
  Its absence indicates that it can not handle it.

  One thing I'm unclear on is what it means if an ADSPEC is sent with
  no service-specific fragments.  IMO, this means that neither kind of
  reservation is adequate, and that something akin to best-effort should
  be reserved.  (IOW, an ADSPEC with no service-specific fragments is
  almost illegal, since it would prevent any reservation from being
  established.)  I've heard from others, however, that this means that
  the receiver is free to choose any kind of reservation.

  I'm also not sure what it means if a Path is received with an IntServ
  class of TSPEC but no ADSPEC.  I suppose this means that the receiver
  is free to choose any kind of reservation, and must do so without the
  information that an ADSPEC would have gathered.

- Anyway, once the receiver gets the Path message, it must choose the
  reservation.

  Given that MPLS is router-to-router and not application-to-
  application, the egress router really doesn't have too much choice in
  what it can try to reserve.  It logically must try to reserve what the
  ingress node requested in its TSPEC object.  To do otherwise would
  require knowledge beyond that which is provided by RSVP.  Such meta-
  knowledge could be configured by an operator, or provided as a value-
  added feature, but IMO, it is beyond the scope of the MPLS working
  group.

Getting back to your question about whether integrated services should
be implemented, I would respond with a qualified yes.  A formal IntServ
stack is not necessary for MPLS with RSVP, but the switch must be able
to understand the IntServ objects and be able to make appropriate
reservations.  If it can't do this (which should really only be true if
the switch is incapable of making QoS-type reservations), then it should
probably reject Path and Resv messages that include IntServ-class TSPEC
and FLOWSPEC objects.

-- David


From owner-mpls@UU.NET  Wed Aug 30 16:04:21 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08258
	for <mpls-archive@lists.ietf.org>; Wed, 30 Aug 2000 16:04:21 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjeng04775;
	Wed, 30 Aug 2000 20:03:57 GMT
Received: by mail-control.mail.uu.net 
	id QQjeng27467
	for mpls-outgoing; Wed, 30 Aug 2000 20:03:19 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQjeng27387
	for <mpls@mail-control.mail.uu.net>; Wed, 30 Aug 2000 20:03:07 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjeng21519
	for <mpls@uu.net>; Wed, 30 Aug 2000 16:02:55 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjeng03946
	for <mpls@uu.net>; Wed, 30 Aug 2000 20:02:54 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA28189
	for mpls@uu.net; Wed, 30 Aug 2000 16:02:53 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjeng26226
	for <mpls@mail-control.mail.uu.net>; Wed, 30 Aug 2000 20:02:31 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjeng29334;
	Wed, 30 Aug 2000 16:02:25 -0400 (EDT)
Received: from tnnt3.tachion.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [198.139.117.130])
	id QQjeng03590;
	Wed, 30 Aug 2000 20:02:24 GMT
Received: by TNNT3 with Internet Mail Service (5.5.2650.21)
	id <R9H66NN2>; Wed, 30 Aug 2000 16:06:20 -0400
Message-ID: <A64EB7AC0201D411B864009027DC856C054DC9@TNNT3>
From: Cheenu Srinivasan <csrinivasan@tachion.com>
To: "'mpls@UU.NET'" <mpls@UU.NET>, "'te-wg@UU.NET'" <te-wg@UU.NET>
Subject: Consensus for draft-kompella-mpls-te-mib-00.txt
Date: Wed, 30 Aug 2000 16:06:19 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C012BD.C32B958A"
Sender: owner-mpls@UU.NET
Precedence: bulk

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_01C012BD.C32B958A
Content-Type: text/plain;
	charset="iso-8859-1"

MPLS/TE WG members,

        This message is in response to the recent introduction
of the draft entitled, "draft-kompella-mpls-te-mib-00.txt" to
the TE WG and the debate which followed. Since no consensus could 
be reached in the TE WG as to whether or not to adopt this draft, 
the TE WG chair felt that this work was still important, and as such 
has directed the author of this draft and the authors of the
MPLS-TE-MIB to work out a consensus for folding-in the salient 
portions of the draft into the MPLS-TE-MIB. We have done so, and
below you will find the fruits of our labor. We will wait for the
feedback of the working groups before posting a revised version of
MPLS-TE-MIB incorporating these changes.

        Tom Nadeau
        Kireeti Kompella
        Cheenu Srinivasan
        Arun Vishwanathan

----------------------------------------------------------------------------
-----------

        1. Two scalars to indicate the number of configured and 
           active tunnels: mplsConfiguredTunnels and mplsActiveTunnels. An
           "active" tunnel denotes an mplsTunnelEntry with
           mplsTunnelOperStatus = Up. A "configured" tunnel denotes an
           mplsTunnelEntry whose mplsTunnelRowStatus is "active". 

        2. The addition of a new performance table which AUGMENTS
           the mpslTunnelTable which includes the following
           attributes:

        mplsTunnelPerfPackets OBJECT-TYPE 
        SYNTAX     Counter32
                                   
        mplsTunnelHCPerfPackets OBJECT-TYPE 
        SYNTAX     Counter64
                                   
        mplsTunnelErrors OBJECT-TYPE
        SYNTAX  Counter32

        mplsTunnelPerfBytes OBJECT-TYPE 
        SYNTAX     Counter32
                                   
        mplsTunnelHCPerfBytes OBJECT-TYPE 
        SYNTAX     Counter64
                                   
        3. The following objects will be added to the tunnelTable
           to allow for further monitoring of the state
           of the tunnel once it is configured.

                mplsTunnelPrimaryTimeUp    TimeStamp,
                mplsTunnelPathChanges      Counter32,
                mplsTunnelLastPathChange   TimeStamp,
                mplsTunnelCreationTime     TimeStamp,
                mplsTunnelStateTransitions Unsigned32,
                mplsTunnelEgressLSRId      Unsigned32,

        A path change is when the current active path (over which 
        packets are being forwarded) changes to another path. 

        4. The addition of a new table called mplsTunnelCHopTable
           which lists the computed HOPs for a tunnel path.

        5. We will enhance the mplsTunnelHopStrictOrLoose object
           to change its name to mplsTunnelHopType. This object
           will become an enumeration of { strict, loose }.

        6.  A new bit will be added to the mplsTunnelSessionAttribute
            called ComputePath. This bit instructs the LSR to
            use Constraint-based Routing to compute the actual path to 
            be traversed by this tunnel instance.

        7. Resource class affinity attributes associated with a traffic 
           tunnel can be used to specify the class of resources which are
           to be explicitly included or excluded from the path of the
traffic
           trunk. These are policy attributes which can be used to impose
           additional constraints on the path traversed by a given traffic
           trunk. 

        Three new objects shall be added to the tunnelEntry:
                                
        mplsTunnelIncludeAnyAffinity OBJECT-TYPE
        SYNTAX          Integer32
        MAX-ACCESS      not-accessible
        STATUS          current
        DESCRIPTION 
          "A link satisfies the include-any constraint iff  the constraint
is zero,
           or the link and the constraint have a resource class in common." 
        REFERENCE "See section section 5.6.3 of RFC 2702." 
         
        mplsTunnelIncludeAllAffinity OBJECT-TYPE
        SYNTAX          Integer32
        MAX-ACCESS    not-accessible
        STATUS        current
        DESCRIPTION 
          "A link satisfies the include-all constraint if and only if the
link
           contains all of the administrative groups specified in the
constraint."
        REFERENCE "RFC 2702, section 5.6.3."

        mplsTunnelExcludeAllAffinity OBJECT-TYPE
        SYNTAX          Integer32
        MAX-ACCESS    not-accessible
        STATUS          current 
        DESCRIPTION 
          "A link satisfies the exclude constraint if and only if the 
          link contains none of the administrative groups specified in 
          the constraint."
        REFERENCE "RFC 2702, section 5.6.3."


        8. A scalar which will denote which type(s) of TE distribution
protocol(s)
           is(are) in use by the LSR. 

        mplsTunnelTEDistProto OBJECT-TYPE
        SYNTAX      BITS { other (0), ospf(1), isis (2) }
        MAX-ACCESS    not-accessible
        STATUS        current 
        DESCRIPTION
          "The traffic engineering distribution protocol(s) used by this
LSR. Note that
           an LSR may support more than one distribution protocol
simultaneously."

----------------------------------------------------------------------------
-----------

------_=_NextPart_001_01C012BD.C32B958A
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>Consensus for draft-kompella-mpls-te-mib-00.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>MPLS/TE WG members,</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This =
message is in response to the recent introduction</FONT>
<BR><FONT SIZE=3D2>of the draft entitled, =
&quot;draft-kompella-mpls-te-mib-00.txt&quot; to</FONT>
<BR><FONT SIZE=3D2>the TE WG and the debate which followed. Since no =
consensus could </FONT>
<BR><FONT SIZE=3D2>be reached in the TE WG as to whether or not to =
adopt this draft, </FONT>
<BR><FONT SIZE=3D2>the TE WG chair felt that this work was still =
important, and as such </FONT>
<BR><FONT SIZE=3D2>has directed the author of this draft and the =
authors of the</FONT>
<BR><FONT SIZE=3D2>MPLS-TE-MIB to work out a consensus for folding-in =
the salient </FONT>
<BR><FONT SIZE=3D2>portions of the draft into the MPLS-TE-MIB. We have =
done so, and</FONT>
<BR><FONT SIZE=3D2>below you will find the fruits of our labor. We will =
wait for the</FONT>
<BR><FONT SIZE=3D2>feedback of the working groups before posting a =
revised version of</FONT>
<BR><FONT SIZE=3D2>MPLS-TE-MIB incorporating these changes.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tom =
Nadeau</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Kireeti =
Kompella</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Cheenu =
Srinivasan</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Arun =
Vishwanathan</FONT>
</P>

<P><FONT =
SIZE=3D2>---------------------------------------------------------------=
------------------------</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1. Two =
scalars to indicate the number of configured and </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
active tunnels: mplsConfiguredTunnels and mplsActiveTunnels. An</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&quot;active&quot; tunnel denotes an mplsTunnelEntry with</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
mplsTunnelOperStatus =3D Up. A &quot;configured&quot; tunnel denotes =
an</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
mplsTunnelEntry whose mplsTunnelRowStatus is &quot;active&quot;. =
</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2. The =
addition of a new performance table which AUGMENTS</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
the mpslTunnelTable which includes the following</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
attributes:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
mplsTunnelPerfPackets OBJECT-TYPE </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SYNTAX&nbsp;&nbsp;&nbsp;&nbsp; Counter32</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
mplsTunnelHCPerfPackets OBJECT-TYPE </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SYNTAX&nbsp;&nbsp;&nbsp;&nbsp; Counter64</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
mplsTunnelErrors OBJECT-TYPE</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SYNTAX&nbsp; Counter32</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
mplsTunnelPerfBytes OBJECT-TYPE </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SYNTAX&nbsp;&nbsp;&nbsp;&nbsp; Counter32</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
mplsTunnelHCPerfBytes OBJECT-TYPE </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SYNTAX&nbsp;&nbsp;&nbsp;&nbsp; Counter64</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3. The =
following objects will be added to the tunnelTable</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
to allow for further monitoring of the state</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
of the tunnel once it is configured.</FONT>
</P>

<P><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; mplsTunnelPrimaryTimeUp&nbsp;&nbsp;&nbsp; =
TimeStamp,</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; =
mplsTunnelPathChanges&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Counter32,</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; mplsTunnelLastPathChange&nbsp;&nbsp; =
TimeStamp,</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; =
mplsTunnelCreationTime&nbsp;&nbsp;&nbsp;&nbsp; TimeStamp,</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; mplsTunnelStateTransitions =
Unsigned32,</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; =
mplsTunnelEgressLSRId&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Unsigned32,</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; A path =
change is when the current active path (over which </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; packets =
are being forwarded) changes to another path. </FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 4. The =
addition of a new table called mplsTunnelCHopTable</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
which lists the computed HOPs for a tunnel path.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 5. We will =
enhance the mplsTunnelHopStrictOrLoose object</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
to change its name to mplsTunnelHopType. This object</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
will become an enumeration of { strict, loose }.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 6.&nbsp; A =
new bit will be added to the mplsTunnelSessionAttribute</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; called ComputePath. This bit instructs the LSR to</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; use Constraint-based Routing to compute the actual path to </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; be traversed by this tunnel instance.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 7. =
Resource class affinity attributes associated with a traffic </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
tunnel can be used to specify the class of resources which are</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
to be explicitly included or excluded from the path of the =
traffic</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
trunk. These are policy attributes which can be used to impose</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
additional constraints on the path traversed by a given traffic</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
trunk. </FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Three new =
objects shall be added to the tunnelEntry:</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
mplsTunnelIncludeAnyAffinity OBJECT-TYPE</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Integer32</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
MAX-ACCESS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; not-accessible</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
STATUS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
current</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
DESCRIPTION </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;A =
link satisfies the include-any constraint iff&nbsp; the constraint is =
zero,</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
or the link and the constraint have a resource class in common.&quot; =
</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; REFERENCE =
&quot;See section section 5.6.3 of RFC 2702.&quot; </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
mplsTunnelIncludeAllAffinity OBJECT-TYPE</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Integer32</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
MAX-ACCESS&nbsp;&nbsp;&nbsp; not-accessible</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
STATUS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; current</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
DESCRIPTION </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;A =
link satisfies the include-all constraint if and only if the =
link</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
contains all of the administrative groups specified in the =
constraint.&quot;</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; REFERENCE =
&quot;RFC 2702, section 5.6.3.&quot;</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
mplsTunnelExcludeAllAffinity OBJECT-TYPE</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Integer32</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
MAX-ACCESS&nbsp;&nbsp;&nbsp; not-accessible</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
STATUS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; current =
</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
DESCRIPTION </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;A =
link satisfies the exclude constraint if and only if the </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; link =
contains none of the administrative groups specified in </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; the constraint.&quot;</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; REFERENCE =
&quot;RFC 2702, section 5.6.3.&quot;</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 8. A =
scalar which will denote which type(s) of TE distribution =
protocol(s)</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
is(are) in use by the LSR. </FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
mplsTunnelTEDistProto OBJECT-TYPE</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; BITS { other (0), ospf(1), isis =
(2) }</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
MAX-ACCESS&nbsp;&nbsp;&nbsp; not-accessible</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
STATUS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; current </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
DESCRIPTION</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&quot;The traffic engineering distribution protocol(s) used by this =
LSR. Note that</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
an LSR may support more than one distribution protocol =
simultaneously.&quot;</FONT>
</P>

<P><FONT =
SIZE=3D2>---------------------------------------------------------------=
------------------------</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C012BD.C32B958A--



From owner-mpls@UU.NET  Wed Aug 30 17:03:26 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09170
	for <mpls-archive@lists.ietf.org>; Wed, 30 Aug 2000 17:03:25 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjenk21695;
	Wed, 30 Aug 2000 21:03:00 GMT
Received: by mail-control.mail.uu.net 
	id QQjenk14953
	for mpls-outgoing; Wed, 30 Aug 2000 21:02:29 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjenk14465
	for <mpls@mail-control.mail.uu.net>; Wed, 30 Aug 2000 21:02:14 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjenk10952
	for <mpls@UU.NET>; Wed, 30 Aug 2000 17:02:14 -0400 (EDT)
Received: from bridge.axiowave.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [209.6.34.2])
	id QQjenk21000
	for <mpls@UU.NET>; Wed, 30 Aug 2000 21:02:14 GMT
Received: from an1.axiowave.com (an1 [192.168.0.2])
	by bridge.axiowave.com (8.9.3/8.9.3) with ESMTP id RAA21557;
	Wed, 30 Aug 2000 17:00:30 -0400
Received: by AN1 with Internet Mail Service (5.5.2650.21)
	id <R5LCHQKG>; Wed, 30 Aug 2000 17:02:05 -0400
Message-ID: <A16247A35C3AD41186260050047706D806F244@AN1>
From: Ram Krishnan <ram@axiowave.com>
To: "'Kireeti Kompella'" <kireeti@juniper.net>, david.charlap@marconi.com,
        mpls@UU.NET
Subject: RE: Fw: MPLS and CAC
Date: Wed, 30 Aug 2000 17:02:00 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Even with Gold customers, you can do this as long as you
can characterise the traffic profiles of your Gold customers
carefully and provision parameters such as effective bandwidth
and buffer space accurately.

Regards,
Ram


While we are on the subject of overbooking, let me point out two
things:
   a) it makes sense to traffic engineer best effort IP traffic,
      and assign it a bandwidth parameter (a point that I believe
      Curtis mentioned, but I'm speaking from memory);
   b) persistent overbooking is fairly common.
(a) is a common reason for (b).

One scenario for (b) is where you have bursty traffic (happens a
lot with IP): say that some traffic trunk averages 40Mbps, but peaks
to 70Mbps.  You could put two of these on a 100Mbps link, and most
of the time, you are just fine.  If the two trunks peak at the same
time, you have some dropped traffic, but on the whole, you come out
ahead (modulo the SLAs with your customers).

You may not want to do this with your Gold customers, but for best
effort IP, this should work just fine.

Kireeti.


From owner-mpls@UU.NET  Wed Aug 30 17:25:13 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09431
	for <mpls-archive@lists.ietf.org>; Wed, 30 Aug 2000 17:25:13 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjenl07805;
	Wed, 30 Aug 2000 21:24:18 GMT
Received: by mail-control.mail.uu.net 
	id QQjenl24507
	for mpls-outgoing; Wed, 30 Aug 2000 21:23:50 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjenl24500
	for <mpls@mail-control.mail.uu.net>; Wed, 30 Aug 2000 21:23:49 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjenl14927
	for <mpls@UU.NET>; Wed, 30 Aug 2000 17:23:29 -0400 (EDT)
Received: from exchsrv1.cosinecom.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail.cosinecom.com [63.88.104.16])
	id QQjenl12533
	for <mpls@UU.NET>; Wed, 30 Aug 2000 21:23:27 GMT
Received: by exchsrv1.cosinecom.com with Internet Mail Service (5.5.2650.21)
	id <RQ7KP2ZY>; Wed, 30 Aug 2000 14:22:47 -0700
Message-ID: <7EB7C6B62C4FD41196A80090279A29112D94F1@exchsrv1.cosinecom.com>
From: Jay Wang <jawang@cosinecom.com>
To: "'Ram Krishnan'" <ram@axiowave.com>,
        "'Kireeti Kompella'"
	 <kireeti@juniper.net>,
        david.charlap@marconi.com, mpls@UU.NET
Subject: RE: Fw: MPLS and CAC
Date: Wed, 30 Aug 2000 14:22:44 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C012C8.6FF0B8E0"
Sender: owner-mpls@UU.NET
Precedence: bulk

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_01C012C8.6FF0B8E0
Content-Type: text/plain;
	charset="iso-8859-1"

Well, "Gold" when used as an adjective is a relative term.
But in any case, no, an accurate characterization of customer
traffic does not lead to a conclusion that tells you whether you 
can overbook your "Gold" customer or not.  This is primary a 
SLA and policy issue.  One way of the other, accurate customer
traffic profiling only gives you the ability to execute your SLA 
more precisely and possibly more efficiently by, for example,
taking advantage of multiplexing gain.

regards,

- Jay  


> -----Original Message-----
> From: Ram Krishnan [mailto:ram@axiowave.com]
> Sent: Wednesday, August 30, 2000 2:02 PM
> To: 'Kireeti Kompella'; david.charlap@marconi.com; mpls@UU.NET
> Subject: RE: Fw: MPLS and CAC
> 
> 
> Even with Gold customers, you can do this as long as you
> can characterise the traffic profiles of your Gold customers
> carefully and provision parameters such as effective bandwidth
> and buffer space accurately.
> 
> Regards,
> Ram
> 
> 
> While we are on the subject of overbooking, let me point out two
> things:
>    a) it makes sense to traffic engineer best effort IP traffic,
>       and assign it a bandwidth parameter (a point that I believe
>       Curtis mentioned, but I'm speaking from memory);
>    b) persistent overbooking is fairly common.
> (a) is a common reason for (b).
> 
> One scenario for (b) is where you have bursty traffic (happens a
> lot with IP): say that some traffic trunk averages 40Mbps, but peaks
> to 70Mbps.  You could put two of these on a 100Mbps link, and most
> of the time, you are just fine.  If the two trunks peak at the same
> time, you have some dropped traffic, but on the whole, you come out
> ahead (modulo the SLAs with your customers).
> 
> You may not want to do this with your Gold customers, but for best
> effort IP, this should work just fine.
> 
> Kireeti.
> 

------_=_NextPart_001_01C012C8.6FF0B8E0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: Fw: MPLS and CAC</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Well, &quot;Gold&quot; when used as an adjective is a relative term.</FONT>
<BR><FONT SIZE=2>But in any case, no, an accurate characterization of customer</FONT>
<BR><FONT SIZE=2>traffic does not lead to a conclusion that tells you whether you </FONT>
<BR><FONT SIZE=2>can overbook your &quot;Gold&quot; customer or not.&nbsp; This is primary a </FONT>
<BR><FONT SIZE=2>SLA and policy issue.&nbsp; One way of the other, accurate customer</FONT>
<BR><FONT SIZE=2>traffic profiling only gives you the ability to execute your SLA </FONT>
<BR><FONT SIZE=2>more precisely and possibly more efficiently by, for example,</FONT>
<BR><FONT SIZE=2>taking advantage of multiplexing gain.</FONT>
</P>

<P><FONT SIZE=2>regards,</FONT>
</P>

<P><FONT SIZE=2>- Jay&nbsp; </FONT>
</P>
<BR>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Ram Krishnan [<A HREF="mailto:ram@axiowave.com">mailto:ram@axiowave.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Wednesday, August 30, 2000 2:02 PM</FONT>
<BR><FONT SIZE=2>&gt; To: 'Kireeti Kompella'; david.charlap@marconi.com; mpls@UU.NET</FONT>
<BR><FONT SIZE=2>&gt; Subject: RE: Fw: MPLS and CAC</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Even with Gold customers, you can do this as long as you</FONT>
<BR><FONT SIZE=2>&gt; can characterise the traffic profiles of your Gold customers</FONT>
<BR><FONT SIZE=2>&gt; carefully and provision parameters such as effective bandwidth</FONT>
<BR><FONT SIZE=2>&gt; and buffer space accurately.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Regards,</FONT>
<BR><FONT SIZE=2>&gt; Ram</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; While we are on the subject of overbooking, let me point out two</FONT>
<BR><FONT SIZE=2>&gt; things:</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; a) it makes sense to traffic engineer best effort IP traffic,</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; and assign it a bandwidth parameter (a point that I believe</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Curtis mentioned, but I'm speaking from memory);</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; b) persistent overbooking is fairly common.</FONT>
<BR><FONT SIZE=2>&gt; (a) is a common reason for (b).</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; One scenario for (b) is where you have bursty traffic (happens a</FONT>
<BR><FONT SIZE=2>&gt; lot with IP): say that some traffic trunk averages 40Mbps, but peaks</FONT>
<BR><FONT SIZE=2>&gt; to 70Mbps.&nbsp; You could put two of these on a 100Mbps link, and most</FONT>
<BR><FONT SIZE=2>&gt; of the time, you are just fine.&nbsp; If the two trunks peak at the same</FONT>
<BR><FONT SIZE=2>&gt; time, you have some dropped traffic, but on the whole, you come out</FONT>
<BR><FONT SIZE=2>&gt; ahead (modulo the SLAs with your customers).</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; You may not want to do this with your Gold customers, but for best</FONT>
<BR><FONT SIZE=2>&gt; effort IP, this should work just fine.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Kireeti.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C012C8.6FF0B8E0--


From owner-mpls@UU.NET  Wed Aug 30 17:57:25 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09910
	for <mpls-archive@lists.ietf.org>; Wed, 30 Aug 2000 17:57:24 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjenn00502;
	Wed, 30 Aug 2000 21:56:58 GMT
Received: by mail-control.mail.uu.net 
	id QQjenn27289
	for mpls-outgoing; Wed, 30 Aug 2000 21:56:30 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQjenn27283
	for <mpls@mail-control.mail.uu.net>; Wed, 30 Aug 2000 21:56:27 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjenn20304
	for <mpls@UU.NET>; Wed, 30 Aug 2000 17:56:15 -0400 (EDT)
Received: from manchaca.ece.utexas.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: manchaca.ece.utexas.edu [128.83.59.38])
	id QQjenn29814
	for <mpls@UU.NET>; Wed, 30 Aug 2000 21:55:59 GMT
Received: from tick.ece.utexas.edu (tick.ece.utexas.edu [128.83.59.31])
	by manchaca.ece.utexas.edu (8.9.3/8.9.3) with SMTP id QAA06627;
	Wed, 30 Aug 2000 16:55:54 -0500 (CDT)
Date: Wed, 30 Aug 2000 16:55:54 -0500 (CDT)
From: Aimin Sang <sang@ece.utexas.edu>
To: Jay Wang <jawang@cosinecom.com>
cc: "'Ram Krishnan'" <ram@axiowave.com>,
        "'Kireeti Kompella'" <kireeti@juniper.net>, david.charlap@marconi.com,
        mpls@UU.NET
Subject: RE: Fw: MPLS and CAC
In-Reply-To: <7EB7C6B62C4FD41196A80090279A29112D94F1@exchsrv1.cosinecom.com>
Message-ID: <Pine.SOL.3.93.1000830164728.17527D-100000@tick.ece.utexas.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

At least for the current ATM PNNI, the traffic descriptor is very limited
and we can not expect an accurate capture of traffic statitics. In that
case, traffic/queue modeling, and thus derived algorithms like additive
effective bandwidth or its improved versions, can hardly exploit much
multiplexing gain.

Therefore online traffic measurement plus basic
assumption that traffic has certain correlation with the immediate history
may be a good choice. Unfortunately there are a lot of other issues
with traffic measurement.

I agree that overbooking factor should be policy-based and
sparsely controlled/tuned by network operator, while the CAC algorithm can
be relatively conservatively for Golden Custormers. Anyway the leftover
bandwidth can be used for services of less constraint QoS.

Any comment or opinion?

Sincerely,

Aimin
****************************************************************
                Aimin Sang, Ph.D Candidate
                Telecommunication Networks
                ENS 106, ECE Department
                Univ. of Texas at Austin
		
                Mailing/Home Address: 
                1515 Rio Grand Dr., Apt. 723, Plano, TX 75075
		
                Fax:   (214)-291-2280 
                Phone: (972)-943-3285 (Home)
                       (214)-291-2375 (Office)
                URL:   http://www.ece.utexas.edu/~sang

"You can never be too rich, too thin, or have too much bandwidth"
*****************************************************************

On Wed, 30 Aug 2000, Jay Wang wrote:

> Well, "Gold" when used as an adjective is a relative term.
> But in any case, no, an accurate characterization of customer
> traffic does not lead to a conclusion that tells you whether you 
> can overbook your "Gold" customer or not.  This is primary a 
> SLA and policy issue.  One way of the other, accurate customer
> traffic profiling only gives you the ability to execute your SLA 
> more precisely and possibly more efficiently by, for example,
> taking advantage of multiplexing gain.
> 
> regards,
> 
> - Jay  
> 
> 
> > -----Original Message-----
> > From: Ram Krishnan [mailto:ram@axiowave.com]
> > Sent: Wednesday, August 30, 2000 2:02 PM
> > To: 'Kireeti Kompella'; david.charlap@marconi.com; mpls@UU.NET
> > Subject: RE: Fw: MPLS and CAC
> > 
> > 
> > Even with Gold customers, you can do this as long as you
> > can characterise the traffic profiles of your Gold customers
> > carefully and provision parameters such as effective bandwidth
> > and buffer space accurately.
> > 
> > Regards,
> > Ram
> > 
> > 
> > While we are on the subject of overbooking, let me point out two
> > things:
> >    a) it makes sense to traffic engineer best effort IP traffic,
> >       and assign it a bandwidth parameter (a point that I believe
> >       Curtis mentioned, but I'm speaking from memory);
> >    b) persistent overbooking is fairly common.
> > (a) is a common reason for (b).
> > 
> > One scenario for (b) is where you have bursty traffic (happens a
> > lot with IP): say that some traffic trunk averages 40Mbps, but peaks
> > to 70Mbps.  You could put two of these on a 100Mbps link, and most
> > of the time, you are just fine.  If the two trunks peak at the same
> > time, you have some dropped traffic, but on the whole, you come out
> > ahead (modulo the SLAs with your customers).
> > 
> > You may not want to do this with your Gold customers, but for best
> > effort IP, this should work just fine.
> > 
> > Kireeti.
> > 
> 



From owner-mpls@UU.NET  Wed Aug 30 22:59:09 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16049
	for <mpls-archive@lists.ietf.org>; Wed, 30 Aug 2000 22:59:08 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjeoh05965;
	Thu, 31 Aug 2000 02:58:38 GMT
Received: by mail-control.mail.uu.net 
	id QQjeoh17051
	for mpls-outgoing; Thu, 31 Aug 2000 02:57:50 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjeoh17046
	for <mpls@mail-control.mail.uu.net>; Thu, 31 Aug 2000 02:57:50 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjeoh28245
	for <mpls@uu.net>; Wed, 30 Aug 2000 22:57:48 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQjeoh12577
	for <mpls@uu.net>; Thu, 31 Aug 2000 02:57:18 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id WAA04296
	for mpls@uu.net; Wed, 30 Aug 2000 22:57:17 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQjeoh17033
	for <mpls@mail-control.mail.uu.net>; Thu, 31 Aug 2000 02:57:07 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjeoh28189
	for <mpls@uu.net>; Wed, 30 Aug 2000 22:56:55 -0400 (EDT)
From: Spencer.Giacalone@predictive.com
Received: from athena.predictive.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: athena.predictive.com [208.209.197.197])
	id QQjeoh04977
	for <mpls@uu.net>; Thu, 31 Aug 2000 02:56:55 GMT
To: mpls@UU.NET
Cc: Joseph.Abban@predictive.com
Subject: control channel lambdas
X-Mailer: Lotus Notes Release 5.0.2c (Intl) 2 February 2000
Message-ID: <OFB1D5C97E.F876FD4E-ON8525694B.0081EA57@predictive.com>
Date: Wed, 30 Aug 2000 22:59:01 -0400
X-MIMETrack: Serialize by Router on Athena/Predictive(Release 5.0.4a |July 24, 2000) at
 08/30/2000 10:59:03 PM,
	Serialize complete at 08/30/2000 10:59:03 PM
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-mpls@UU.NET
Precedence: bulk

Can anyone point me in the direction of work that has been done to specify 
what lambdas controls channels should use?

Thanks, 

Spence



From owner-mpls@UU.NET  Wed Aug 30 23:49:05 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16913
	for <mpls-archive@lists.ietf.org>; Wed, 30 Aug 2000 23:49:05 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjeol09907;
	Thu, 31 Aug 2000 03:47:25 GMT
Received: by mail-control.mail.uu.net 
	id QQjeol01949
	for mpls-outgoing; Thu, 31 Aug 2000 03:47:05 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjeol01943
	for <mpls@mail-control.mail.uu.net>; Thu, 31 Aug 2000 03:46:56 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQjeol27259;
	Wed, 30 Aug 2000 23:46:46 -0400 (EDT)
Received: from maplenetworks.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: w082.z216112072.sjc-ca.dsl.cnc.net [216.112.72.82])
	id QQjeol07687;
	Thu, 31 Aug 2000 03:46:15 GMT
Received: from prasuncomp (farhad_pc [192.168.10.239])
	by maplenetworks.com (8.9.3+Sun/8.9.3/jcm Maplenetworks hub 1.4) with SMTP id UAA05563;
	Wed, 30 Aug 2000 20:42:31 -0700 (PDT)
Message-ID: <037001c02a90$f2c30c20$ef0aa8c0@maplenetworks.com>
From: "Sudhanshu Jain" <sjain@maplenetworks.com>
To: "Cheenu Srinivasan" <csrinivasan@tachion.com>, <mpls@UU.NET>,
        <te-wg@UU.NET>
References: <A64EB7AC0201D411B864009027DC856C054DC9@TNNT3>
Subject: Re: Consensus for draft-kompella-mpls-te-mib-00.txt
Date: Fri, 29 Sep 2000 20:44:59 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_036D_01C02A56.2226DC20"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_036D_01C02A56.2226DC20
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Consensus for draft-kompella-mpls-te-mib-00.txtHi All,

Please see my inline comments below.

  ----- Original Message -----=20
  From: Cheenu Srinivasan=20
  To: 'mpls@UU.NET' ; 'te-wg@UU.NET'=20
  Sent: Wednesday, August 30, 2000 1:06 PM
  Subject: Consensus for draft-kompella-mpls-te-mib-00.txt


  MPLS/TE WG members,=20

          This message is in response to the recent introduction=20
  of the draft entitled, "draft-kompella-mpls-te-mib-00.txt" to=20
  the TE WG and the debate which followed. Since no consensus could=20
  be reached in the TE WG as to whether or not to adopt this draft,=20
  the TE WG chair felt that this work was still important, and as such=20
  has directed the author of this draft and the authors of the=20
  MPLS-TE-MIB to work out a consensus for folding-in the salient=20
  portions of the draft into the MPLS-TE-MIB. We have done so, and=20
  below you will find the fruits of our labor. We will wait for the=20
  feedback of the working groups before posting a revised version of=20
  MPLS-TE-MIB incorporating these changes.=20

          Tom Nadeau=20
          Kireeti Kompella=20
          Cheenu Srinivasan=20
          Arun Vishwanathan=20

  =
-------------------------------------------------------------------------=
--------------=20

          1. Two scalars to indicate the number of configured and=20
             active tunnels: mplsConfiguredTunnels and =
mplsActiveTunnels. An=20
             "active" tunnel denotes an mplsTunnelEntry with=20
             mplsTunnelOperStatus =3D Up. A "configured" tunnel denotes =
an=20
             mplsTunnelEntry whose mplsTunnelRowStatus is "active".=20

An unrelataed comment. If you look, there are potenially three oper =
status ( in rfc2233(ifOperStatus), mplsTunnelOperStatus and =
mplsXcOperStatus), which may be representing the same information.

I think,  mplsTunnelOperStatus is not really required as there is a =
direct index to the mplsXcTable and it has the mplsXcOperStatus.

Any comments??


          2. The addition of a new performance table which AUGMENTS=20
             the mpslTunnelTable which includes the following=20
             attributes:=20

          mplsTunnelPerfPackets OBJECT-TYPE=20
          SYNTAX     Counter32=20
                                    =20
          mplsTunnelHCPerfPackets OBJECT-TYPE=20
          SYNTAX     Counter64=20
                                    =20
          mplsTunnelErrors OBJECT-TYPE=20
          SYNTAX  Counter32=20

          mplsTunnelPerfBytes OBJECT-TYPE=20
          SYNTAX     Counter32=20
                                    =20
          mplsTunnelHCPerfBytes OBJECT-TYPE=20
          SYNTAX     Counter64=20


I think these type of parameters are specific for the Packet Switch =
Capable(PSC) Interfaces and should be addressed accordingly.
                               =20


          3. The following objects will be added to the tunnelTable=20
             to allow for further monitoring of the state=20
             of the tunnel once it is configured.=20

                  mplsTunnelPrimaryTimeUp    TimeStamp,=20
                  mplsTunnelPathChanges      Counter32,=20
                  mplsTunnelLastPathChange   TimeStamp,=20
                  mplsTunnelCreationTime     TimeStamp,=20
                  mplsTunnelStateTransitions Unsigned32,=20
                  mplsTunnelEgressLSRId      Unsigned32,=20

How does the egress lsr id is learned in RSVP-TE? Also what is the usage =
of this information?

I think scope of mplsTunnelStateTransitions , should be increased to =
address notPresent, lowerLayerDown etc.



          A path change is when the current active path (over which=20
          packets are being forwarded) changes to another path.=20


I think path change(mplsTunnelLastPathChange &  mplsTunnelPathChanges) =
is protection specific information, and should be addresses in seprate =
mplsTunnelTable's augumented table along with information like=20

- current protection available

Also mplsTunnelTable's should have configurable information like "kind =
of protection" required for this Tunnel along with pre existing =
information "localProtectionAvailable".


-Sudhanshu

------=_NextPart_000_036D_01C02A56.2226DC20
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Consensus for =
draft-kompella-mpls-te-mib-00.txt</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4134.600" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi All,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Please see my inline comments =
below.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=3Dcsrinivasan@tachion.com =
href=3D"mailto:csrinivasan@tachion.com">Cheenu=20
  Srinivasan</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A title=3Dmpls@UU.NET=20
  href=3D"mailto:'mpls@UU.NET'">'mpls@UU.NET'</A> ; <A =
title=3Dte-wg@UU.NET=20
  href=3D"mailto:'te-wg@UU.NET'">'te-wg@UU.NET'</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Wednesday, August 30, =
2000 1:06=20
  PM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Consensus for=20
  draft-kompella-mpls-te-mib-00.txt</DIV>
  <DIV><FONT face=3DArial size=3D2></FONT><FONT face=3DArial =
size=3D2></FONT><FONT=20
  face=3DArial size=3D2></FONT><FONT face=3DArial =
size=3D2></FONT><BR></DIV>
  <P><FONT size=3D2>MPLS/TE WG members,</FONT> </P>
  <P><FONT size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This =
message is in=20
  response to the recent introduction</FONT> <BR><FONT size=3D2>of the =
draft=20
  entitled, "draft-kompella-mpls-te-mib-00.txt" to</FONT> <BR><FONT =
size=3D2>the=20
  TE WG and the debate which followed. Since no consensus could =
</FONT><BR><FONT=20
  size=3D2>be reached in the TE WG as to whether or not to adopt this =
draft,=20
  </FONT><BR><FONT size=3D2>the TE WG chair felt that this work was =
still=20
  important, and as such </FONT><BR><FONT size=3D2>has directed the =
author of this=20
  draft and the authors of the</FONT> <BR><FONT size=3D2>MPLS-TE-MIB to =
work out a=20
  consensus for folding-in the salient </FONT><BR><FONT =
size=3D2>portions of the=20
  draft into the MPLS-TE-MIB. We have done so, and</FONT> <BR><FONT =
size=3D2>below=20
  you will find the fruits of our labor. We will wait for the</FONT> =
<BR><FONT=20
  size=3D2>feedback of the working groups before posting a revised =
version=20
  of</FONT> <BR><FONT size=3D2>MPLS-TE-MIB incorporating these =
changes.</FONT>=20
</P>
  <P><FONT size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tom =
Nadeau</FONT>=20
  <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Kireeti=20
  Kompella</FONT> <BR><FONT =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  Cheenu Srinivasan</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Arun =
Vishwanathan</FONT>=20
</P>
  <P><FONT=20
  =
size=3D2>----------------------------------------------------------------=
-----------------------</FONT>=20
  </P>
  <P><FONT size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1. Two =
scalars to=20
  indicate the number of configured and </FONT><BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
active=20
  tunnels: mplsConfiguredTunnels and mplsActiveTunnels. An</FONT> =
<BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
"active"=20
  tunnel denotes an mplsTunnelEntry with</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  mplsTunnelOperStatus =3D Up. A "configured" tunnel denotes an</FONT> =
<BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  mplsTunnelEntry whose mplsTunnelRowStatus is "active". =
</FONT></P></BLOCKQUOTE>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>An unrelataed comment. If you =
look, there=20
are potenially three oper status ( in rfc2233(ifOperStatus),=20
mplsTunnelOperStatus and mplsXcOperStatus), which may be representing =
the same=20
information.</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>I=20
think,&nbsp;&nbsp;mplsTunnelOperStatus&nbsp;is not really required as =
there is a=20
direct index to the mplsXcTable and it has the =
mplsXcOperStatus.</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Any comments??</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <P><FONT size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2. The =
addition of=20
  a new performance table which AUGMENTS</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
the=20
  mpslTunnelTable which includes the following</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  attributes:</FONT> </P>
  <P><FONT size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  mplsTunnelPerfPackets OBJECT-TYPE </FONT><BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  SYNTAX&nbsp;&nbsp;&nbsp;&nbsp; Counter32</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </FONT><BR><FONT size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  mplsTunnelHCPerfPackets OBJECT-TYPE </FONT><BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  SYNTAX&nbsp;&nbsp;&nbsp;&nbsp; Counter64</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </FONT><BR><FONT size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  mplsTunnelErrors OBJECT-TYPE</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SYNTAX&nbsp;=20
  Counter32</FONT> </P>
  <P><FONT size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
mplsTunnelPerfBytes=20
  OBJECT-TYPE </FONT><BR><FONT =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  SYNTAX&nbsp;&nbsp;&nbsp;&nbsp; Counter32</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </FONT><BR><FONT size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  mplsTunnelHCPerfBytes OBJECT-TYPE </FONT><BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  SYNTAX&nbsp;&nbsp;&nbsp;&nbsp; Counter64</FONT>&nbsp;<BR><FONT=20
  size=3D2></FONT></P></BLOCKQUOTE>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>I think these type of =
parameters are=20
specific for the Packet Switch Capable(PSC) Interfaces and should be =
addressed=20
accordingly.</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <P><FONT face=3DArial size=3D2></FONT><FONT face=3DArial =
size=3D2></FONT><FONT=20
  face=3DArial size=3D2></FONT><FONT face=3DArial size=3D2></FONT><FONT =
face=3DArial=20
  size=3D2></FONT><FONT face=3DArial size=3D2></FONT><FONT face=3DArial=20
  size=3D2></FONT><FONT face=3DArial size=3D2></FONT><FONT face=3DArial=20
  size=3D2></FONT><FONT face=3DArial size=3D2></FONT><BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3. The following =
objects=20
  will be added to the tunnelTable</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
to allow=20
  for further monitoring of the state</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
of the=20
  tunnel once it is configured.</FONT> </P>
  <P><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  mplsTunnelPrimaryTimeUp&nbsp;&nbsp;&nbsp; TimeStamp,</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  mplsTunnelPathChanges&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Counter32,</FONT>=20
  <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  mplsTunnelLastPathChange&nbsp;&nbsp; TimeStamp,</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  mplsTunnelCreationTime&nbsp;&nbsp;&nbsp;&nbsp; TimeStamp,</FONT> =
<BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  mplsTunnelStateTransitions Unsigned32,</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  mplsTunnelEgressLSRId&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Unsigned32,</FONT> =

</P></BLOCKQUOTE>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>How does the egress lsr id is =
learned in=20
RSVP-TE? Also what is the usage of this information?</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>I think scope of=20
mplsTunnelStateTransitions&nbsp;, should be increased to address =
notPresent,=20
lowerLayerDown etc.</FONT></DIV>
<DIV dir=3Dltr><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <P><FONT size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; A path =
change is=20
  when the current active path (over which </FONT><BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; packets are being =
forwarded)=20
  changes to another path. </FONT></P></BLOCKQUOTE>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>I think path change(<FONT=20
face=3D"Times New Roman">mplsTunnelLastPathChange =
&amp;&nbsp;</FONT>&nbsp;<FONT=20
face=3D"Times New Roman">mplsTunnelPathChanges) </FONT>is protection =
specific=20
information, and should be addresses in seprate mplsTunnelTable's =
augumented=20
table&nbsp;along with information like </FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>- current protection =
available</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Also mplsTunnelTable's should =
have=20
configurable information like "kind of protection" required=20
for&nbsp;this&nbsp;Tunnel along with pre existing information=20
"localProtectionAvailable".</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT size=3D2>-Sudhanshu</FONT></DIV></BODY></HTML>

------=_NextPart_000_036D_01C02A56.2226DC20--



From owner-mpls@UU.NET  Thu Aug 31 04:25:48 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01626
	for <mpls-archive@lists.ietf.org>; Thu, 31 Aug 2000 04:25:48 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQjepd22358;
	Thu, 31 Aug 2000 08:24:48 GMT
Received: by mail-control.mail.uu.net 
	id QQjepd16398
	for mpls-outgoing; Thu, 31 Aug 2000 08:24:26 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQjepd16383
	for <mpls@mail-control.mail.uu.net>; Thu, 31 Aug 2000 08:24:18 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQjepd25983
	for <mpls@UU.NET>; Thu, 31 Aug 2000 04:24:14 -0400 (EDT)
Received: from neptune.telecomm.tadiran.co.il by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: tadiran.co.il [194.90.248.2])
	id QQjepd21966
	for <mpls@UU.NET>; Thu, 31 Aug 2000 08:24:10 GMT
Received: from oranus.ecitele.com (oranus [10.115.11.180])
	by neptune.telecomm.tadiran.co.il (8.9.3/8.9.3) with ESMTP id KAA13024
	for <mpls@UU.NET>; Thu, 31 Aug 2000 10:19:54 +0200 (IST)
Received: by oranus.ecitele.com with Internet Mail Service (5.5.2650.21)
	id <RY83QKBP>; Thu, 31 Aug 2000 11:20:53 +0300
Message-ID: <A09DA710F4E2D311A69300508B8BBAA608DFB9@oranus.ecitele.com>
From: Porotsky Sergey <Sergey.Porotsky@ecitele.com>
To: "'mpls@UU.NET'" <mpls@UU.NET>
Subject: LSP bandwidth
Date: Thu, 31 Aug 2000 11:20:49 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Dear All. I have a question regarding "LSP bandwidth". On some MPLS drafts
(e.g., "draft-compella-lsp-hierarchy-00.txt, p.4",
"draft-chang-mpls-path-protection-00.txt, p.9") used this notion, but what
have we to mean for it? Really LSP can have many primary traffic parameters
(PDR, PBS, CDR, etc.). On the other hand, secondary LSP bandwidth parameter
(effective bandwidth, which is result of LSR CAC calculations)  may differ
from one LSR to another LSR, isn't it? 
Thanks beforehand, Sergey.




