Liaison Reply regarding L1VPNs

[Kireeti Kompella <[e-mail]>]

 To:          Mr. Marco Carugi, Rapporteur for Question 11 of ITU-T Study Group 13.
 From:        Adrian Farrel and Kireeti Kompella
                 Co-chairs of the CCAMP Working Group of the IETF
 Cc:          Alex Zinin and Bill Fenner, Routing Area Directors of the IETF
 For:         Information
 Deadline:    None
 Subject:     Reply to Liaison Statement on L1VPNs

Dear Mr. Carugi,

Thank you for your liaison statement COM13-LS23 dated 3-12 February
2004 on the subject of Layer One VPNs and related work within Study
Group 13.

Thanks also to the members of Study Group 13 Question 11 for their
work on draft-takeda-l1vpn-framework-00.txt which represents so clearly
the motivations for L1VPNs, the high level (service level) requirements,
and the architectural models that might be used to build L1VPNs.

Members of the CCAMP working group have expressed a considerable
interest in this work and we are keen to pursue a working relationship
with SG13 to advance the description of the functional requirements,
assess current protocols for suitability, and develop any protocol
extensions that may be necessary.

Some feedback on draft-takeda-l1vpn-framework-00.txt has already been
made on the CCAMP mailing list and we know that the authors of the
draft are aware of the comments.  Hopefully this is valuable input and
will be taken back for discussion in Q.11 where appropriate.

In order to further facilitate the discussion of L1VPN within the
IETF, we have started a new mailing list designated for L1VPN emails
only.  In keeping with all IETF mailing lists, this list is open to
all and we would welcome active participation from SG13 delegates and
attendees, and from anyone else who can contribute in this area.

We anticipate that initial discussions will focus on
draft-takeda-l1vpn-framework-00.txt, but that we will move on to an
analysis of the short-comings of existing IETF protocols in the
delivery of L1VPNs.

To join the mailing list please visit
https://www1.ietf.org/mailman/listinfo/l1vpn.  The mailing list will
also be archived and can be read on the Web at
ftp://ftp.ietf.org/ietf-mail-archive/l1vpn/

Sincerely,
Kireeti Kompella & Adrian Farrel, CCAMP WG chairs




Envelope-to: [e-mail]
Delivery-date: Mon, 28 Jun 2004 09:56:57 +0000
Date: Mon, 28 Jun 2004 02:53:34 -0700 (PDT)
From: Kireeti Kompella <[e-mail]>
To: Marco Carugi <[e-mail]>
cc: Adrian Farrel <[e-mail]>, Bill Fenner <[e-mail]>, Kireeti Kompella <[e-mail]>, Alex Zinin <[e-mail]>, [e-mail], IESG Secretary <[e-mail]>
Subject: Liaison Reply regarding L1VPNs
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

 To:          Mr. Marco Carugi, Rapporteur for Question 11 of ITU-T Study Group 13.
 From:        Adrian Farrel and Kireeti Kompella
                 Co-chairs of the CCAMP Working Group of the IETF
 Cc:          Alex Zinin and Bill Fenner, Routing Area Directors of the IETF
 For:         Information
 Deadline:    None
 Subject:     Reply to Liaison Statement on L1VPNs

Dear Mr. Carugi,

Thank you for your liaison statement COM13-LS23 dated 3-12 February
2004 on the subject of Layer One VPNs and related work within Study
Group 13.

Thanks also to the members of Study Group 13 Question 11 for their
work on draft-takeda-l1vpn-framework-00.txt which represents so clearly
the motivations for L1VPNs, the high level (service level) requirements,
and the architectural models that might be used to build L1VPNs.

Members of the CCAMP working group have expressed a considerable
interest in this work and we are keen to pursue a working relationship
with SG13 to advance the description of the functional requirements,
assess current protocols for suitability, and develop any protocol
extensions that may be necessary.

Some feedback on draft-takeda-l1vpn-framework-00.txt has already been
made on the CCAMP mailing list and we know that the authors of the
draft are aware of the comments.  Hopefully this is valuable input and
will be taken back for discussion in Q.11 where appropriate.

In order to further facilitate the discussion of L1VPN within the
IETF, we have started a new mailing list designated for L1VPN emails
only.  In keeping with all IETF mailing lists, this list is open to
all and we would welcome active participation from SG13 delegates and
attendees, and from anyone else who can contribute in this area.

We anticipate that initial discussions will focus on
draft-takeda-l1vpn-framework-00.txt, but that we will move on to an
analysis of the short-comings of existing IETF protocols in the
delivery of L1VPNs.

To join the mailing list please visit
https://www1.ietf.org/mailman/listinfo/l1vpn.  The mailing list will
also be archived and can be read on the Web at
ftp://ftp.ietf.org/ietf-mail-archive/l1vpn/

Sincerely,
Kireeti Kompella & Adrian Farrel, CCAMP WG chairs



Envelope-to: [e-mail]
Delivery-date: Fri, 25 Jun 2004 19:07:10 +0000
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Path Computation Element (PCE) BOF
Date: Fri, 25 Jun 2004 14:01:23 -0500
Message-ID: <[e-mail]>
Thread-Topic: Path Computation Element (PCE) BOF
Thread-Index: AcRUr0dzmSxeTiQ0RZy92QvHx5wFMwGNiQng
From: "Ash, Gerald R \(Jerry\), ALABS" <[e-mail]>
To: <[e-mail]>, "[e-mail]" <[e-mail]>, <[e-mail]>, <[e-mail]>, "TEWG" <[e-mail]>
Cc: "Ash, Gerald R \(Jerry\), ALABS" <[e-mail]>, "Jean Philippe Vasseur" <[e-mail]>, "Adrian Farrel" <[e-mail]>

All,

Please review and comment on "Path Computation Element (PCE) Problem
Statement"
http://www.ietf.org/internet-drafts/draft-ash-pce-problem-statement-00.t
xt.  The PCE is an approach to MPLS traffic engineering that is
applicable to inter-area and inter-AS path computation.  A problem
statement and overview of solution alternatives is provided.  This will
be discussed during the PCE BOF outlined below.

Thanks,
Jerry=20

________________________________

From: [e-mail] [mailto:[e-mail]] On
Behalf Of Adrian Farrel
Sent: Thursday, June 17, 2004 5:01 PM
To: [e-mail]; '[e-mail]'; [e-mail];
[e-mail]; TEWG
Cc: 'Jean Philippe Vasseur'
Subject: Path Computation Element (PCE) BOF

Hi,
=20
We will be holding a BOF in San Diego under the care of the Routing
Area.
=20
Please see the description, a draft agenda, and proposed charter below.
=20
We'd welcome any thoughts for additions to the agenda, and any pointers
to existing drafts that you consider already fit within this scope.
=20
If you have views for or against, please bring them to the BOF where we
will hopefully have time to air them fully.
=20
Thanks,
Adrian and JP
=20
=3D=3D=3D=3D
Path Computation Element BOF (PCE BOF) Agenda
60th IETF, San Diego, August 2004
=20
Routing Area Ads: Alex Zinin ([e-mail] <mailto:[e-mail]> ),
                  Bill Fenner ([e-mail]
<mailto:[e-mail]> )

BOF Chairs: JP Vasseur ([e-mail] <mailto:[e-mail]>
),
            Adrian Farrel ([e-mail]
<mailto:[e-mail]> )

Description:
In certain MPLS TE networks it may be beneficial or desirable to have
path=20
computation performed by a distinct node (termed the Path Computation=20
Element  PCE) that is not the LSR that needs to know the path. This BOF=20
examines the scope of such function, what extensions to existing
protocols=20
might required, what additional protocols may need to be developed, and=20
whether there is cuase and support for this work within the IETF.

---

Proposed BOF agenda
1) Introduction, admin, statement of objectives of the BOF (10 minutes)
2) Overview of PCE-based LSP Path computation (10 minutes)
         - terminology
         - dichotomy (centralized versus distributed, statefull versus=20
           stateless, ...)
3) Requirements for PCE-based path computation (5 minutes)
         - for intra-area TE LSP (packet and non packet LSP, multiple=20
           criteria optimization techniques, online/offline)
         - for inter-area and inter-AS TE (shared information or=20
           collaborative computation)
4) Functional requirements of a PCE-based path computation system  (10
minutes)
         - Framework,
         - Path computation model
         - discovery of PCEs within a network
         - distribution of TE information to PCEs
         - LSR-PCE communication
         - Monitoring and Management (MIBs)
         - Policy/Security/Confidentiality in the context of
inter-providers
5) Current status of drafts and early implementations (10 minutes)
6) Why should this be IETF work? (5 minutes)
         - CCAMP or new Working Group?
         - Is this work limited to MPLS-TE? What about BGP route
servers?
7) Proposed charter (see below) (10 minutes)
8) Open discussion (50 minutes)
9) Summary and conclusions (10 minutes)

---

Proposed WG Charter
=20
Organizational Overview
The PCE working group coordinates the work within the IETF of defining
the=20
operation of path computation elements within the Internet. Path=20
computation elements are responsible for computing paths through IP=20
networks for uses such as traffic engineering so that a prime consumer
of=20
such paths might be an MPLS-TE LSR. Areas of responsibility will include

the collection of attributes relevant to the computation of paths, the=20
discovery by LSRs of available path computation elements, the
communication=20
with LSRs for the request of path computation, the collaboration between

path computation elements within the network, and analysis of path=20
computation algorithms with a view to ensuring consistency between
computed=20
paths. The working group will work closely with many working groups in
the=20
Routing Area including the OSPF, IS-IS, IDR, MPLS and CCAMP working
groups.

Working Group Scope
The PCE working group scope includes:
- Definition  of Generalized Traffic Engineered LSP paths computation=20
  techniques involving Path Computation Element(s). This includes the
intra=20
  IGP area, inter IGP area, inter-AS and inter-provider TE LSPs path=20
  computation for Point-to-Point, Point-to-Multipoint and=20
  Multipoint-to-Multipoint TE LSPs.
- Definition of protocol-independent metrics and constraints defining
path=20
  quality measurement criteria, algorithm complexity and scalability
criteria=20
  related to path computation techniques.
- Definition of requirements for communication between LSRs and PCEs=20
  including routing extensions in support of PCE discovery techniques
within=20
  an IGP area and across multiple IGP areas, ASes and Provider networks,
and=20
  including the development of new protocols or protocol extensions for=20
  requesting path computation and supplying responses. Any protocol=20
  extensions will developed in conjunction with the working groups in
charge=20
  of the specific protocols.
- Specification of routing (OSPF, ISIS, BGP) and signalling extensions=20
  (RSVP-TE) required by PCE-based path computation techniques. The
extensions=20
  will developed in conjunction with the working groups in charge of the

  specific protocols.
- Specification of requirements and protocol extensions related to the=20
  policy, security and confidentiality aspects of PCE-based path
computation=20
  techniques involving PCEs of multiple Providers.
- Definition of MIBs, management procedures related to the protocol=20
  extensions defined by the WG

In doing this work, the WG will closely work with at least the following

other WGs: CCAMP, MPLS, ISIS, OSPF, IDR. The WG will also cooperate with

the ITU-T and OIF.

Goals and Milestones

Dates for milestones to be decided later.

  Post strawman WG goals and charter.

  Submit WG document defining the framework and applicability of the=20
  PCE model.

  Select a single candidate protocol from communication between LSRs=20
  and PCEs.

  Submit document(s) that define various path computation models
=20
  Submit an analysis document examining the requirements for coherent
  computation techniques and the implication of cooperation between=20
  PCEs.

  Submit a document defining the protocol for communication between=20
  LSRs and PCEs.

  Submit document(s) defining extensions to routing and signalling=20
  protocols necessary to support the use of a PCE model within MPLS
  networks.
=20
  Submit a document defining MIB modules for modeling and management=20
  of PCE systems.



Envelope-to: [e-mail]
Delivery-date: Fri, 18 Jun 2004 13:51:39 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE : RE : RE : Last call comments: draft-ietf-tewg-interarea-mpls-te-req-01.txt
Date: Fri, 18 Jun 2004 15:49:56 +0200
Message-ID: <[e-mail]>
Thread-Topic: RE : RE : Last call comments: draft-ietf-tewg-interarea-mpls-te-req-01.txt
Thread-Index: AcRUsvnEEbrw4KzmSCq9BYYZr/FXeQAgLJSA
From: "LE ROUX Jean-Louis FTRD/DAC/LAN" <[e-mail]>
To: "Arthi Ayyangar" <[e-mail]>
Cc: <[e-mail]>, "TE" <[e-mail]>, "CCAMP" <[e-mail]>

Hi Arthi

Please see inline

Regards,

JL

>> >As I explained in my email to JP, it is still somewhat=20
>unclear as to=20
>> >what the ability to signal the desired method buys the=20
>provider, and=20
>> >exactly why or how that simplifies LSP management.
>>
>> Basically, as mentionned by JP, the signaling method used=20
>will have a=20
>> non negligeable impact on important features (Reoptimization, FRR,=20
>> rerouting). For instance, if you use sitching or nesting, you will=20
>> face FRR issues as regards ABR protection.
>----------> Let me try to explain this, if possible with a couple of
>examples:
>Re-optimization
>---------------
>Actually, nothing prevents you from having Head-end Control of=20
>re-optimzation even with the non-contiguous signaling methods.=20
>It is just that with the non-contiguous signaling methods, one=20
>can, if desired, also have the ability to do a local=20
>re-optimization. But if you do not want this 'intermediate=20
>re-optimization' behavior for certain LSPs, you may want to=20
>signal that explicitly or configure it on the box.

Agree

>
>Crankback/Re-routing
>---------------------
>The crankback document actually provides a similar ability for=20
>controlling re-routing at intermediate nodes by signaling this=20
>explicitly.

Agree,

And what about FRR: if I want FRR protection of ABRs with no impact on
backup length and recovery delay, I definitely need contiguous LSPs.
This is actually the only signaling mode allowing this service. Thus I
prefer to signal directly the signaling mode "Contiguous LSP", rather
than the required service, in order to avoid any misinterpretation of
this service ...






Envelope-to: [e-mail]
Delivery-date: Fri, 18 Jun 2004 12:23:45 +0000
Message-ID: <025801c45513$a02b0510$d4849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Fw: Response to OIF communication of June 4th
Date: Fri, 18 Jun 2004 09:14:21 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Response from Steve Joiner...
----- Original Message ----- 
From: "Steve Joiner" <[e-mail]>
To: "'Adrian Farrel'" <[e-mail]>
Cc: "'Kireeti Kompella'" <[e-mail]>; <[e-mail]>; "'Bill Fenner'"
<[e-mail]>; "'Kimberly Chiu'" <[e-mail]>; <[e-mail]>;
"'Jim Jones'" <[e-mail]>; <[e-mail]>
Sent: Thursday, June 17, 2004 9:49 PM
Subject: RE: Response to OIF communication of June 4th


Adrian,

I received your communication and will forward it to our membership.  It
will be reviewed at our next meeting in late July.

We look forward to continued open communication.

Let me know when you are ready to pursue more formal relationship
between the two bodies.

-steve
OIF TC Chair

-----Original Message-----
From: Adrian Farrel [mailto:[e-mail]]
Sent: Thursday, June 17, 2004 12:42 PM
To: Steve Joiner
Cc: 'Kireeti Kompella'; Adrian Farrel; [e-mail]; Bill Fenner;
Kimberly Chiu; [e-mail]; Jim Jones; [e-mail]
Subject: Response to OIF communication of June 4th


To        OIF, Technical Committee Chair, Steve Joiner,
<mailto:[e-mail]> [e-mail]
Cc         <mailto:[e-mail]> [e-mail]
             <mailto:[e-mail]> [e-mail]
            A. Zinin, B. Fenner (IETF Routing ADs)
            K. Kompella, A. Farrel (CCAMP WG chairs)
            CCAMP WG

Dear Mr. Joiner,

Thank you for your response of June 4th, it is good to have opened
up some communication channels between the OIF and CCAMP. We will
investigate what is necessary to establish a more formal
relationship between the two bodies.

We are happy to note the importance that you put on the feedback
process from the OIF to the IETF with respect to GMPLS
standardisation, and in view of this we are pleased to inform the
OIF that IETF CCAMP WG has initiated a Design Team on GMPLS ASON
Routing Solutions.  The GMPLS ASON Routing Solutions Design Team's
Charter is as below. Initially the output will be in the form of
IETF drafts. We will send you the output of the DT over the next
months.

Sincerely,
Kireeti Kompella & Adrian Farrel, CCAMP WG chairs

=====

ASON Routing Solutions Design Team
----------------------------------

Members (alphabetical order):

       Chris Hopps < <mailto:[e-mail]> [e-mail]>
       Lyndon Ong < <mailto:[e-mail]> [e-mail]>
       Dimitri Papadimitriou < <mailto:[e-mail]>
[e-mail]>
       Jonathan Sadler < <mailto:[e-mail]>
[e-mail]>
       Stephen Shew < <mailto:[e-mail]>
[e-mail]>
       Dave Ward < <mailto:[e-mail]> [e-mail]>

Charter:
-------
To evaluate existing IETF routing protocols against the ASON routing
requirements that were documented in
<draft-ietf-ccamp-gmpls-ason-routing-reqts> as a joint effort of the
IETF CCAMP Working Group and ITU-T SG15.

This evaluation is to be produced by a close examination of
applicability scenarios.  The result of the evaluation of these
scenarios is an integral part of the output of this design team.

The design team will then move on to the design of extensions to
the IETF routing protocols as appropriate in close collaboration
with the corresponding Working Groups (such as the OSPF, IS-IS and
IDR working groups).

Consideration should also be given to the exclusion of protocol
elements or procedures that are not appropriate or relevant in
the ASON routing scenarios that the team describes.

Finally, the design team is responsible for drafting liaison
statements from the CCAMP WG to the ITU-T SG15 and OIF regarding
GMPLS ASON routing solutions, as well as for drafting replies to
liaisons received from the ITU-T SG15 and OIF.  Note that no
Liaisons drafted by the design team will be sent or replied to
without approval from the CCAMP WG chairs, ADs and rough
consensus of the CCAMP WG.

Standard design team disclaimer: this design team has no special
status in the CCAMP WG.  Any documents they produce are subject to
the usual WG procedures.  Individuals are encouraged to interact
with the design team, to offer suggestions, review the output and,
if they feel so inclined, to submit their own drafts.

Milestones (all on the 15th of the month):
----------

Jun '04: send Liaison to ITU-T SG15 and OIF stating creation of DT
         and charter
Jul '04: first draft of "Evaluation of existing IETF routing
         protocols against ASON routing requirements including
         evaluation scenarios"
Aug '04: first CCAMP WG document of "Evaluation of existing IETF
         routing protocols against ASON routing requirements
         including evaluation scenarios"
Aug '04: send Liaison to ITU-T SG15 and OIF soliciting input on
         above WG document
Sep '04: first drafts of protocol-specific "Protocol extensions and
         usage procedures for ASON"
Oct '04: first CCAMP WG protocol-specific documents on "Protocol
         extensions and usage procedures for ASON"
Oct '04: send Liaison to ITU-T SG15 and OIF soliciting input on above
         WG documents
Dec '04: CCAMP WG Last Call (including appropriate Routing WG Last
         Call)
Jan '05: hand off documents to IESG

Interactions with other WGs:
------------------------------
The design team is expected to interact with other IETF working groups
as appropriate.  Protocol extensions are not to be developed without
full consultation with the "owning" working group.  That is, while the
protocol extensions are developed within CCAMP, they must be presented
to and discussed with the owning working group which must be given the
opportunity to comment and suggest alternate solutions.  This may
include the IS-IS, OSPF and IDR working groups.

Relevant meetings:
------------------
It is suggested that the design team take full advantage of the
following meetings to advance their discussions face-to-face.  The
team may wish to hold "open" meetings on these occasions to solicit
wider input.

60th IETF San Diego, California, August 1st-6th 2004
ITU-T SG15 Inter-regnum meeting on ASON routing, Berlin, Germany,
   November 1st-5th 2004
61st IETF Washington, DC, November 7th-12th 2004






Envelope-to: [e-mail]
Delivery-date: Thu, 17 Jun 2004 21:30:23 +0000
Date: Thu, 17 Jun 2004 14:28:14 -0700 (PDT)
From: Arthi Ayyangar <[e-mail]>
To: LE ROUX Jean-Louis FTRD/DAC/LAN <[e-mail]>
cc: [e-mail], TE <[e-mail]>, CCAMP <[e-mail]>
Subject: Re: RE : RE : Last call comments: draft-ietf-tewg-interarea-mpls-te-req-01.txt
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi JL,

Some comments inline.

<snipped>
> ><snip>
> >
> >As I explained in my email to JP, it is still somewhat unclear
> >as to what the ability to signal the desired method buys the
> >provider, and exactly why or how that simplifies LSP management.
>
> Basically, as mentionned by JP, the signaling method used will have a
> non negligeable impact on important features (Reoptimization, FRR,
> rerouting). For instance, if you use sitching or nesting, you will face
> FRR issues as regards ABR protection.
----------> Let me try to explain this, if possible with a couple of
examples:
Re-optimization
---------------
Actually, nothing prevents you from having Head-end Control of
re-optimzation even with the non-contiguous signaling methods. It is just
that with the non-contiguous signaling methods, one can, if desired, also
have the ability to do a local re-optimization. But if you do not want
this 'intermediate re-optimization' behavior for certain LSPs, you may
want to signal that explicitly or configure it on the box.

Crankback/Re-routing
---------------------
The crankback document actually provides a similar ability for
controlling re-routing at intermediate nodes by signaling this
explicitly.

So, I think that it is basically upto the solutions documents to
address these functionalities. In fact, Dimitri had a very good
example of how by restricting the 'signaling method' you could
shoot down one set of benefits for the other.

thanks,
-arthi

> I agree that we could just signal the function/service
>  "FRR protection of ABRs", "Head-end Control of reoptimization"...
> This would clearly require the "contiguous" signaling mode

> IMHO, this is simpler to directly signal the signaling mode. I don't
> really see any interop issue here. Basically if an ABR does not support
> the signaling mode, it simply rejects the LSP setup.
>
>
> >
> >
> >> Let's have a look at the FRR draft: There are two modes defined, and
> >> the desired mode (one-to-one or bypass) is signaled on a
> >per-LSP basis
> >> (within the FRR object). I did not see any objection on that.
> >
> >I think the FRR draft is really a solutions draft, and it
> >presents two solutions which offer somewhat different
> >services, in my view. The detour provides the ability to
> >protect segments of a _given_ LSP, while the bypass tunnel
> >provides the ability to simultaneously protect _multiple_ LSPs
> >sharing a given resource (node(s) or link).
> >
> >Also, as Adrian mentioned, it has lead to interop issues.
>
> FRR interop issues was IMHO not related to this flag in the FRR object.
>
>
> >
> >> >
> >> >8. Sec. 7.3 on path optimality talks only of the optimality of a
> >> >single path computed in isolation. What is the definition of
> >> >optimality to be applied for computing diverse paths? (Sec.
> >7.7 later
> >> >does not specifically discuss this aspect either.) If one used CSPF
> >> >in sequence to compute two diverse paths (as this section would
> >> >imply) then the computation may fail, even though a set of optimal
> >> >diverse paths exists (as acknowledged in Sec. 7.7 ahead).
> >>
> >> Agree, we should add a definition of optimality to be applied when
> >> computing diverse path This maybe: A placement of two
> >diverse paths is
> >> optimal if their cumulative cost is minimal.
> >
> >Yes, this is one definition. I think in  some previous email
> >exchanges, Fabio had provided a good definition of optimality
> >for diverse path routing. (I'll try to dig it up in the
> >archives, and post a note separately on it.)
>
> Thanks
>
> >
> >
> >> >9. Sec. 7.4 "Inter-area MPLS TE Routing" I would like to underscore
> >> >Adrian's point on specifying the scaling requirements themselves
> >> >(with respect to areas, amount of flooded info. etc.)
> >rather than the
> >> >realization of those requirements (by not adding any info. to the
> >> >LSAs, for example).
> >>
> >>
> >> It seems that you are OK with 5.3 (no comments)
> >> "Containment of routing information MUST not be compromised to allow
> >> inter-area traffic
> >>    engineering. Information propagation for path-selection
> >MUST continue
> >>    to be localized.".
> >> Thus you should also be OK with 7.4
> >
> >Actually, 5.3 imposes a requirement to preserve IGP hierarchy
> >and scalability, but at least leaves open the possibility for
> >the IGP to carry extra information as long as it is not an
> >"unreasonable amount of extra information" that does not
> >"unreasonably increase IGP flooding frequency".
>
> Basically 5.3 points out that information propagation for PATH-SELECTION
> MUST continue to be localized.
> It also means that we allow for the IGP to carry extra information provided that it is NOT topology related...
>
> >
> >I thought 7.4 should probably provide some specifics on what
> >unreasonable is, and leave it to the protocol designers to
> >devise protocols that keep within those limits. Instead it
> >seems to prescribe a realization -- one where no topology
> >related info. of any sort should be added to the IGP LSAs.
> >
> >> Basically we want to preserve IGP hierachy concept, are there
> >> objections to that point ?
> >
> >Depends on whether you want to preserve it in spirit or to the
> >letter :-). I think it may be useful to give protocol
> >designers some wiggle room.
>
> IMHO it is also useful to tell protocol designers what we don't want in our networks...
>
> >
> >> This means, for ISPs contributing to this draft, "no leaking of any
> >> topology related info accross areas". Of course, this does not
> >> preclude the addition of info to the LSA, provided that it is not
> >> topology related.
> >>
> >> >
> >> >If solutions can meet the scaling requirements by adding a bit of
> >> >info. to the IGP, I think this should be allowed, otherwise
> >there is
> >> >really not much that could be achieved using current mechanisms
> >> >(since no modifications to them seem permissible, and we already
> >> >established that these, as they exist, do not provide for adequate
> >> >inter-area MPLS TE).
> >> >
> >> >BTW, one of the points made in this regard in these
> >> >email thread was about the use of path computation servers,
> >which can
> >> >supposedly compute optimal paths without any impact on the IGP.
> >> >
> >> >I think this argument isn't quite complete, since it hides the
> >> >signaling extensions required for these as well as the scalability
> >> >impact of recursive PCE-type schemes (btw, this was a question that
> >> >came up in independent discussions with JP in the context
> >of the ARO
> >> >and PCE schemes, and is still under discussion).
> >>
> >> Let's continue this discussion in another thread addressing solutions
> >
> >Ok, sure.
> >
> >
> >> >10. Sec. 7.6, the figure O(N^2) makes the assumption that
> >each of the
> >> >N ARBs at the border of the neighboring areas is connected to each
> >> >other ABR. No? In reality, the number of crankback's may be
> >> >significantly less therefore.
> >>
> >> No, basically if you have X1 ABRs in head-end area and X2 ABRs in
> >> tail-end area you may have up to X1*X2 crankbacks, provided
> >that there
> >> is a path between all ABRs. This does not assume direct connectivity
> >> between ABRs.
> >
> >
> >Ok, thanks. I see now what you are saying.
> >
> >> >11. Sec. 7.7, I guess it would be useful to qualify what is
> >> >considered "extra-load" in signaling and routing here. Is
> >that to be
> >> >interpreted as _absolutely no change_ to current signaling and
> >> >routing protocol objects?
> >>
> >> No, this should not be interpreted as "absolutely no change".
> >> Basically the solution must respect scalability requirements
> >spelt out
> >> in 5.2 Will clarify in next revision.
> >>
> >>
> >> >seem feasible, if inter-area routing/TE is to be achieved, so
> >> >something more specific is implied, which would be good to
> >spell out.
> >> >
> >> >BTW, also tend to agree with Adrian's point that this section seems
> >> >to be describing the computation of diverse paths rather than the
> >> >establishment of diverse paths, which would seem to be the
> >> >requirement.
> >>
> >> Yes this is basically a requirement on computation, but in this
> >> inter-domain context Path computation and Path establishment are no
> >> longer necessarily independant (see your ARO proposal)
> >>
> >>
> >> >
> >> >12. Sec. 7.9, what is meant by "inter-area head end LSR"?
> >> >An LSR that is the head-end of an inter-area LSP (that is, an LSP
> >> >traversing multiple areas)?
> >>
> >> Yes, will reword
> >>
> >> >
> >> >13. Sec. 8.2, not sure that is providing a real measurable
> >evaluation
> >> >criterion. If it is to be kept, some specifics should probably be
> >> >given.
> >
> >JL, sure. The perf. requirements are given in Sec. 8.1, but I
> >was looking at Sec. 8.2.
>
> OK, in 8.2 the criteria is more qualitative than quantitative
>
> >
> >Also, even for 8.1, it may be good to add the = to explanation
> >for (1) and (2) that you've given below.
>
> OK
>
> >
> >> IMHO what we list is clearly measurable
> >>    (1) Optimality of the computed inter-area TE LSP path.
> >> = Computed cost - Shortest cost
> >>    (2) Optimality of the computed backup tunnel path
> >protecting against
> >>        the failure of an ABR, capability to share bandwidth
> >among backup
> >>        tunnels protecting independent facilities
> >> = Total backup bandwidth consumption
> >>    (3) Inter-area TE LSP set up time.
> >>  = clearly measurable
> >>    (4) RSVP-TE and IGP scalability (state impact, number of messages,
> >>        message size)
> >>  = Memory footprint increase, CPU load increase, Message size
> >> Increase...This is also definitely measurable.
> >>
>
> >
>
> Thanks again for these comments. We will post, on Monday, a new revision incorporating received comments.
>
> Regards,
>
> JL
>
>



Envelope-to: [e-mail]
Delivery-date: Thu, 17 Jun 2004 21:07:56 +0000
Message-ID: <01e201c454ae$f7966d90$d4849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>, "'[e-mail]'" <[e-mail]>, <[e-mail]>, <[e-mail]>, "TEWG" <[e-mail]>
Cc: "'Jean Philippe Vasseur'" <[e-mail]>
Subject: Path Computation Element (PCE) BOF
Date: Thu, 17 Jun 2004 22:01:25 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_01D7_01C454B6.A251D6F0"

This is a multi-part message in MIME format.

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

Hi,

We will be holding a BOF in San Diego under the care of the Routing =
Area.

Please see the description, a draft agenda, and proposed charter below.

We'd welcome any thoughts for additions to the agenda, and any pointers =
to existing drafts that you consider already fit within this scope.

If you have views for or against, please bring them to the BOF where we =
will hopefully have time to air them fully.

Thanks,
Adrian and JP

=3D=3D=3D=3D
 Path Computation Element BOF (PCE BOF) Agenda
60th IETF, San Diego, August 2004
=20
 Routing Area Ads: Alex Zinin ([e-mail]),
                  Bill Fenner ([e-mail])

BOF Chairs: JP Vasseur ([e-mail]),
            Adrian Farrel ([e-mail])

Description:
In certain MPLS TE networks it may be beneficial or desirable to have =
path=20
computation performed by a distinct node (termed the Path Computation=20
Element  PCE) that is not the LSR that needs to know the path. This BOF=20
examines the scope of such function, what extensions to existing =
protocols=20
might required, what additional protocols may need to be developed, and=20
whether there is cuase and support for this work within the IETF.

---
=20
Proposed BOF agenda
1) Introduction, admin, statement of objectives of the BOF (10 minutes)
2) Overview of PCE-based LSP Path computation (10 minutes)
         - terminology
         - dichotomy (centralized versus distributed, statefull versus=20
           stateless, ...)
3) Requirements for PCE-based path computation (5 minutes)
         - for intra-area TE LSP (packet and non packet LSP, multiple=20
           criteria optimization techniques, online/offline)
         - for inter-area and inter-AS TE (shared information or=20
           collaborative computation)
4) Functional requirements of a PCE-based path computation system  (10 =
minutes)
         - Framework,
         - Path computation model
         - discovery of PCEs within a network
         - distribution of TE information to PCEs
         - LSR-PCE communication
         - Monitoring and Management (MIBs)
         - Policy/Security/Confidentiality in the context of =
inter-providers
5) Current status of drafts and early implementations (10 minutes)
6) Why should this be IETF work? (5 minutes)
         - CCAMP or new Working Group?
         - Is this work limited to MPLS-TE? What about BGP route =
servers?
7) Proposed charter (see below) (10 minutes)
8) Open discussion (50 minutes)
9) Summary and conclusions (10 minutes)

---
=20
Proposed WG Charter
=20
Organizational Overview
The PCE working group coordinates the work within the IETF of defining =
the=20
 operation of path computation elements within the Internet. Path=20
computation elements are responsible for computing paths through IP=20
networks for uses such as traffic engineering so that a prime consumer =
of=20
such paths might be an MPLS-TE LSR. Areas of responsibility will include =

the collection of attributes relevant to the computation of paths, the=20
discovery by LSRs of available path computation elements, the =
communication=20
with LSRs for the request of path computation, the collaboration between =

path computation elements within the network, and analysis of path=20
computation algorithms with a view to ensuring consistency between =
computed=20
paths. The working group will work closely with many working groups in =
the=20
Routing Area including the OSPF, IS-IS, IDR, MPLS and CCAMP working =
groups.

Working Group Scope
The PCE working group scope includes:
- Definition  of Generalized Traffic Engineered LSP paths computation=20
  techniques involving Path Computation Element(s). This includes the =
intra=20
  IGP area, inter IGP area, inter-AS and inter-provider TE LSPs path=20
  computation for Point-to-Point, Point-to-Multipoint and=20
  Multipoint-to-Multipoint TE LSPs.
- Definition of protocol-independent metrics and constraints defining =
path=20
  quality measurement criteria, algorithm complexity and scalability =
criteria=20
  related to path computation techniques.
- Definition of requirements for communication between LSRs and PCEs=20
  including routing extensions in support of PCE discovery techniques =
within=20
  an IGP area and across multiple IGP areas, ASes and Provider networks, =
and=20
  including the development of new protocols or protocol extensions for=20
  requesting path computation and supplying responses. Any protocol=20
  extensions will developed in conjunction with the working groups in =
charge=20
  of the specific protocols.
- Specification of routing (OSPF, ISIS, BGP) and signalling extensions=20
  (RSVP-TE) required by PCE-based path computation techniques. The =
extensions=20
  will developed in conjunction with the working groups in charge of the =

  specific protocols.
- Specification of requirements and protocol extensions related to the=20
  policy, security and confidentiality aspects of PCE-based path =
computation=20
  techniques involving PCEs of multiple Providers.
- Definition of MIBs, management procedures related to the protocol=20
  extensions defined by the WG

In doing this work, the WG will closely work with at least the following =

other WGs: CCAMP, MPLS, ISIS, OSPF, IDR. The WG will also cooperate with =

the ITU-T and OIF.

Goals and Milestones

Dates for milestones to be decided later.

  Post strawman WG goals and charter.

  Submit WG document defining the framework and applicability of the=20
  PCE model.

  Select a single candidate protocol from communication between LSRs=20
  and PCEs.

  Submit document(s) that define various path computation models
=20
  Submit an analysis document examining the requirements for coherent
  computation techniques and the implication of cooperation between=20
  PCEs.

  Submit a document defining the protocol for communication between=20
  LSRs and PCEs.

  Submit document(s) defining extensions to routing and signalling=20
  protocols necessary to support the use of a PCE model within MPLS
  networks.
=20
  Submit a document defining MIB modules for modeling and management=20
  of PCE systems.

------=_NextPart_000_01D7_01C454B6.A251D6F0
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 6.00.2800.1170" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DCourier size=3D2>Hi,</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>We will be holding a BOF in San Diego =
under the=20
care of the Routing Area.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Please see the description, a draft =
agenda, and=20
proposed charter below.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>We'd welcome any thoughts for =
additions to the=20
agenda, and any pointers to existing drafts that you consider already =
fit within=20
this scope.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>If you have views for or against, =
please bring=20
them to the BOF where we will hopefully have time to air them=20
fully.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Thanks,</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Adrian and JP</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2> Path Computation Element BOF (PCE =
BOF)=20
Agenda<BR>60th IETF, San Diego, August 2004<BR>&nbsp;<BR> Routing Area =
Ads: Alex=20
Zinin (</FONT><A href=3D"mailto:[e-mail]"><FONT face=3DCourier=20
size=3D2>[e-mail]</FONT></A><FONT face=3DCourier =
size=3D2>),</FONT></DIV>
<DIV><FONT face=3DCourier=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&nbsp;Bill Fenner&nbsp;(</FONT><A =
href=3D"mailto:[e-mail]"><FONT=20
face=3DCourier size=3D2>[e-mail]</FONT></A><FONT =
face=3DCourier=20
size=3D2>)<BR><BR>BOF Chairs: JP Vasseur (</FONT><A=20
href=3D"mailto:[e-mail]"><FONT face=3DCourier=20
size=3D2>[e-mail]</FONT></A><FONT face=3DCourier =
size=3D2>),</FONT></DIV>
<DIV><FONT face=3DCourier=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;Adrian=20
Farrel&nbsp;(</FONT><A href=3D"mailto:[e-mail]"><FONT =
face=3DCourier=20
size=3D2>[e-mail]</FONT></A><FONT face=3DCourier=20
size=3D2>)<BR><BR>Description:<BR>In certain MPLS TE networks it may be =
beneficial=20
or desirable to have path&nbsp;<BR>computation performed by a distinct =
node=20
(termed the Path Computation&nbsp;<BR>Element&nbsp; PCE) that is not the =
LSR=20
that needs to know the path. This BOF&nbsp;<BR>examines the scope of =
such=20
function, what extensions to existing protocols&nbsp;<BR>might required, =
what=20
additional protocols may need to be developed, and&nbsp;<BR>whether =
there is=20
cuase and support for this work within the IETF.<BR></FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>---</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;<BR>Proposed BOF agenda<BR>1) =
Introduction,=20
admin, statement of objectives of the BOF (10 minutes)<BR>2) Overview of =

PCE-based LSP Path computation (10=20
minutes)<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -=20
terminology<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - =
dichotomy=20
(centralized versus distributed, statefull=20
versus&nbsp;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;stateless,=20
...)<BR>3) Requirements for PCE-based path computation (5=20
minutes)<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - for =
intra-area TE=20
LSP (packet and non packet LSP,=20
multiple&nbsp;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;criteria=20
optimization techniques,=20
online/offline)<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - =
for=20
inter-area and inter-AS TE (shared information=20
or&nbsp;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&nbsp;collaborative computation)<BR>4) Functional requirements of a =
PCE-based=20
path computation system&nbsp; (10=20
minutes)<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -=20
Framework,<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Path=20
computation model<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -=20
discovery of PCEs within a=20
network<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - =
distribution of TE=20
information to PCEs<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
-=20
LSR-PCE =
communication<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -=20
Monitoring and Management=20
(MIBs)<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -=20
Policy/Security/Confidentiality in the context of inter-providers<BR>5) =
Current=20
status of drafts and early implementations (10 minutes)<BR>6) Why should =
this be=20
IETF work? (5 =
minutes)<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -=20
CCAMP or new Working =
Group?<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
- Is this work limited to MPLS-TE? What about BGP route servers?<BR>7) =
Proposed=20
charter (see below) (10 minutes)<BR>8) Open discussion (50 =
minutes)<BR>9)=20
Summary and conclusions (10 minutes)<BR></DIV></FONT>
<DIV><FONT face=3DCourier size=3D2>---</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;<BR>Proposed WG=20
Charter<BR>&nbsp;<BR>Organizational Overview<BR>The PCE working group=20
coordinates the work within the IETF of defining the&nbsp;<BR> operation =
of path=20
computation elements within the Internet. Path&nbsp;<BR>computation =
elements are=20
responsible for computing paths through IP&nbsp;<BR>networks for uses =
such as=20
traffic engineering so that a prime consumer of&nbsp;<BR>such paths =
might be an=20
MPLS-TE LSR. Areas of responsibility will include&nbsp;<BR>the =
collection of=20
attributes relevant to the computation of paths, the&nbsp;<BR>discovery =
by LSRs=20
of available path computation elements, the communication&nbsp;<BR>with =
LSRs for=20
the request of path computation, the collaboration between&nbsp;<BR>path =

computation elements within the network, and analysis of=20
path&nbsp;<BR>computation algorithms with a view to ensuring consistency =
between=20
computed&nbsp;<BR>paths. The working group will work closely with many =
working=20
groups in the&nbsp;<BR>Routing Area including the OSPF, IS-IS, IDR, MPLS =
and=20
CCAMP working groups.<BR><BR>Working Group Scope<BR>The PCE working =
group scope=20
includes:<BR>- Definition&nbsp; of Generalized Traffic Engineered LSP =
paths=20
computation&nbsp;<BR>&nbsp; techniques involving Path Computation =
Element(s).=20
This includes the intra&nbsp;<BR>&nbsp; IGP area, inter IGP area, =
inter-AS and=20
inter-provider TE LSPs path&nbsp;<BR>&nbsp; computation for =
Point-to-Point,=20
Point-to-Multipoint and&nbsp;<BR>&nbsp; Multipoint-to-Multipoint TE =
LSPs.<BR>-=20
Definition of protocol-independent metrics and constraints defining=20
path&nbsp;<BR>&nbsp; quality measurement criteria, algorithm complexity =
and=20
scalability criteria&nbsp;<BR>&nbsp; related to path computation=20
techniques.<BR>- Definition of requirements for communication between =
LSRs and=20
PCEs&nbsp;<BR>&nbsp; including routing extensions in support of PCE =
discovery=20
techniques within&nbsp;<BR>&nbsp; an IGP area and across multiple IGP =
areas,=20
ASes and Provider networks, and&nbsp;<BR>&nbsp; including the =
development of new=20
protocols or protocol extensions for&nbsp;<BR>&nbsp; requesting path =
computation=20
and supplying responses. Any protocol&nbsp;<BR>&nbsp; extensions will =
developed=20
in conjunction with the working groups in charge <BR>&nbsp; of the =
specific=20
protocols.<BR>- Specification of routing (OSPF, ISIS, BGP) and =
signalling=20
extensions&nbsp;<BR>&nbsp; (RSVP-TE) required by PCE-based path =
computation=20
techniques. The extensions <BR>&nbsp; will developed in conjunction with =
the=20
working groups in charge of the <BR>&nbsp; specific protocols.<BR>-=20
Specification of requirements and protocol extensions related to=20
the&nbsp;<BR>&nbsp; policy, security and confidentiality aspects of =
PCE-based=20
path computation <BR>&nbsp; techniques involving PCEs of multiple=20
Providers.<BR>- Definition of MIBs, management procedures related to the =

protocol&nbsp;<BR>&nbsp; extensions defined by the WG<BR><BR>In doing =
this work,=20
the WG will closely work with at least the following&nbsp;<BR>other WGs: =
CCAMP,=20
MPLS, ISIS, OSPF, IDR. The WG will also cooperate with&nbsp;<BR>the=20
ITU-T&nbsp;and OIF.<BR><BR>Goals and Milestones<BR><BR>Dates for =
milestones to=20
be decided later.<BR><BR>&nbsp; Post strawman WG goals and=20
charter.<BR><BR>&nbsp; Submit WG document defining the framework and=20
applicability of the&nbsp;<BR>&nbsp; PCE&nbsp;model.<BR><BR>&nbsp; =
Select a=20
single candidate protocol from communication between =
LSRs&nbsp;<BR>&nbsp; and=20
PCEs.<BR><BR>&nbsp; Submit document(s) that define various path =
computation=20
models<BR>&nbsp;<BR>&nbsp; Submit an analysis document examining the=20
requirements for coherent<BR>&nbsp; computation techniques and the =
implication=20
of cooperation between&nbsp;<BR>&nbsp; PCEs.<BR><BR>&nbsp; Submit a =
document=20
defining the protocol for communication between&nbsp;<BR>&nbsp; LSRs=20
and&nbsp;PCEs.<BR><BR>&nbsp; Submit document(s) defining extensions to =
routing=20
and signalling&nbsp;<BR>&nbsp; protocols&nbsp;necessary to support the =
use of a=20
PCE model within MPLS</FONT></DIV>
<DIV><FONT face=3DCourier =
size=3D2>&nbsp;&nbsp;networks.<BR>&nbsp;<BR>&nbsp; Submit=20
a document defining MIB modules for modeling and =
management&nbsp;<BR>&nbsp; of=20
PCE systems.<BR></DIV></FONT></BODY></HTML>

------=_NextPart_000_01D7_01C454B6.A251D6F0--




Envelope-to: [e-mail]
Delivery-date: Thu, 17 Jun 2004 19:46:33 +0000
Message-ID: <01bb01c454a3$99c2f630$d4849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Steve Joiner" <[e-mail]>
Cc: "'Kireeti Kompella'" <[e-mail]>, "Adrian Farrel" <[e-mail]>, <[e-mail]>, "Bill Fenner" <[e-mail]>, "Kimberly Chiu" <[e-mail]>, <[e-mail]>, "Jim Jones" <[e-mail]>, <[e-mail]>
Subject: Response to OIF communication of June 4th
Date: Thu, 17 Jun 2004 20:41:44 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_01B6_01C454AB.803E8BE0"

This is a multi-part message in MIME format.

------=_NextPart_000_01B6_01C454AB.803E8BE0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

To        OIF, Technical Committee Chair, Steve Joiner, =
[e-mail]
Cc        [e-mail]
            [e-mail]
            A. Zinin, B. Fenner (IETF Routing ADs)
            K. Kompella, A. Farrel (CCAMP WG chairs)
            CCAMP WG

Dear Mr. Joiner,

Thank you for your response of June 4th, it is good to have opened
up some communication channels between the OIF and CCAMP. We will
investigate what is necessary to establish a more formal
relationship between the two bodies.

We are happy to note the importance that you put on the feedback
process from the OIF to the IETF with respect to GMPLS
standardisation, and in view of this we are pleased to inform the
OIF that IETF CCAMP WG has initiated a Design Team on GMPLS ASON
Routing Solutions.  The GMPLS ASON Routing Solutions Design Team's
Charter is as below. Initially the output will be in the form of
IETF drafts. We will send you the output of the DT over the next
months.

Sincerely,
Kireeti Kompella & Adrian Farrel, CCAMP WG chairs

=3D=3D=3D=3D=3D

ASON Routing Solutions Design Team
----------------------------------

Members (alphabetical order):

       Chris Hopps <[e-mail]>
       Lyndon Ong <[e-mail]>
       Dimitri Papadimitriou <[e-mail]>
       Jonathan Sadler <[e-mail]>
       Stephen Shew <[e-mail]>
       Dave Ward <[e-mail]>

Charter:
-------
To evaluate existing IETF routing protocols against the ASON routing
requirements that were documented in
<draft-ietf-ccamp-gmpls-ason-routing-reqts> as a joint effort of the
IETF CCAMP Working Group and ITU-T SG15.

This evaluation is to be produced by a close examination of
applicability scenarios.  The result of the evaluation of these
scenarios is an integral part of the output of this design team.

The design team will then move on to the design of extensions to
the IETF routing protocols as appropriate in close collaboration
with the corresponding Working Groups (such as the OSPF, IS-IS and
IDR working groups).

Consideration should also be given to the exclusion of protocol
elements or procedures that are not appropriate or relevant in
the ASON routing scenarios that the team describes.

Finally, the design team is responsible for drafting liaison
statements from the CCAMP WG to the ITU-T SG15 and OIF regarding
GMPLS ASON routing solutions, as well as for drafting replies to
liaisons received from the ITU-T SG15 and OIF.  Note that no=20
Liaisons drafted by the design team will be sent or replied to
without approval from the CCAMP WG chairs, ADs and rough=20
consensus of the CCAMP WG.

Standard design team disclaimer: this design team has no special
status in the CCAMP WG.  Any documents they produce are subject to
the usual WG procedures.  Individuals are encouraged to interact
with the design team, to offer suggestions, review the output and,
if they feel so inclined, to submit their own drafts.

Milestones (all on the 15th of the month):
----------

Jun '04: send Liaison to ITU-T SG15 and OIF stating creation of DT
         and charter
Jul '04: first draft of "Evaluation of existing IETF routing=20
         protocols against ASON routing requirements including=20
         evaluation scenarios"
Aug '04: first CCAMP WG document of "Evaluation of existing IETF
         routing protocols against ASON routing requirements=20
         including evaluation scenarios"
Aug '04: send Liaison to ITU-T SG15 and OIF soliciting input on=20
         above WG document
Sep '04: first drafts of protocol-specific "Protocol extensions and
         usage procedures for ASON"
Oct '04: first CCAMP WG protocol-specific documents on "Protocol
         extensions and usage procedures for ASON"
Oct '04: send Liaison to ITU-T SG15 and OIF soliciting input on above
         WG documents
Dec '04: CCAMP WG Last Call (including appropriate Routing WG Last=20
         Call)
Jan '05: hand off documents to IESG

Interactions with other WGs:
------------------------------
The design team is expected to interact with other IETF working groups
as appropriate.  Protocol extensions are not to be developed without
full consultation with the "owning" working group.  That is, while the
protocol extensions are developed within CCAMP, they must be presented
to and discussed with the owning working group which must be given the
opportunity to comment and suggest alternate solutions.  This may
include the IS-IS, OSPF and IDR working groups.

Relevant meetings:
------------------
It is suggested that the design team take full advantage of the
following meetings to advance their discussions face-to-face.  The
team may wish to hold "open" meetings on these occasions to solicit
wider input.

60th IETF San Diego, California, August 1st-6th 2004
ITU-T SG15 Inter-regnum meeting on ASON routing, Berlin, Germany,
   November 1st-5th 2004
61st IETF Washington, DC, November 7th-12th 2004


------=_NextPart_000_01B6_01C454AB.803E8BE0
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 6.00.2800.1170" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DCourier =
size=3D2>To&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; OIF,=20
Technical Committee Chair, Steve Joiner, </FONT><A=20
href=3D"mailto:[e-mail]"><FONT face=3DCourier=20
size=3D2>[e-mail]</FONT></A><BR><FONT face=3DCourier=20
size=3D2>Cc&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT><A=20
href=3D"mailto:[e-mail]"><FONT face=3DCourier=20
size=3D2>[e-mail]</FONT></A><BR><FONT face=3DCourier=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
</FONT><A href=3D"mailto:[e-mail]"><FONT face=3DCourier=20
size=3D2>[e-mail]</FONT></A><BR><FONT face=3DCourier =
size=3D2>&nbsp;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; A. Zinin, B. =
Fenner (IETF=20
Routing=20
ADs)<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; K.=20
Kompella, A. Farrel (CCAMP WG=20
chairs)<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;=20
CCAMP WG<BR><BR>Dear Mr. Joiner,<BR><BR>Thank you for your response of =
June 4th,=20
it is good to have opened<BR>up some communication channels between the =
OIF and=20
CCAMP. We will<BR>investigate what is necessary to establish a more=20
formal</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>relationship&nbsp;</FONT><FONT =
face=3DCourier=20
size=3D2>between the two bodies.<BR><BR>We are happy to note the =
importance that=20
you put on the feedback<BR>process from the OIF to the IETF with respect =
to=20
GMPLS<BR>standardisation, and in view of this we are pleased to inform=20
the<BR>OIF that IETF CCAMP WG has initiated a Design Team on GMPLS=20
ASON<BR>Routing Solutions.&nbsp; The GMPLS ASON Routing Solutions Design =

Team's<BR>Charter is as below.&nbsp;Initially the output will be in the =
form=20
of</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>IETF drafts. We will send you the =
output of=20
the&nbsp;DT over the next</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>months.<BR></FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Sincerely,<BR>Kireeti Kompella &amp; =
Adrian=20
Farrel, CCAMP WG chairs<BR><BR>=3D=3D=3D=3D=3D<BR></FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>ASON Routing Solutions Design=20
Team<BR>----------------------------------<BR></FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Members (alphabetical=20
order):<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Chris Hopps =
&lt;</FONT><A=20
href=3D"mailto:[e-mail]"><FONT face=3DCourier=20
size=3D2>[e-mail]</FONT></A><FONT face=3DCourier=20
size=3D2>&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Lyndon Ong =
&lt;</FONT><A=20
href=3D"mailto:[e-mail]"><FONT face=3DCourier=20
size=3D2>[e-mail]</FONT></A><FONT face=3DCourier=20
size=3D2>&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Dimitri =
Papadimitriou=20
&lt;</FONT><A href=3D"mailto:[e-mail]"><FONT =
face=3DCourier=20
size=3D2>[e-mail]</FONT></A><FONT face=3DCourier =

size=3D2>&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Jonathan Sadler=20
&lt;</FONT><A href=3D"mailto:[e-mail]"><FONT =
face=3DCourier=20
size=3D2>[e-mail]</FONT></A><FONT face=3DCourier=20
size=3D2>&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Stephen Shew =
&lt;</FONT><A=20
href=3D"mailto:[e-mail]"><FONT face=3DCourier=20
size=3D2>[e-mail]</FONT></A><FONT face=3DCourier=20
size=3D2>&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Dave Ward =
&lt;</FONT><A=20
href=3D"mailto:[e-mail]"><FONT face=3DCourier=20
size=3D2>[e-mail]</FONT></A><FONT face=3DCourier=20
size=3D2>&gt;<BR><BR>Charter:<BR>-------<BR>To evaluate existing IETF =
routing=20
protocols against the ASON routing<BR>requirements that were documented=20
in<BR>&lt;draft-ietf-ccamp-gmpls-ason-routing-reqts&gt; as a joint =
effort of=20
the<BR>IETF CCAMP Working Group and ITU-T SG15.<BR></FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>This evaluation is to be produced by =
a close=20
examination of<BR>applicability scenarios.&nbsp; The result of the =
evaluation of=20
these<BR>scenarios is an integral part of the output of this design=20
team.<BR><BR>The design team will then move on to the design of =
extensions=20
to<BR>the IETF routing protocols as appropriate in close =
collaboration<BR>with=20
the corresponding Working Groups (such as the OSPF, IS-IS and<BR>IDR =
working=20
groups).<BR><BR>Consideration should also be given to the exclusion of=20
protocol<BR>elements or procedures that are not appropriate or relevant=20
in<BR>the ASON routing scenarios that the team =
describes.<BR><BR>Finally, the=20
design team is responsible for drafting liaison<BR>statements from the =
CCAMP WG=20
to the ITU-T SG15 and OIF regarding<BR>GMPLS ASON routing solutions, as =
well as=20
for drafting replies to<BR>liaisons received from the ITU-T SG15 and =
OIF.&nbsp;=20
Note that no </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Liaisons drafted by the design team =
will be sent=20
or replied to</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>without approval from the CCAMP WG =
chairs, ADs=20
and rough </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>consensus of the CCAMP =
WG.<BR><BR>Standard design=20
team disclaimer: this design team has no special<BR>status in the CCAMP=20
WG.&nbsp; Any documents they produce are subject to<BR>the usual WG=20
procedures.&nbsp; Individuals are encouraged to interact<BR>with the =
design=20
team, to offer suggestions, review the output and,<BR>if they feel so =
inclined,=20
to submit their own drafts.<BR><BR>Milestones (all on the 15th of the=20
month):<BR>----------<BR><BR>Jun '04: send Liaison to ITU-T SG15 and OIF =
stating=20
creation of DT<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; and=20
charter<BR>Jul '04: first draft of "Evaluation of existing IETF routing=20
</FONT></DIV>
<DIV><FONT face=3DCourier =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
protocols&nbsp;against ASON routing requirements including </FONT></DIV>
<DIV><FONT face=3DCourier =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
evaluation&nbsp;scenarios"<BR>Aug '04: first CCAMP WG document of =
"Evaluation of=20
existing IETF<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
routing=20
protocols against ASON routing requirements </FONT></DIV>
<DIV><FONT face=3DCourier =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
including evaluation scenarios"<BR>Aug '04: send Liaison to ITU-T SG15 =
and OIF=20
soliciting input on </FONT></DIV>
<DIV><FONT face=3DCourier =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
above&nbsp;WG document<BR>Sep '04: first drafts of protocol-specific =
"Protocol=20
extensions and</FONT></DIV>
<DIV><FONT face=3DCourier =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&nbsp;usage procedures for ASON"<BR>Oct '04: first CCAMP WG =
protocol-specific=20
documents on =
"Protocol<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
extensions and usage procedures for ASON"<BR>Oct '04: send Liaison to =
ITU-T SG15=20
and OIF soliciting input on=20
above<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; WG =
documents<BR>Dec=20
'04: CCAMP WG Last Call (including appropriate Routing WG Last =
</FONT></DIV>
<DIV><FONT face=3DCourier=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Call)<BR>J=
an '05:=20
hand off documents to IESG<BR><BR>Interactions with other=20
WGs:<BR>------------------------------<BR>The design team is expected to =

interact with other IETF working groups<BR>as appropriate.&nbsp; =
Protocol=20
extensions are not to be developed without<BR>full consultation with the =

"owning" working group.&nbsp; That is, while the<BR>protocol extensions =
are=20
developed within CCAMP, they must be presented<BR>to and discussed with =
the=20
owning working group which must be given the<BR>opportunity to comment =
and=20
suggest alternate solutions.&nbsp; This may<BR>include the IS-IS, OSPF =
and IDR=20
working groups.<BR><BR>Relevant meetings:<BR>------------------<BR>It is =

suggested that the design team take full advantage of the<BR>following =
meetings=20
to advance their discussions face-to-face.&nbsp; The<BR>team may wish to =
hold=20
"open" meetings on these occasions to solicit<BR>wider =
input.<BR><BR>60th IETF=20
San Diego, California, August 1st-6th 2004<BR>ITU-T SG15 Inter-regnum =
meeting on=20
ASON routing, Berlin, Germany,<BR>&nbsp;&nbsp; November 1st-5th =
2004<BR>61st=20
IETF Washington, DC, November 7th-12th =
2004<BR><BR></FONT></DIV></BODY></HTML>

------=_NextPart_000_01B6_01C454AB.803E8BE0--




Envelope-to: [e-mail]
Delivery-date: Thu, 17 Jun 2004 16:06:29 +0000
Reply-To: <[e-mail]>
From: "Vishal Sharma" <[e-mail]>
To: "Scott W Brim" <[e-mail]>, "dimitri papadimitriou" <[e-mail]>
Cc: "Adrian Farrel" <[e-mail]>, <[e-mail]>, "'Kireeti Kompella'" <[e-mail]>, <[e-mail]>, "Bill Fenner" <[e-mail]>
Subject: RE: Draft of a liaison to ITU-T Study Group 13 about L1VPN
Date: Thu, 17 Jun 2004 09:05:07 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Adrian,

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On
> Behalf Of Scott W Brim
> Sent: Wednesday, June 16, 2004 11:31 PM
> To: dimitri papadimitriou
> Cc: Adrian Farrel; [e-mail]; 'Kireeti Kompella';
> [e-mail]; Bill Fenner
> Subject: Re: Draft of a liaison to ITU-T Study Group 13 about L1VPN
> 
> 
> On Thu, Jun 17, 2004 12:50:50AM +0200, dimitri papadimitriou 
> allegedly wrote:
> > hi adrian, what do you mean by "to separate the work from the 
> noise that 
> > happens on the CCAMP mailing list" 
> 
> Right.  Adrian, just delete the first part of that sentence and start
> with "We have started a new mailing list".  
> 
> > and "In keeping with all IETF mailing 
> > lists,.."
> 
> I have no problem with this.
> 
> swb

Ditto.

-Vishal



Envelope-to: [e-mail]
Delivery-date: Thu, 17 Jun 2004 08:20:40 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE : RE : Last call comments: draft-ietf-tewg-interarea-mpls-te-req-01.txt
Date: Thu, 17 Jun 2004 10:19:35 +0200
Message-ID: <[e-mail]>
Thread-Topic: RE : Last call comments: draft-ietf-tewg-interarea-mpls-te-req-01.txt
Thread-Index: AcRQD29oIusza1tGS16JQ1U5Wp4UYQELSIZA
From: "LE ROUX Jean-Louis FTRD/DAC/LAN" <[e-mail]>
To: <[e-mail]>, "TE" <[e-mail]>, "CCAMP" <[e-mail]>

Hi Vishal

Sorry for this delayed answer

See some additionnal comments inline

Regards,

JL

>-----Message d'origine-----
>De : [e-mail]=20
>[mailto:[e-mail]] De la part de Vishal Sharma
>Envoy=E9 : vendredi 11 juin 2004 23:35
>=C0 : LE ROUX Jean-Louis FTRD/DAC/LAN; TE; CCAMP
>Objet : RE: RE : Last call comments:=20
>draft-ietf-tewg-interarea-mpls-te-req-01.txt
>
>
>Hi JL,
>
>Thanks for the clarifications. A few follow-up thoughts in-line.
>
>Regards,
>-Vishal
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]]On
>> Behalf Of LE ROUX Jean-Louis FTRD/DAC/LAN
>> Sent: Friday, June 11, 2004 9:30 AM
>> To: [e-mail]; TE; CCAMP
>> Subject: RE : Last call comments:=20
>> draft-ietf-tewg-interarea-mpls-te-req-01.txt
>>
>>
>> Hi Vishal,
>>
>> Thanks a lot for these highly useful comments.
>>
>> Please see inline for some answers.
>>
>> Regards,
>>
>> JL
>>
>
><snip>
>
>> >7. Sec. 7.2, I tend to agree with Adrian that (ideally) it=20
>would seem=20
>> >it should be enough for the head-end to signal the function/service=20
>> >it wants and not the underlying method used by nodes=20
>further in path=20
>> >to provide that service. If, as you mention, this is a requirement=20
>> >expressed by many SPs, it would be good to understand why it is so,=20
>> >and for the document to explain a bit about it.
>>
>> Actually I don't really understand the objection on that point. The=20
>> requirement seems clear for me. If there are several methods=20
>supported=20
>> in my network, I want to select the method on a per LSP=20
>basis in order=20
>> to have entire control on how the LSP is signaled. This will=20
>ease LSP=20
>> management. Basically there won't be hundreds of methods but=20
>just two=20
>> or three (contiguous, stiching, nesting..)
>> So it seems quite relevant to have the ability to signal the
>> desired method.
>
>As I explained in my email to JP, it is still somewhat unclear=20
>as to what the ability to signal the desired method buys the=20
>provider, and exactly why or how that simplifies LSP management.

Basically, as mentionned by JP, the signaling method used will have a =
non negligeable impact
on important features (Reoptimization, FRR, rerouting). For instance, if =
you use sitching or nesting, you will face FRR issues as regards ABR =
protection.

I agree that we could just signal the function/service
 "FRR protection of ABRs", "Head-end Control of reoptimization"...
This would clearly require the "contiguous" signaling mode

IMHO, this is simpler to directly signal the signaling mode.
I don't really see any interop issue here. Basically if an ABR does not =
support the signaling mode, it simply rejects the LSP setup.


>
>
>> Let's have a look at the FRR draft: There are two modes defined, and=20
>> the desired mode (one-to-one or bypass) is signaled on a=20
>per-LSP basis=20
>> (within the FRR object). I did not see any objection on that.
>
>I think the FRR draft is really a solutions draft, and it=20
>presents two solutions which offer somewhat different=20
>services, in my view. The detour provides the ability to=20
>protect segments of a _given_ LSP, while the bypass tunnel=20
>provides the ability to simultaneously protect _multiple_ LSPs=20
>sharing a given resource (node(s) or link).
>
>Also, as Adrian mentioned, it has lead to interop issues.

FRR interop issues was IMHO not related to this flag in the FRR object.=20


>
>> >
>> >8. Sec. 7.3 on path optimality talks only of the optimality of a=20
>> >single path computed in isolation. What is the definition of=20
>> >optimality to be applied for computing diverse paths? (Sec.=20
>7.7 later=20
>> >does not specifically discuss this aspect either.) If one used CSPF=20
>> >in sequence to compute two diverse paths (as this section would=20
>> >imply) then the computation may fail, even though a set of optimal=20
>> >diverse paths exists (as acknowledged in Sec. 7.7 ahead).
>>
>> Agree, we should add a definition of optimality to be applied when=20
>> computing diverse path This maybe: A placement of two=20
>diverse paths is=20
>> optimal if their cumulative cost is minimal.
>
>Yes, this is one definition. I think in  some previous email=20
>exchanges, Fabio had provided a good definition of optimality=20
>for diverse path routing. (I'll try to dig it up in the=20
>archives, and post a note separately on it.)

Thanks=20

>
>
>> >9. Sec. 7.4 "Inter-area MPLS TE Routing" I would like to underscore=20
>> >Adrian's point on specifying the scaling requirements themselves=20
>> >(with respect to areas, amount of flooded info. etc.)=20
>rather than the=20
>> >realization of those requirements (by not adding any info. to the=20
>> >LSAs, for example).
>>
>>
>> It seems that you are OK with 5.3 (no comments)
>> "Containment of routing information MUST not be compromised to allow=20
>> inter-area traffic
>>    engineering. Information propagation for path-selection=20
>MUST continue
>>    to be localized.".
>> Thus you should also be OK with 7.4
>
>Actually, 5.3 imposes a requirement to preserve IGP hierarchy=20
>and scalability, but at least leaves open the possibility for=20
>the IGP to carry extra information as long as it is not an=20
>"unreasonable amount of extra information" that does not=20
>"unreasonably increase IGP flooding frequency".

Basically 5.3 points out that information propagation for PATH-SELECTION =

MUST continue to be localized.=20
It also means that we allow for the IGP to carry extra information =
provided that it is NOT topology related...

>
>I thought 7.4 should probably provide some specifics on what=20
>unreasonable is, and leave it to the protocol designers to=20
>devise protocols that keep within those limits. Instead it=20
>seems to prescribe a realization -- one where no topology=20
>related info. of any sort should be added to the IGP LSAs.
>
>> Basically we want to preserve IGP hierachy concept, are there=20
>> objections to that point ?
>
>Depends on whether you want to preserve it in spirit or to the=20
>letter :-). I think it may be useful to give protocol=20
>designers some wiggle room.

IMHO it is also useful to tell protocol designers what we don't want in =
our networks...

>
>> This means, for ISPs contributing to this draft, "no leaking of any=20
>> topology related info accross areas". Of course, this does not=20
>> preclude the addition of info to the LSA, provided that it is not=20
>> topology related.
>>
>> >
>> >If solutions can meet the scaling requirements by adding a bit of=20
>> >info. to the IGP, I think this should be allowed, otherwise=20
>there is=20
>> >really not much that could be achieved using current mechanisms=20
>> >(since no modifications to them seem permissible, and we already=20
>> >established that these, as they exist, do not provide for adequate=20
>> >inter-area MPLS TE).
>> >
>> >BTW, one of the points made in this regard in these
>> >email thread was about the use of path computation servers,=20
>which can=20
>> >supposedly compute optimal paths without any impact on the IGP.
>> >
>> >I think this argument isn't quite complete, since it hides the=20
>> >signaling extensions required for these as well as the scalability=20
>> >impact of recursive PCE-type schemes (btw, this was a question that=20
>> >came up in independent discussions with JP in the context=20
>of the ARO=20
>> >and PCE schemes, and is still under discussion).
>>
>> Let's continue this discussion in another thread addressing solutions
>
>Ok, sure.
>
>
>> >10. Sec. 7.6, the figure O(N^2) makes the assumption that=20
>each of the=20
>> >N ARBs at the border of the neighboring areas is connected to each=20
>> >other ABR. No? In reality, the number of crankback's may be=20
>> >significantly less therefore.
>>
>> No, basically if you have X1 ABRs in head-end area and X2 ABRs in=20
>> tail-end area you may have up to X1*X2 crankbacks, provided=20
>that there=20
>> is a path between all ABRs. This does not assume direct connectivity=20
>> between ABRs.
>
>
>Ok, thanks. I see now what you are saying.
>
>> >11. Sec. 7.7, I guess it would be useful to qualify what is=20
>> >considered "extra-load" in signaling and routing here. Is=20
>that to be=20
>> >interpreted as _absolutely no change_ to current signaling and=20
>> >routing protocol objects?
>>
>> No, this should not be interpreted as "absolutely no change".=20
>> Basically the solution must respect scalability requirements=20
>spelt out=20
>> in 5.2 Will clarify in next revision.
>>
>>
>> >seem feasible, if inter-area routing/TE is to be achieved, so=20
>> >something more specific is implied, which would be good to=20
>spell out.
>> >
>> >BTW, also tend to agree with Adrian's point that this section seems=20
>> >to be describing the computation of diverse paths rather than the=20
>> >establishment of diverse paths, which would seem to be the=20
>> >requirement.
>>
>> Yes this is basically a requirement on computation, but in this=20
>> inter-domain context Path computation and Path establishment are no=20
>> longer necessarily independant (see your ARO proposal)
>>
>>
>> >
>> >12. Sec. 7.9, what is meant by "inter-area head end LSR"?
>> >An LSR that is the head-end of an inter-area LSP (that is, an LSP=20
>> >traversing multiple areas)?
>>
>> Yes, will reword
>>
>> >
>> >13. Sec. 8.2, not sure that is providing a real measurable=20
>evaluation=20
>> >criterion. If it is to be kept, some specifics should probably be=20
>> >given.
>
>JL, sure. The perf. requirements are given in Sec. 8.1, but I=20
>was looking at Sec. 8.2.

OK, in 8.2 the criteria is more qualitative than quantitative

>
>Also, even for 8.1, it may be good to add the =3D to explanation=20
>for (1) and (2) that you've given below.

OK=20

>
>> IMHO what we list is clearly measurable
>>    (1) Optimality of the computed inter-area TE LSP path.
>> =3D Computed cost - Shortest cost
>>    (2) Optimality of the computed backup tunnel path=20
>protecting against
>>        the failure of an ABR, capability to share bandwidth=20
>among backup
>>        tunnels protecting independent facilities
>> =3D Total backup bandwidth consumption
>>    (3) Inter-area TE LSP set up time.
>>  =3D clearly measurable
>>    (4) RSVP-TE and IGP scalability (state impact, number of messages,
>>        message size)
>>  =3D Memory footprint increase, CPU load increase, Message size=20
>> Increase...This is also definitely measurable.
>>

>

Thanks again for these comments. We will post, on Monday, a new revision =
incorporating received comments.

Regards,

JL



Envelope-to: [e-mail]
Delivery-date: Thu, 17 Jun 2004 06:46:48 +0000
Date: Thu, 17 Jun 2004 08:31:06 +0200
From: Scott W Brim <[e-mail]>
To: dimitri papadimitriou <[e-mail]>
Cc: Adrian Farrel <[e-mail]>, [e-mail], "'Kireeti Kompella'" <[e-mail]>, [e-mail], Bill Fenner <[e-mail]>
Subject: Re: Draft of a liaison to ITU-T Study Group 13 about L1VPN
Message-ID: <20040617063105.GA2796@sbrim-w2k01>
Mail-Followup-To: Scott W Brim <[e-mail]>, dimitri papadimitriou <[e-mail]>, Adrian Farrel <[e-mail]>, [e-mail], 'Kireeti Kompella' <[e-mail]>, [e-mail], Bill Fenner <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.1i

On Thu, Jun 17, 2004 12:50:50AM +0200, dimitri papadimitriou allegedly wrote:
> hi adrian, what do you mean by "to separate the work from the noise that 
> happens on the CCAMP mailing list" 

Right.  Adrian, just delete the first part of that sentence and start
with "We have started a new mailing list".  

> and "In keeping with all IETF mailing 
> lists,.."

I have no problem with this.

swb



Envelope-to: [e-mail]
Delivery-date: Wed, 16 Jun 2004 22:53:27 +0000
Message-ID: <[e-mail]>
Date: Thu, 17 Jun 2004 00:50:50 +0200
From: dimitri papadimitriou <[e-mail]>
Reply-To: [e-mail],  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
MIME-Version: 1.0
To: Adrian Farrel <[e-mail]>
CC: [e-mail], 'Kireeti Kompella' <[e-mail]>,  [e-mail], Bill Fenner <[e-mail]>
Subject: Re: Draft of a liaison to ITU-T Study Group 13 about L1VPN
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

hi adrian, what do you mean by "to separate the work from the noise that happens 
on the CCAMP mailing list" and "In keeping with all IETF mailing lists,.."

except from these expected clarifications, the proposal looks fine to me

thanks,
- dimitri.

Adrian Farrel wrote:

> Comments on this proposed liaison to ITU-T SG13 would be very welcome.
> Thanks,
> Adrian
> 
> ====
> 
> To:          Mr. Marco Carugi, Rapporteur for Question 11 of ITU-T Study Group 13.
> From:      Adrian Farrel and Kireeti Kompella, Co-chairs of the CCAMP Working Group of the
> IETF
> Cc:          Alex Zinin and Bill Fenner, Routing Area Directors of the IETF
> For:         Information
> Deadline: None
> Subject:   Reply to Liaison Statement on L1VPNs
> 
> Dear Mr. Carugi,
> 
> Thank you for your liaison statement COM13-LS23 dated 3-12 February 2004 on the subject of
> Layer One VPNs and related work within Study Group 13.
> 
> Thanks also to the members of Study Group 13 Question 11 for their work on
> draft-takeda-l1vpn-framework-00.txt which represents so clearly the motivations for
> L1VPNs, the  high level (service level) requirements, and the architectural models
> that might be used to build L1VPNs.
> 
> Members of the CCAMP working group have expressed a considerable interest in this work and
> we are keen to pursue a working relationship with SG13 to advance the description of the
> functional requirements, assess current protocols for suitability, and develop any
> protocol extensions that may be necessary.
> 
> Some feedback on draft-takeda-l1vpn-framework-00.txt has already been made on the CCAMP
> mailing list and we know that the authors of the draft are aware of the comments.
> Hopefully this is valuable input and will be taken back for discussion in Q.11 where
> appropriate.
> 
> In order to further facilitate the discussion of L1VPN within the IETF and to separate the
> work from the noise that happens on the CCAMP mailing list, we have started a new mailing
> list designated for L1VPN emails only. In keeping with all IETF mailing lists, this list
> is open to all and we would welcome active participation from SG13 delegates and
> attendees, and from anyone else who can contribute in this area.
> 
> We anticipate that initial discussions will focus on draft-takeda-l1vpn-framework-00.txt,
> but that we will move on to an analysis of the short-comings of existing IETF protocols in
> the delivery of L1VPNs.
> 
> To join the mailing list please visit https://www1.ietf.org/mailman/listinfo/l1vpn.
> The mailing list will also be archived and can be read on the Web at
> ftp://ftp.ietf.org/ietf-mail-archive/l1vpn/
> 
> Sincerely,
> Kireeti Kompella & Adrian Farrel, CCAMP WG chairs
> 
> 
> 
> .
> 



Envelope-to: [e-mail]
Delivery-date: Wed, 16 Jun 2004 16:34:42 +0000
Message-ID: <00a301c453bf$c6791720$d4849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "'Kireeti Kompella'" <[e-mail]>, <[e-mail]>, "Bill Fenner" <[e-mail]>
Subject: Draft of a liaison to ITU-T Study Group 13 about L1VPN
Date: Wed, 16 Jun 2004 17:21:49 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Comments on this proposed liaison to ITU-T SG13 would be very welcome.
Thanks,
Adrian

====

To:          Mr. Marco Carugi, Rapporteur for Question 11 of ITU-T Study Group 13.
From:      Adrian Farrel and Kireeti Kompella, Co-chairs of the CCAMP Working Group of the
IETF
Cc:          Alex Zinin and Bill Fenner, Routing Area Directors of the IETF
For:         Information
Deadline: None
Subject:   Reply to Liaison Statement on L1VPNs

Dear Mr. Carugi,

Thank you for your liaison statement COM13-LS23 dated 3-12 February 2004 on the subject of
Layer One VPNs and related work within Study Group 13.

Thanks also to the members of Study Group 13 Question 11 for their work on
draft-takeda-l1vpn-framework-00.txt which represents so clearly the motivations for
L1VPNs, the  high level (service level) requirements, and the architectural models
that might be used to build L1VPNs.

Members of the CCAMP working group have expressed a considerable interest in this work and
we are keen to pursue a working relationship with SG13 to advance the description of the
functional requirements, assess current protocols for suitability, and develop any
protocol extensions that may be necessary.

Some feedback on draft-takeda-l1vpn-framework-00.txt has already been made on the CCAMP
mailing list and we know that the authors of the draft are aware of the comments.
Hopefully this is valuable input and will be taken back for discussion in Q.11 where
appropriate.

In order to further facilitate the discussion of L1VPN within the IETF and to separate the
work from the noise that happens on the CCAMP mailing list, we have started a new mailing
list designated for L1VPN emails only. In keeping with all IETF mailing lists, this list
is open to all and we would welcome active participation from SG13 delegates and
attendees, and from anyone else who can contribute in this area.

We anticipate that initial discussions will focus on draft-takeda-l1vpn-framework-00.txt,
but that we will move on to an analysis of the short-comings of existing IETF protocols in
the delivery of L1VPNs.

To join the mailing list please visit https://www1.ietf.org/mailman/listinfo/l1vpn.
The mailing list will also be archived and can be read on the Web at
ftp://ftp.ietf.org/ietf-mail-archive/l1vpn/

Sincerely,
Kireeti Kompella & Adrian Farrel, CCAMP WG chairs




Envelope-to: [e-mail]
Delivery-date: Wed, 16 Jun 2004 16:22:36 +0000
Message-ID: <009e01c453bd$fb5d3310$d4849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, "L1VPN List" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Layer One VPNs
Date: Wed, 16 Jun 2004 17:21:21 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

This is just to let you know that a new mail list has been set up for the discussion of
Layer One VPNs. Subscription can be managed through
https://www1.ietf.org/mailman/listinfo/l1vpn. You are all very welcome to join.

This list is currently "under the care" of the CCAMP co-chairs while we evaluate the
interest and relevance to the IETF.

Much of the initial work for developing service level requirements and an architecture has
come from the ITU-T SG13 and we will advance the discussions in a cooperative
relationship.

At the moment there are three drafts that are of particular interest.

http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework-00.txt
This provides a good background to what L1VPNs are trying to achieve and summarizes the
architectures that may be used.

http://www.ietf.org/internet-drafts/draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-05.txt
Describes a BGP-based solution to "Generalized VPNs". This fits into one of the
architectural models for L1VPNs.

http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-overlay-04.txt
Satisfies another of the L1VPN architectural models.

We hope that the next work will be:
- review and refinement of the framework draft
- tightening and further detail for functional requirements
- applicability of the existing GMPLS protocols to the architectures in the
   framework
- identification of any protocol extensions that may be needed.

All of this is done under the following provisos:
- there continues to be interest within the IETF
- it continues to be judged appropriate for the IETF
- no better place for the discussions is identified.

Comments on these points as well as the drafts and the work itself are welcomed on the
list.

Please note that at the moment the automatic archiving of the list is broken, but that
this will be fixed very soon.

Thanks,
Adrian




Envelope-to: [e-mail]
Delivery-date: Wed, 16 Jun 2004 10:47:46 +0000
Date: Wed, 16 Jun 2004 11:51:08 +0000
To: "Ccamp" <[e-mail]>
From: "Adrian" <[e-mail]>
Subject: RE: Message Notify
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="--------fotdgildgkivtidrcwev"

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

<html><body>
<img src="cid:nopujwwhfs.bmp"><br>
</body></html>

----------fotdgildgkivtidrcwev
Content-Type: image/bmp; name="nopujwwhfs.bmp"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="nopujwwhfs.bmp"
Content-ID: <nopujwwhfs.bmp>

Qk0KDgAAAAAAADYAAAAoAAAAdgAAAA8AAAABABAAAAAAANQNAAAAAAAAAAAAAAAAAAAAAAAA
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/KgMqAyoDKgMqAyoD
KgMqAyoDKgMqAyoDKgMqAyoDKgMqAyoDKgMqAyoDKgMqAyoDKgMqAyoDKgMqAyoDKgMqAyoD
KgMqAyoDKgMqAyoDKgMqAyoDKgMqAyoDKgMqAyoDKgMqAyoDKgMqAyoDKgMqAyoDKgMqAyoD
KgMqAyoDKgMqAyoDKgMqAyoDKgMqAyoDKgMqAyoDKgP/f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/KgMqA/9//3//f/9//3//f/9/22dwJ3An
uFcqAyoD/3/9d7ZLKgMqA5Q/3XP9d7ZLKgMqA5Q/3XP/f/9//3//f/9//3//f/9//3//f/9/
/3//f7dTKgMqA7dT/3//f/9//3//fyoDKgP/f/9/3XNyMyoDcjPbZ/9//3//fyoDKgP/f/9/
/3//f/9/KgMqA/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//38qAyoD
/3//f/9//3//f/9//39wJyoD3XPaYyoDKgP/f5Q/KgPdc/13KgNyM5Q/KgPdc/13KgNyM/9/
/3//f/9//3//f/9//3//f/9//3//f7lfKgPaY9xvKgO3U/9//3//f/9/KgMqA/9//3+2SyoD
3XPaYyoD3G//f/9/cjMqA/13/3//f/9//39yMyoD/Xf/f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//fyoDKgP/f/9//3//f/9//3//fyoDKgP/f/9/KgMqA/9//3//f9tr
t1MqA3An/3//f9trt1MqA3An/3//f/9//3//fyoDKgMqA/9//3//f/9/lD8qA/9//38qAyoD
/38qAyoDKgMqAyoDKgP/f/9//3//f/9/KgO2S/9//3+VRyoD3G//f/9//3//f5VHKgPcb/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/KgMqA/9//3//f/9//3//f/9/
22cqA7ZL3XMqAyoD/3/bZ3AnKgMqA3An22fbZ3AnKgMqA3An22f/f/9//3//f/9//3//f/9/
/3//f/9//38qAyoD/3//fyoDKgP/f5VH22f/fyoDKgP/f/9//3//f/9//38qA3An/3//f7lf
KgO4V/9//3//f/9/uV8qA7hX/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/38qAyoDKgMqAyoDt1P/f/9//3//f9xvuFeUPyoDKgP/f3AnKgOUP9tn/3//f3AnKgOUP9tn
/3//f/9//3//f/9//3//f/9//3//f/9//3//fyoDKgPcb9trKgO2S/9/22uVR/9/KgMqA/9/
/3//f5VHKgOVR3IzKgP/f/9/3XMqA5Q//3//f/9//3/dcyoDlD//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//fyoDKgP/f/9/uV8qA7dT/3//f5Q/22v/f91zKgNwJ/9/
cjMqA/9/3XMqA5Q/cjMqA/9/3XMqA5Q//3//f/9//3//f/9//3//f/9//3//f/9/KgNyM5VH
KgOVR/9//3//f3Iz3G8qAyoD/3//f7ZLKgPba9xvKgMqA/9//3//f3IzKgP9d/9//3//f/9/
cjMqA/13/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/KgMqA/9//3//fyoD
KgP/f/9/3XOVRyoDKgNyM9tr/3/dc5Q/KgMqA5VH3XPdc5Q/KgMqA5VH3XP/f/9//3//f/9/
/3//f/9//3//f/9//39wJyoD/3//f/9//3//f/9/22e3UyoDKgP/f/9/KgMqA/9//38qAyoD
/3//f/9/22cqA7hX/3//f/9//3/bZyoDuFf/f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//38qAyoD/3//f/9/KgMqA/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f7ZLKgP/f/9//3//f/9//3//f3Iz
KgMqA/9//38qAyoD/3//fyoDlUf/f/9//3//f3IzcCf/f/9//3//f/9/cjNwJ/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//fyoDKgP/f/9/2mMqA7ZL/3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
3G8qA9pj3XMqA7ZL/3//f/9/2mMqAyoD/3//f7dTKgPcb9pjKgO5X/9//3//f/9/22sqA7ZL
/3//f/9//3/bayoDtkv/f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/KgMqAyoD
KgMqA7ZL/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f9tncjMqA3Iz3XP/f/9//3//f3AnKgP/f/9//3+3UyoD
cCe4V/9//38qAyoDKgMqAyoDKgP/fyoDKgMqAyoDKgMqA/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/

----------fotdgildgkivtidrcwev
Content-Type: application/octet-stream; name="Counter_strike.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Counter_strike.zip"

UEsDBAoAAQAIAGBc0DDmlWfU/lQAAFBRAAAMAAAAcWZrc2l1a3EuZXhlzpFNqhZJM6+ZIedp
hDF/YKqpgG8b1EmVYKlePOrLCIpS0j9rtVjLJhbaZ9uoxH7eosoh41Ow7xiipGyY6pBsfWEC
2zdc7cP95oKvx0zbbUg8KexKYNJ+II2MqS1o/c2ppXM2CxEeVsx9H0ua6pY1kQsuN2iZ0lBX
RdlSF9DB4oj6Y3vPLZLJrpAmcLaKcikhEIFeK9AGf1/aJp8nGdqhaKj18z3fBPTuIHVAYKWe
Lt3gqrs2WUUi/bPSdUv5fSuA01pszuAeN+bmzEZZ5kYheo6xmefcYiHFlj5XnejRz5UH2+VY
n7OYtIdt5MMZkkS5D2lrfeCUyi5HdpMjW40KGmfGLfwHSP2eDi8CXnOAWIZOmH5KYsXsvqcX
9QcXFFRcYtF1OC8ThvXdQkGsGsMQ6eM6yO6aE3XTyfpOitXWNgO6q84q04diwq3oTQGFXNAD
uni865yYDhsjH/Idxt7A4lrmNWDezjDAq5oqSwTFKThVoxGMQ1sfh6xvZBB5T7pasn12I369
/QAGIJZg4wK83IKIlmRAQR5OR8u+JoIhvde5o+qWYOVmJqN4m2MYYYZjAqYP0TY5VvF14BEG
YeO08RecwAogfopazrAh+Pd0N2edKn0nytAkDi8Py/onanmLJDR3WU+6pBDNzN0QtIWEjzvc
p3W1Czijmyr6H9PktNGgxyLl8LDQPE2xSJVGNxIsSC/UZGeFLRjdGso77nzGofCDJCmWoGk9
ojJvItAGDn3yyzK/KY9cnsKFGiHL9jeX1c5+4IsLuWB0mkQFOnIpGLKmeaOP8xg+MxrACOyf
zvR8Rq5viMouYb/2F+3R7Vy+MfDGn847kuorURpMRLTNaIiai1xcaFJMOMhPDmAYgzhKWflC
tZha1dccWFK7YHCu8KONqWwQ2FzvmAmIotdXYrmMjMSLrQelw9Enw7irljL1GR5qoww1Zlzb
HehcRbPMG764UPgGvdxqk5UqQDNrJEk1huRezpyIyPP0+3kwtH4uhD8ZTlEeierAisAOrbk+
glxsw2u7YdA5oSaznBCUhswkVOPu35MJkAFxyuoWn5r1LrEgUShO2sPdYtvMVzHvEbaYB5m2
bZbyHjVrrWBDgyofOw/9Mu9UTNZEpWWwpB7ikQV0EaN0MrAbz5WYvB7B/H6J+9kM5jR0REiB
VLmWTfff4w0gcrnyORep6ejzUSqOXaKpnmKpTX0KGSPsudSONwjYiejYfT7Dq6DTWqSApQiu
2E+zNsqseU+25SUP7o+FS4XXTySp9xShg0v0FG47kcYAo8XI9CNqZUTtfuvb1nctY2qTDYn+
zKZXTkzFwGq+GA9Rj6iOqO5qZCQ6RI7z/1ScR9PHzfZSiWqHb4x0DzB3WZALNbonCmu00TeS
lW08RU5DfS4KzgoOvHA6YttFcj8/umwZz/pNLdcYZ3IKz+v805sIflBtdKa1k5SBABhzbT0H
53lskmx0IFPfNzf4Z2lGnaWnUvuiLrZUFihdhthbcujkJSRpYfFQT6eNbkKnCNAuveAp4Atx
hfAM9zOPjy3tOWBrRlRXn7VKZcmGZJpyDNkFzT9Ki8pOxyb0R/ftZh3wAWh8naXsGCSxncxD
/Cw4ihpZ3U51/QiIwNAfyJDR1W7G+qKWgxggQeycpjOFXaHJcDUSmhBUXtf2FeSxOj/7UJLJ
soVhlhe8MGynJPNZQTUw4mowzE12g4IXWK27HxsKNUjBgx/f7EfU87nJgD7m1tQeZWROBuKX
e/YakC/eR3tTyC2od+8hdbHZ9CfDMURvpcQ1rnOaNod+fCAY0P3NJNcXmwsbNV5/NiNjS4f2
RXZURhF9KR4w8d02IbO2+3v8/vkMTypRS5n2k8fiIMXLiAjX0N4xwDFv5W7x8Ur71oiPZusI
JSW1Mx25AbHSa3geyP4pHIlY8hsqrmextSEODNqeQkLhNVGbtF6PUCfsAC3ubZWTQNYSHTcK
42X9Usb9FNmD94RF63gzcJAVZZHNQnu5fmQsLljIcbI6Sfwnx69oup9t12W1WLdf9+W5dJxd
LDGRj0QAJ5S+yDg4cNgYMkvKcKtj9Dxa4B3Hsq8mxXh2fm2zNS2iPbL0MQ7xTBGXOkfrTVg7
5+sSPLg+rsKGy278EbLvo7Z/hxHvxrl3jcP6XMlCheXK+mUYTSGzZQ8l5yKTCiwgjDxvaUaR
983zlw8dvbTAaWBbo1yBijUw/f2cVzaOYO4eQZUK0qJvBWM+W5ExGplcK5/9fHGDfityp2lT
S5p/sHjBj/aEspbB+vou18sFWn+PGaGGk16W+bXiR4hYXGGshUwcgFGQmwJ012pSTRMbw/yD
bjmuhOFfS850WI34WU7sbQ5BHeOrJioL4rcA4epr/czMjBPCY4zG0rDtG+DC4Gtj+e64HIT8
08jnkXWz61n3Xkg43tgnl2TkA+hAOg8rxLrcPCYWVo9L+HRvgJKhlUXwYrkjS2AJ8EcRQqUk
EPFYbh/11mwL4jBEozD+XIga8qNjtP3uW65npQdiaJpycz0FBnq21d6+GUHyknAyTeWGpYUF
LaUrck9UwJJKExHctfQp1lXqSwT5zqeUw5DSYrPXajX3Ij/hBVJ69Yvuie3aQwJCGvxVqz8m
LLxmwwCqq8m2sleCb2Vt/R9abqJP9Ox0v4Wk87//cFm6d8+zW5UiwGwfkzO/Pua1BHk/wcQJ
37JsU8nXDX+hPHKooedhemKSxvcgu2QMTkq1pbv0Kq5v8eJzBoCBBkVveDgC2u64GouheZ8d
S9Yqoh/87qSCx3FP1ugktFudTHDQhClKhp8+Sp8bz8dkpPLlT5mcL8fgNgI80GlY5EonS7IB
fiPXB14r1DK6+BKT2mt20ZDV4Xq9o99cIb2COsWFkN3EhhBeyeI7gkwwkydb69goSfVcV8eX
R3vGpAnV27xh2h/lllVsq2YKDr0iCxWn54NINcDyuGJZxsb2kwJSnjQOW6k5EO3apYqf0diS
sscTgNABS0Q05l25W5JNNgF2juDJmSUQ+fs+25U/08MnRcktPZxQR+OqD3b/ZQVKwE83ZZ+W
tc1HdKgt5nYFDGSGC/3eIL1ADLrA2+MfAuFXcsyI4UzOhIQ0S8XU6zdieu2iOvuXc5muIy1L
MPpBQdcTzwz5zNwojHUkHqPKsoNteaQ1DsDkZtEAANHOQ24IgzRIF7CC+jpyL6vzqGsbF6N/
o49utWPJx+ZmS64SjCegWpuceUwLKL+0r7zo5UwtQrXhQMQWaOcHqbtku83f31S4QySZYkM8
nwNW5rt7yJjzjyk6UfRwrgdeBvQDGVQP29BOaylhjj6Bjd4wcZBZwVPIdcleZmuvxRCvpx6R
k/0trXr2ahda7iHurPjDnCoKyLV0CR/CrKixPdd32ZyqSvLcUB8Ag7JitYebayAerRl+TJ9q
X9DiCGF8u3HEdvXvshU2J8g76nb8YQcHECjSp60AO3Qu/KzN86ecmKkSsXABG7HlcphGr/kn
qzk4mt+RmfyQky4hxZw/NZGyMJmujVcXg7z1JWpQZlr6abulzAB5+s2P+Tt0CRZ7GngAq7kU
KnznC3Il8qRqHNE+g70KHaebucBdbJFey+i8lpihWN5+BNsg8cFXkVQgRnfXzmM7d5o2+rMw
YjVlQtIS8CsdPJYxhHzDeEqJaecHf7Zi3lU6QTnFpPI0o45XyxuXREE2Df7EeXyMdA38Th3Y
/hTNspgr9QixvKgX45twQBWAjOtZfRP5bXC73lTtDCIodv2UjzvvXwQLaEz5zvJi3Lf52iyH
ENox6c95YLDfxq/j9RJk8aJ1JghKxI8mcJjt4GfzbAUL8Px7jNMWseCdO39qr4LyY6u73rph
E+eGOPACDMLDQXejqCRzo3jGs+77d8qkTT3t6btoXM7468z+sJ4Yt1EJIEMz6tNc3dqvhHov
dOFqtM6XoFEnD96R3HYiviQ5cyCq2exAjSycsnwrdFJewp9CEhoGLKBfM0Ynr1bx7J2F/ApF
XoOTdVqv/zF1SMmUL5n3Gxx8MBru53K0JLeU/ipB5D45OTpRezVr5gsbER9bjNfaKxBDuCw3
z9OeU/93LC8RZ3NTcFrt2/YM0VWcg9KwO2kuZH5QrQ+ALkSHvQ4gJ2riyybUBmjzIrliRzGv
96PcpqY8umCXFy/Vwp6phqKRlpMEx+6NGDuiqb3l8r0Z6EdOHbyIv3RlIh6dtXowDd79J+av
DlpSEoESgyHXl5BhjL5k55/1tJYlR7cp7Ahjn7KdLMrw7/Nt7bvUtbHdbyjnPKzv+oczJp4s
UAxyG8xbQ6VbxCPV61m7SlfdOXVRzcOvcMk8XNRs4465/mFywGMG2na48kld9+6Mntjiew6O
gTSsphXtm+/3xYMBZiEg0U1bF8NbWFHKg1VkuVBk79TCHixck9qOR7zRoRfd1xzEsOMY2aVZ
LDA+p22G8qge5kXv8LVB5LPZ2tKu0rzIgHkYxlvlV/T3Uhg913Y7bdrrluH1DflKIZwYLcZd
v88TbsibjldYS2oV0KXwre3ddeQXIBIcRUmw2hlsD9QopzeGk0j6kMY/G6bpGPRUi0WKKgfy
jBwyD6a80cGpCeIP6WZdALkCcvPWsOVv8qTdd/EtkDmbyxk455qSbL5i5IOxh+W1Z3R8CcIt
eBIYftFuF167V3MUQsVovv/Qt8vHIrQaiVTWsEkGiogApn6RHVKDLf+LmEGFQo/6GC6UVnbr
rWFIv7Ze294uVkyTcMdJtXzFRHlexVnaoAbxPUYS0AShWJHmPajQBUHJRr4hWljenOWSN1C3
mKH3k69VpS60kbZ9s+vGJ4HTlCrAeMd8KT7094sDxRdNHUPsqg+3Y/l85g6B4Dn44/CsZE0s
8Z2cnGK3GolHUC+RHa8jt1vNoEVH3hWnGaOjogl8EP2P/bH0SB0eTQ+/xhzeete00LS/niaL
d15gfJx9ifrOgVJtj2S4SDsm1Uz6tq0B1s0lBxTOX7SX7w+89S4GJ3ho+JzgJluFl9C5mfaQ
oe+v7P0itqsA1VFf5J5C+RD3T4kGrktYUyrzX6tc7SNYZK+vTh/AAA0qt3QvBtWW1O6MsUao
HLcudxNKqW82slopY8PF12Yd0QAr5xrL9xNaOOCp565zvt0vXuUQNxcekde1qSC+VlQgpPx4
9LMJGZ+lKTQdkCSZmfq4gdRnjbhM3pamL0f9oQxIijklkdDx4wSsj5tiL5zvkQ2mCHLTm55W
05AAJSh9D9L/uMR3vHTAKl7DHe1kmzHixBB89nkJUQCgzshnUolGnSTafPqS7Iue+BbyxT6F
wjIpvrCRZJleFXp9FKG4CHsi0SE29HkEyf4AWIkxrfjo4zy6HthBlz/jDe68ErXcfMNlCpGa
cJY1oGrCwfQ697c662m46uTt3HzGGyAMonUzhCAZVqxeXx/BPvCTgjLTarEX1hcpgcbZqYy3
2Usx3cLTkkVlxVw0xgJU3OBtxGxX8XX5zjPyxkIyYLTn1oz35H1ycPfEZILrM7TZTkQ/8aM5
PRqx2FY+wVWE7ns+5uAguFYOVg7H30T1jSt2Gy+8jofU18f3ed0GsUeDc/B2fowVyaNo2Uhv
WLPuKeYqq40THe669hetiTwYVJ7M7YIW232RrXWD363mp8dTwHYojBJfiW4Zd755LTGNAm/D
TVR8CWpsT1IZow1mnExWxxFBC/DtOcT6rgvjSyYh5Efsiun59N4fpxuDkBUYeWMrrprr+sAa
0cXnqJUMZGahD5FZjAhCsrPbSxNGMGEv1jHeHHK0YLtRHW5p8uar9jsvgnpLM0WfM2VSNYs6
xD2pvAiOhHIbYhFyKdT6Y3ixf8B0j3IFw/zuTCM4nHYuus7ygj+RPk9nnZ1rrYaY6rcFqqPj
t9ah638Dj7QakWBcA8ryemTOcGwchVjXrHd6dz1pQEE3aF0QcFjo79e5adHXeVy/XuPxaH0q
zEenymgPOqFCo++Ue026nTqzmbPjJMkYawt3QVXc08kpgRK8rNC8W3Nf6kfZ6wEI2S8gj8b8
4qfnD0g4zBsbSxbyBd0vSZgOJ3Bd6TAyuhmx8B6YsoIPD55Smnu8S4L7Hs4PtHQAxbJ5UIYC
SOuTMFkwRGl0c0W8AvwdFBK+l98tJY9JX5zwU3I019azidIvdhRGppBwtqN2cW1LyIo2TzWq
MC4iuxZcIZdtnpd1dP0+nM6tOh5L0EZp3HPw9gtivc2rHaSthtBdYbb+Rz83qFMVmbiHCYOc
yKzhbKi1mjguRehY6UpIr7/MbHR8du84ZEytfc9dvxMe6lHmpNI3VO8vAHzFQVcScNEy9aE0
uYv0HroPj+K/ttUeG0gXdV8f4ERDp2Tzs2LhzoA6l7L5DKpsUrcXkWI3BO//eHpZiKWWElTr
Lq/MOzhvnXtuRTmVZ0Y51tn4v+aA3qGXaRs4lv7DZK3SzB1b9NEKTCrOuXhD8pHRVXg1S//o
OKQ0dKJ7MPDVpZ1JGF/6ACJUFNr5cxn35bm2zjHmqzy6DUwcRP2EXspPvwGQLV6Lt55N0EQn
3SY7P9nOAOwCvbU3YHskyeJd7Ha/nrnZltgszYw+34AF68qQASg6Kk1rsCi8uV79lPu/uW9T
FWKFX03O8qzJtTOiRKwAzGobAGJsbIrfqEF+/4fNukzQ2bgqoIETMziKpIH3e5NcYWwyHTH7
EpumPKyvaj//yMtdTMSAdUAQYml+VWp2bbK7OKw4gJeEnhMc7zfdnaMEyJzInVLhJghNn3wX
LXlmdSMcOmy+0kaRCMwM5X6xQwDQ+JmAYP4ouP2UddGsehQsvEOJvMcDOcZqdlXZJkB5pbDU
5Ep2ZqsjKC/LoNDkrXwU0h/ARo4lFDGEHih4ePqDtqt+2jBTLhjymU1wgmWr5qncp4B4SBXH
POJB6ov7C91vO60uyxY03BCRX6HaUTY9K4q/FYQioCbMDzsbNWy3YPLPYbVX+6Z3/JG0NksR
Rl9dmsTiE1J9DGIGQlhcNtq1F8/Y60q5aRVzf2wm2EDdOjDMbhXNBG8UxTAWE8Gvzd+BsYoT
I9X2waBFQji8yb5/bmBOybHhJ74w2/VIK1t0D4oipHT8I03+BFfN5M4Q3OERInaCaBVxXeXT
qEquiDjEDXQThMk28FADxqHDINk9q1swbbman3wdilRPffxVUZv2TeNSZovNacEUQ//mQMDG
qJEHEcc4WZiLHD9cAvnd78A6c88XtUyOhS9moYwuPB8+ekNXxBYr6ZqNw7gARFQXTTg6D0lT
Zz1EFVU6sEGeyMqrUz2tdy069rLK+3Q4H0v5ARekSp56Kvgf1+meTJZBO7cLh4oDr81yGxP+
6SfNoS8rhD5HbC+2Rs2coEXqyF6ddJIuBV+05tEezZh2I+tXayHc/VFWKp5N5yngGC/oL146
PQNXAoWVDbR+KJO9hx7gIb4RU+I9xrycCpJiT/7GF97GfQha1NSYSeWT7xstRitZQTCVYnKU
GD2fmfqqT1x1h+/9gTNtg2kZ7bR3pshpJdAyH+qnhWCWvcevHIeHrkn9hpoMmKYg0KLLVNwt
wQdL1IkO7G2V+0BDQ60LPoVQCpgwYaoyokuNF2cwvG0d2cHxLw06Ju8fk5e5cbt7mVINW33/
xIqNEScd8BytpXMxl6wy5VgxNJc9fyfoIw7z4oD5vuPebFc/i5Y7DSXx1gpT/MokGNZx5Xl/
D7JGok6ZePZ/95el+Ve4fbpCK3DjsiqENXcGvEgaEjTYB5vnaY7jvBqVZ+HUjoWF5K1d3Z4R
0mOIzz7ThVpFv2nPKhvQSQ6o3mBH1487zWMCh2TeNcV8nKiKnt5JEWIJ7rKI7g1RPhTRSJFn
aFqv/mxRjrlUN9JljhH0fY8niuzpyEmcWccoHA8W3iYKspT1dKfDRXg/+yGfjx5t1s+DEYFN
wuw6xm7vDru3DPeFiMvij3/5oO8zczEV/omfP3ZblamZXMpbG3tQsjySA1HgYd0w7YoygbDD
cz4eoD19vd+b7D8cdXAjm5QBHy2c4MjkjB9YYCYIJAo+M1uXY1uKsep6fccUJh0tBUkI1zCT
IIjuHLWckcepZn8uZlRFDVpz8/4BVXnX7AsZAlBly8hBa8UOVCoEWqLqimTpsWiXpHZQC48s
mUMc9oiKNGCEw/Dshc9Eah5jA32dhmHiB2e4gA6U6yZ5n1A+1Z6cCnIDb64BNwjsIW0/eMYr
wvY/LNEQQZMY+7JtwdK0rjhoHrL9g9wWv05pAYgk6wJ6NBURZKy1BiKyRwk5VkwoI2VO6TiJ
uV3z3h5cWcg4Jokz6VESCzbD+DC4PSS4Y0fVYolOiOIR51vkrLKT88LRV+k9pXOn1Os4MNAF
B9mnZoS3BUQdlh0uytFt3aNddD95JgxcupnpI9PHNEw3d2x3hyt7oAIuyHZc15LegpOWBKmN
EUAuxRY8rH0KsL5bg/aHXNUDt5NxDGw+W6uk7fb5AaqOItHJkHFnhz5q9aGJdaH6YQjGDRJc
LkrDpIaz+Wz1zmQIpB6f97KeeTUSgefpbbi+gOmT2G6nuV1KDVDQivuc7RF+fgmcmS7YD1O0
uXJRnWJJVP3f6PwRWELgqv5b+qcLn40Dx7UwekV2L03tV2eYC8F4Fj2WS1D2ukEsAPrVNsOR
+Ofmo9dpiki6FfSpGHOfNP5FWQTmw7xyrYSwpVNIr/7SvurddzvALlGXdPDA2RULvwf0eds5
5uxd3s4Y201a1fsmRZP1qnKv85y5xJtfE2P6DCn58K4CI4AsN9FXzhL6s11rS2s8J3qNFhCD
35WfEautMiXMwT1uSYi9jqMh30RVaVQ4z3k8EHPgSyPTVhgRGOrt3UVLHI4IcGczcX7EstbT
uxS+MfNHOHgZq2DYQCgkTbGqIGOJttpGwN96NUfM4MiiKuVEKqZAi5kIqgTIqDUxq16M2U/f
RyuXDkuorkBdDJf0Um/wsTGsNZTQyl83Stv4YCo834fX9vBwwAYBxADtXlkL0cVg5gZi255c
zkG1llfmYmxNRh/qndT4jcIIQjEaQP/9uAUIMGY0Q/amP8YeK/fnn190MX6qWmB1KzS4On//
lBGiNKbxt4TXt/TgP20nUf5qlXD0f3bpj7YY885S0lfePwyt80Hw/8zmyNGpjOsvt5jLRplY
HdeCPS4Qy93ou/fYeHNhKaX298oOcANd5+zdCFQ7mVQbUw5Z31/lWvGTMNlV9uv/6U2uCbqs
dRDT62YA/W5FPNC00Rvhkh7PwmCV9OK6tGQFzH8v9yPMfzKM8IJMeN+txW6tOzGjZTnAKdpx
5Nt9iQQe0Xh8YAZIDe02KStmSwKxYxe0/lqa7t3gS4+NCAcrxseCj/MJn6bZymGjyvCfURLK
aFwTlIBMkJue9a+WCc3zIOwgWGchOVC+8p4tyj2N24/f5hDQICKaFuJETuuNuPuVGcvE1Umv
2Gqo71vc1LJhAkNnu5DyZExe/5s6X8CycB8tKDdv7u3pvnGZSQt1nBsYcaMl+Ivf9TeKY6re
Ny5DD/wWyvQiwX4G5BmEx+G5c3GAYWgSTMM9+g4Wcz46jWfHTzeiy5aoDseTSBvI2CqUzjzc
iqJAYo3Uk+JDIZ3mf9EzMwAI3jpXN+qcJJOlNnnQx3WZ8/FgktG4vHY5huq8+nBaYQMnc64l
KJnoiBasj5/KLyHsqwshVsUcbl5YW/AMBHepwguYv+t/3NM+ff0UCG6arezKoRBv3eystwst
GwduQLknuIMuEIJhrUfj65hHXnXzSvfWNLvqwqDrqJxDEtTtWPg1zu78VAO8Laz2csrtlRUp
FQpy0+zcl3iPQ6oiGawpE95jLnlOfg4QQJ3XaR50c/GCJACD/aHMnYw+JLgOeEFmfay4tRl+
2i/nL1d+W1k5lY0dImwJdHEUxIohc39WSSzCyTB5J4vqvt8Xl2sqd9K7wttI260BUysmlG8s
8g+bKqxplzo+0Gn6a/c3GAoaiZKh7DxtrBDzNUA3J3PSTu1e4ffsd6mhMh80PQG34FuUHcDS
6tK25Zax4aoAmiYpSpO1znxfG+EUUgzuuQMqrj4fNkRhwL1+wvx5K51+vHtBPb4fouzx2vTz
2kiDda6sg2NnupGNri6lOD/gsKzJh4RrJu3g0n9/7a7qtvkoNA86b0jqnNGV/vccayvPqX9h
cXgi2uaYAj861t4SEGZ7WhbPJBMhBFrpK7XRwTPt+w970LVi/qiWtdNjnrRAu/UIHQholKT7
hnC+MhYT2rWtBUNgm6JDYBSV4Hb0sracdAKZzKp7RMhT/zKrVm1uHbVZWGpLq4gIH4VkhDeL
WXIlnRGAJAiuS28tPGmZH1/lohsGQ1gFIGXCDf3HUGFy7bg3b147/W4wJXBADTdahpHRA7Vq
4NiND0w1IGQQVLI3RsrNZBeruiGDeRuVP/drLXzptdiEUoA1BAmP4u3yc/usB2LdVin5vLq/
WIJhqYfWNg8I1tVYQv1yYTIE5WOumlEaIVDB1fRPVmd9jX2fQt+QnFycE8L/msKfpvg/7+kj
ghwM8Z3ag4+MrNwpwmRo1mPId2S8iasC4FKMKwMgC3sewJXYDnd9JC6xvgp5HRVw25migYj5
PmsaDnqac8FjE1pfA+jb6yDIFulvINZuYfM9ntfOpnoWbhTpr8FAAyGUM7zozLKe6k15GsoI
rfcpSm1LACBIMhWU6ZKLfL1S0REz201BOxLrG0XOxUWFaxHUrFMLWxRUzzQZb5tw8AE9B5Rg
ugCW3C6MeYjQ9YPopYBFdIESO+94Uz4t4E6w7k/hmTucbsw0pIfZ9l/SEWI+uLMQ4WWuHN08
qxt9Mo/xIL0dmbQUz7fywKEI7ft4GB00Yf8JRX/+JQntOAgx+B5FM3TytSfuowhH4WYnh7RW
5mTRQTDZJGPlLfMJrj9ef3fZDd+6mzXMm43ClPl7aN6lGMT2846+bze4adm8Qxa305+3+xXX
HuOcGyzVF19CgiY1eVqpkqGzIgvkLQ1JD3183uQAidoyvP4foEcr8qoFiS8ACSb/JBbSYJNy
EzWIaNMJ6bVUbaXWLYrwgg2+gChj+O1hDvCM+GnJG2GBk9WbPkdFIjqB8B2UtJFdc/eDzPiU
Q3Dd9DQ5KhSsZmOjIu59eDXSC8lDL6lXwUZ19KvvtHLUoGKKmwPPTsUCI0ra5XhwSEJu/aHI
75Berdhkk1Xx+O5pHBXNRJ4hND5xG6W0pfkeNNLR+ia1IvK731X/H5grHpGftG3is2YsaatY
6MvBJK/kt+TF5Y6F0bMyElCgqkap/x1nFeCD279guLarpxLjayi1Vst8azHOuNhs4g1tHc1w
+sHEfu72zBlZvfsJZy4m1a6XV0Hsgdz2Ru/uWi6CQwTwJ8qme3e/0y5GcA+NAIJESI0VaXhU
6/P1g5U/FUTmZBz49RtCHkieHV2IQ5REQshwN8fP4+Kr30TfHt8p21mrspML9lSP9yvsGw/y
BDVJfkdZa5mftHlEOMF7i4DXMoJxrR+4hCvIz5Ue8Iw0ZV70rHPzaihJPERJd6pq2pfWKxK0
HVqlFCOQ2Nn7UwatzUTZjMPhnumpk+KSmrJacsP1wbJYK2RZdMmyINFMg3KhFLVntaIRb9g6
XSXunds2WJ35w6YRWkN3aCX0iNViG4QMiRy0CbR2plIKJe2JovnJMW/t4DCEi4OZ/aoBtGQ1
JzlQxFdmtRLHHAG9ndn7R8E6/E/yHSlSKQYmHDB12ZlwpzbyUNvPoo7RJV1Zbpwmf7tSSjFJ
Z/8Cv2raCebYrOJa/NgrzO95Y3yL+wYctDhuuwidJNZ53rAAAyLllV046GXy3K1v3LdcvQEE
4rLynL5L9xd5pEh8piT3XDZezEKiVUxLPFw5Lc/axLyCz86DlcftLSdfHjxmv+PDw3n+GPpn
SjCVYfb946WNqf5gaZWKLL0gCF+dB7z+CLKJ1RSVnwCmw4jeX4/cAyiOwoROQt8W6ilKixo9
pNb9hRqoavDUzW2b5QBGrVKFrCbXk0HpshAMSxB/07nU9jFtwQmUSbH3Y7BsUUn+FWqN+Ih6
3ITKmutw4UmWnVKe6GBKxc5oQjxfvJdjZcYLx46SEVxQgm+FzF7VuPVkoLO9izIma1BMjQWR
amZoNEYFVhaJ1meb/YVDKMY9WkBOe70Trw/qNwIxv1AX8GHF7KBJSqXAb23uohqBJhx/V1lP
Xj4qml5wfYDD0aiGZfZiEr6TCfiZboxRofxBLdyy0yFmmkTOWqjl+nWoFhrPs9jvUn7UgWwa
LyAgT3xlBhJu1sAdXqHIvWg8rPzcPVcHdjtFOwOQa2hsnbLgvX1LZMo3aByJ9k3FgBB3x6wP
YDHRQGGB7pffnYCpx1NOYJh1yNDKSIOTwL+SdfbpWloZH+gEmfCsEKVZd/7oa/WUxS8yjJdW
woaVYUiLz37Er66UQE15mDw4yY2RgTsJws6ahNFDtdtMzHz7jXuncMCmpw7UNrMDxTiCOLo5
3gtuZ+FlD8uNytYebGIhxsdFGY/ZenAardyleQfFCjCSEHkiWnNPbFM8e0gQzmzyQcUQMHq7
cz6TvmWvw7sI+AWAL/nVM2BKYug0ulSLR5NRVpcSeoZlzcdsn9C2mkFw7j0k0JIBp1QhCjF7
FEL49HgKGz1ocR4uzbXVXb9tw1qTjNARMfngkPaT/7Y5wLP57Li426Jo06FY3FGNkjTRx39k
T2+/BU6y5i6FAnUmFx+O4lsLpOxI6pPcoC21zpquF5UAjGd4hCXQxVuho6l4dcm2v5Be+NS5
zKpsOrU2xEBLxfwTnB9XsL//V8c0RjSM9/B4kBBzHIRx1DonexVHT0zrGMJhfQ26vBPTgjqM
ZAiJtJCNyYn2F2NTf/byqg8W4qHaSypBEJXWUsBhYTRO9V7FWu/C4H4nfb6qfC4iKn0n0KX+
sBW1x/Crtueu/Iq9B5b27f/JLQRv0oDsAFX/pY9gNKN4559uGaimwIARrad4gqLqckZJjswp
eSopbjDhKvRF7VGNiW7u/dtcr8igqQec0ZotN4R7gjEe+0a8pyxxvL8xNMPkB9awAoag/zyn
99KbLHLrCSKoHcy3TfVExsseRCHsEagW46xRoN2ILIe3eMEwiOgt4yQvIjFTX0AHuDg+ZTd5
c3WTZcN6mv/QEYKze3+S8fP9RoTR0sua7FvqpIx5kr32vvCmBS1Mz16uM9l1SjVvqNZPtwg+
SQJ4w2POKjmBtT83clfkf/VJ6amWR0bjSd6i21t2zqlZL2Wa5y5WKtj1y0TyMi6q7QUInZiS
BfOqGpDOT/AgxPe3iyQiFFx2DoDyR/moGyMtM95yQ+IdQxIZZ87HCa7y4M7ct45XV93Qyw2Y
SNMX9aNsC9HqUtSxPzy061ZsfXQmKL/fLfXejjOmRp6XGciCUSs6COCdxsA1e+M2JYTuop7/
e4aJbDqfxvtmbxltlq4cjrUJG33GbxPOpI8w5vHR1FC7alIm4KxKdLFV61pJl+OHAarDdU4b
JPOGm1KKC8GStS9tx+IWg1f2O+sL7MMrav4om14zKfCyhraMAVH8ev8UJlYj3zUlzh5NVTnu
dRCVcRLj6427+DBDZfD5ob6Yq4d0H1AOhARUXrGNWWy039mF7LTnOOb8rzEU99ec4BclAN/1
P4dprXJ5mMPgPGAT0WaFBpwROVPw2skovyCk6hCnvz2xQi2FTiatxs4bI01rqu1l0vFGWE3c
sa4BB+z2Qb/dQmw/rYrrU0G1AiaLpXALl8LkpH0HAB6oG6C3ibgeaHXkNhsebEOuP0h86iAy
Jp8s3CwJxRAmlhRkSu8i2bxRG68xtwIF09lhKIlflwkGSgXyZ/NBrkEePgAy5V/6PzuSmrF5
CGVoOIz8SEEfwUnGw1w/QVghZev/Y5LNO1/AOVqAmU/pikkvTFODKRlYBqihwob0jw8GG/7p
JhFCod6ctZiMJeuJeqZKPJ+AsgndLV1FlF4/2ybGdLPJEvZx+zw2mB/r7qDKxRRIP+vXEsFs
0KHG7Gp/nZI7l451zUmxpOVTAhCC7lqZvWSI9sL1KNQ0W87eklUidZR1GkwM6BO6MSPPVU9j
veWWtfRpC/MfG/uovgMGdx2Bc5QbcauIlM9lL4lYYH/+KPp0OYmoummWxK4MkeSrl2TkgBr9
exR7M517oDGkMtDNzrxhFumFYS1xpQVa3ePn8xrV7f+luMNjX6DkRJykeAmINW/Tzyv5cZk0
vhtHg+I3/00JhyAs5vRaQzd+AjLTJlZY2G7b/MMF1ZHCsdpMa/8e3JtRRc64hhJk+wIF8LdT
jhkK2djfcYJFD9yyceCRiWwVdBzo1AZdqWCy8NcJ7T7usPOxw8OARMd9AIErIhfkPbd3TZ+b
Zmi83BBbs190v4XvnzerdV15FmCA7L07y3sIptJrplcOXZKAPhZJDXwi/bMT3AAIofNyz15C
J9evSda2fuvxz2/hLlkO/zak18e1LfO9NvDSTAHCAEXXcaeEjPGz7lsSPtXK8w97v7S4FA4g
tb3x2Vb4tORfBQI+Xkgd6nmKZO+Tb6m/ih8A5GoFoWzHbWDdgNHbBRulDq/Qy5G5eEBQMbQF
To3GJfX/stfy3lQDgUZ8xa9bXH3/qZb9tVTZ0bOGzUho6cl5muB6RmqqfiF0EczzZ/DkELLk
8glrSHnNZjR+UJRni8LxmTWmZSuroZuYhdXArGe8BgXks9+KtXIjIaTCBlATy5lPR5O11b29
aWYdHD3biP3pWpKtuGlLuXXsNo3kaZii3VmeRs3HbWhDTk9h5jvx1mPOPDKqUJIyJhmgp+SN
voel/T48l8bad2rjeW8yWFDjLt8eEQOgSzXGzFfKZNGuESpjWUsqml95jnlfKkUHCQjx4SI2
SiEbqeVndOL3PiB0A+myEqpJJcp+QZjw7+zDE+U5uWUswL8R4E6bg24nvIxXjgkfOUGIwUdM
aHfxGs1A9bzSTsBY66KxCJFBRX0UQHSbX/FTRJez6auO0+JU1vj9778wD+EVfHqvgyuhrVWn
zKqgIoYK74KpYKEUw1pD4BuOGzo42ghhl38EKI+EccfY+zs0pzg0LpjM+sZ2XvJng5ouIFtx
RTPGRBdZ0tD/yevBPYGoK12fFgofXTp3wclbyWsXuOK5h2i+Otcf/aaLq3R/sSLgY4Vy4E/N
ICGUQppIPmy1ywp6yFZF2cADwXylscUHqoKuQFKUKcL0dqEsBnSa58M4iLdKGhsr8ZAL4zBK
PJXO6iJpytxjoavlp2/VaIG0Mh9Phn2uOnwNew/2kfP13o8J3X1zw7gFRzqbI2LxSl8L7bLV
mlB4/vkGwapH0Qa2VNpoLGElsWtAp3JEdJ+rZZKSWQEPAM1X+CuMO40FFCi2Yz1cfzCeBzRn
g/odXM7s6AN08DSXOrFOHeJa1MJpGj6pYWh+DtHWNCxBcBoAJwFI7ZxZPpr2mbK2SbhsL3r4
zaTsuTooGM3SEVis8Zh64j8dGWObb2K4exZ49ZMLbrBlix825s1DfVWLPvgaaERvB3ZMPAFL
OG9Ifz8FsURNTxQtuL6W4986jkHlqxDVNsDsxV72+OyJQ5lVbHQWvrrlmBpaW6Z2SU0g8dAi
LvYMVkuIB+0QOdg7LXcbCae0CQ3SkBUGHjzsIvc8eEPjeXHbgUBA6K10J2RI6Kiia0wRb5aW
SrgRMbyA/hvIllW8Ezgif24HPq//zuIs/5XLhQS2NZis+pig0gQfH7zMUUnQKK/mSqA0w+cR
tPGooBtC98uh99EMRzXe1dogBAbXNZgMt63hdM5JA5fCo8ssv+dWk43ySxi4ZwESZhKXNqdm
oJzOUb0LIpPNxkF3AI+tQkG56wohMezJpuGagTSg3uSHEGEvhKHbLY5Omq7GuWgJZ0lvGsad
zF8AXKF+IS/RHuYa67yjQVj+wrwockaP/Qhf32M/hxwCoiMRpA1E9NR95UC38koc5Fzv7kJs
KfIc9F+il3em8+1Cnb/VX9KJUUQarbwSJcPG8YNgyoQFReahair63QMRb+1Mg28PbFJjxyta
c294A4hhyZSy10AkXpHKUFYxLsnVT2nlUNRQHB2m8HgMF9PBVxwoQPZ3dlgp09vy818gePmK
Z1L1JLv5261AZP719dlDNBsnS5CmAku/Aqo8vw0FFXtRwZG/R4c3nW8PEXnoVFtHtEa7lr1a
lGJvtgYSqlcmvKtSgMgDlZ8qNTk5Yv8j54z6OukRfq04kXsG+pLj0YZOxpw8ok530EHP7PYK
ILVF0Z5PwF7cOPXMdqMI9RYPegoW3p4NKQZDaXOw2ipuRngM45PYnJmHTGr6MjFl3szVGwfy
1dyDaWPYdaSTfLthzUONJCi/d0mUhkdpC7mluAv62nJTtHeMJRS6Fnzo4xG/pQqCyo0YywKP
uQ78o3ncCvBrRY2UDoZQthVCH+Yv4CmzJyzJIjocI57u+t4TDsXfZMfNKxvfSBrFbTbmfOeK
OcGRCKwFTyROGiVa42QJECFOqm/gKyXy8TtIypNkUwRzVTTWXdNy2SaDyZu9SmMb60PDsLTm
qs1YsbpD2nrtGBeXq4OtqHaVKrZAaAxrHm26ltxgrQH6sxtVzFbfGIgi95dF6JTV/BaU1jE6
TIX/FM/xxaBbhgF3gs/b5ZWG++Pxx84oNC2Da0nmUxqDIqhhzfdrmKbrRN5Qqltv9cFZgD1t
PxjmB/cQKl0ZMApenlYR3grSRCZN8a8burx5QIY0opdTgdMXRE1+3L5AacR8svaLJ0t+kPWs
JPrETB072jXDvBuqfS8xie3A3oBcw4z+pszeZ0IROwxLur1hi0IvH7vhUvkYRkRshZZ1Wyb6
p8rBHEHFoNIJwJTD7Z/5nQtAreiklpTDZs6wueM8ceUBw6A/FB1LNnHK3A4tv/WtLOeLJST5
8qrlkgHcauNH+kwZDf0AETwnTFVEZ5pmISyUnb5wk7mbsekul+MLGhASwH++bmEgNHOo2w8T
6KbrUpVG8PXRUUGsUsJ8/4MAdnd2HhiHFA+gE+6sV2ewaIFTvlyRVn0krud2aw4oQS9t2EHR
aS/3rCMpaXi4mV6CO/mU6CAh23xZOBqAhswoc889y9R46zaX+U+6jysY6ONha6GpytoAe5XN
FIi4QeHCWo14ALIEZkDLTWxpw5KeOIiyLxLWh0fb5ymMCZrIvW0OA7tA3qZJLuaz8Vtg6HYE
3UxOh+ZachUv9Bh+WMkdDa8/C25pGHaoOb6fwGmn7xwiYELSQGPRTtyl0A/W6vr+EPcf/NDB
Mc8vE59QKj12VqxAcGdlsnKtTFV6d3UPft2MQfO1Lpyu6pLsi7YU5R9BuGUkyGkE0TcOD9w5
UrD5Xfb66TyPiKFzlqtG6Sg1U7yESM0qQzD95JSczwYkeAJYkWg3xs2fkF7T3VrpCysvnrPl
JjvOBEmjp9bPewYK0VynUELrJ+2ftE6TWHRN9XxiIKgxK0DjzlRe/4Rfg4jXuuN+hqvyCPxq
p7/AXkAIgj4y49jCskx5kmt9nE0uqpAmXALId1l//fjssM370b/x5zWni2L3MhQGvZKInrlX
HykFUIwtOvOiymWcba2XELr5MVFsrT5veUgt+4hfuNwN+8T3unzasBU7kk9QS/Em/Ym8Vw8F
KCRJWYD+LZdZwYPkSmdLBgp8emTEReooANeJ+bRypzd6FlIZLyz/P1zZYGh2W3DgWDu1+BxA
aS4OfNmBlB7Bj1gnnAIT3kWXDeByFME2gqcDZU8B7pQL6d79naVEZAZ8LKsyYVLqu0NvrVCf
NgnLiaxwEcefTi+TXWRwBPKIS5ZjUC6uVqOrz8kjP63WX7fN3ADeRz9Jqnay7ND/WEc5X2MY
HmGBa7M/ZhvkpURbQBXqN3XoKfgX/MwqXMldI5EtUvdOhqK8Rfm5Ct3ziS/JwIhyWWLdfuNY
a4EcsOlD/dJF1p5RLf/ysVdFJXAKhHpsmLq5oEd00YJzEiZIpKvNVQ0KmEdadmmGd3iyk2kN
XOUlvjH3RFheISTYX/g3cH3MaVg2TvQdOQ+ipn7ULaEBEeqYaO5G4OyU3Ayx+IOvXgtP/iZ4
8AkW0OBMMaV20iUAxvxkBQ84AhM4xHDabOmOp8DhumReiW3GpsylxHMu09ANPZx/l/wINKnZ
8Y8E8bFf2vkK05403Un1WTSEUBYli0G3xpgUstGRT4Im191D2i13U+jVNFRbNYcmgaCaSWKZ
0kTRkGMgZ9vueBMs0rjSggRzU9zlKhOG2fipuJsx8/iBbcctUXCYim423rpQNzerr1TH+PTR
MJ1XnO5mqdjBS19UfbvpDxGeXcuaaa6iiDSXq12hA+AMtlAY02PyJGBBqN/a8sSHb34znIrM
Wm11e5V1HycgZc8n2J/gBSUbp0zXW0nt99GpFF13zY/f00Pwwt8bTsrwFYpPCnKOOEeSb6X3
bZinP+3WA+EXpafsSnIVd5mNO7pl/1PFRWZOa3SBA6YX24Wckmje9kJrGccZQvM+LL03b3Tk
vwGVPe/92gUlvK5MKZk/IWHZKx7Q7bvTWqHXwhyAp359WnRR5SzJcbTsq2YfX5erGrfMt1c8
Qid3rO/K33PEhY346xqJcQCxxJp8jWO3vWPs4bsPmaYwLzCtLStrZDA2K1iQ2WoMxnvBDieu
fNd+Z7a8/sSxsOrIsgEJOFCxnuE5EsCj3Igje09gZLKVAPNQ4zSGM7+xZdNCPoL+9lS5IbcT
3RJWfWxWZqC11BV6TFRhBcgEW4wfma9XkfSt52Om/2DB6AyZ+ALaDAqtZ2Yy8FcbpxZ2oZ7J
5sJM0wA2N8SLhYJ75WzVspGxG7LXqIcfZ/rmecelZ5QTtaRgf1rh/h0KcoewoFk5KPNirtwe
UhTA7juf5r90yH6Mb/C8hm7hAFvWwwc+PdMQiz5j6DsYh15hgbGy+BLd9BkZ6xJ1RCzUzCZb
/iqpiEUB9PrKlZ9Licr2E1PrjbAFeBUa3JTv0fvbvI8dpXLevxXuclgBnDpkuD3hWaZDt+Ij
MlifS84iGqk2cT5sraHC9/CgZSGWQY74F9m5pMdCGi16m+ZHHiSYnqILscxFDMltjZPjRxmX
JWOEWHTTZ/cNcWaT1LUcOeXvsrrz42/OCGhj228nBTy4DsvSCKx5LVyEhdrCeit/O5YWCsxI
V9/eAiOlY8pGaDhzMTNiPHMuMFHbgGGZNjLoVoixLsjYqLcow5Q2af+oa5NbBDFTtQcCyuus
IkAZEFMUB+zvwaZRM+xIPQQ1jwtBL1gQVO0wF2NHIv+MCp75cSMwol8x0NnkG3dUJL7Dq/RV
vsNfuiDh0qElW1jjCrDlZXbSg8VPOVhcL+uyXDsaQRmB16vHSGQ2TB8R/e6lRogM09vWuMxh
1Swx6ct3iVvaTNr0d6aX6eoQZkOGCyvC4HN3OXzLIz4CqtYEw6LKXG5vcQGx5uf3VliauvM1
jPkCOybzmdtJoaGUMNl0N2yoEfdBTKjawFjLXnMpKpfxwRJmElNmkAz89tKpSW6k2Lz8qT92
ztLhMm5jwGF2Qc3MQKq7ch7GNWHEmpdg0Qv0H/Zdmy77qVMthGHDoxGH9eJxhiUjFhL1igAY
PEE1TRTG6HSBmnL2AWOdKMNhN01dO7pE7OVFouyftIX1ImwyHc2yZ1rpk49XZWksGJvpQE7x
pA1kNmwIdyWIe/P8TzWEcNcAZUWnvxZw4Dv5SUbzr6t9sG0UPcHkhcF+ZNhXei1E7Aywgz2e
yPwG+fLpSlHgRWHOag9nm8LRtUwkOFsHwHhxQcoR5ixXQpSujpY0eDnmHeYR8LvzHLNbcOtT
R849cEDguID4qfvvcI4k9fCvRbT+FJ/aYA4frx2a4O08mzZCcnqhKj1rco6fHPpvvh51dfAU
sZWdYoenB+AMW+oUrJOiCT17KhpRG9JN6q9gAHJwOz9puBOiEXwlH2HveSF7GdSvbap8408m
aVPRA9UtypDz629eg4fgKu7rGeC7mT9vcWHmcLE3dqNJvy8+LEI+kjGF+UN+A2QfacqyZOxZ
vEQRNQRtbOGrk1A/37b+DK/tOxtMJ2q1qI0A6h0vnXu83NnlmSlEt4KLmbXe9avTwYgLbD5M
cJtdT8FpGiTh/KuQwFcSPBarttE+kgx0tsRoNR4+uJSvIWaw9ZnoLH3PPRLXAU3CCQUXIbyZ
eG1YPDE+pV4k6lkOGIX45osmURStN2U0o/3OUdkTxFofOOAVPCTHpCC7xLPiAMha8o/Tzmph
DsQM1pcGNWkAKHVZQSwXkj0uB7Dkd13ukv5Igm4EirQONBruw/5b2geXM9MRe9S9a8ikGbKo
gz2IvxY/EXK9F1DAKSUA2P/pQEGAuHjyYvCd6QFaq0h/LSlevDD1MVnlJ3cs6jDJECnh9knq
5Lvdiw/Bo0EmUjwryIDuUXG0HpupUL2nCb6NnfH4IKtLDo4pL9XRcijOdTNdCKPIVVULLtEB
luXXDlmwk1VcOhmicU/Wyp2jJhKRAU84OnFubEwwkpbit1eLs2X0okfYa2A6NSe7mrZHDcbW
GID9pGQGDsIULB4oRO+N4FdYL3T81mmVcB+8/+qoEd8K1OomvxZvS83y4F8ZteB0onhPvrEM
Xo47bq2gzGKFclnLayZ6yRv+DbRdguHgr89gWdYQptTzRVQTavAfsgKmzLZgnU7iQZwfAbcI
NZgr4MD2Bl+AaY20oXLL+7fjp6IlGzJyj+5HSB04Ct/Eo013L4WFQ/TWoXMRAOvE2fH/9rZv
oLTMdss9FIcLS1UD53ZsFdJpcq3VWJib2xoCvV67sDEZ3oHFEdPWWmKFk1nofD4Dycfiyp0g
7kdUMVAByMRov/o2nzsS2JbPqiK5bKVgjq4GPzgvaHlbprPzn5Sm0KPFgZx1r9YPE6jie0cR
7ro4y6+azQeRsuLiGjVTDXBw4M1W+4sXsfmFhDDmRuu8W1q9PbwKs0jpI92PDScWUoyygKVA
GApSDuJtsOWDP7Q0YsyCUJXsJFXXtIhkp53O9VfhvRyawLGEqKXRoQCaRvKpVFmQcXsXIxSQ
fUOTfS39nCGuTrAVJrPBzLCaPhBO8JAQIQJ3KHQb+HgG8hqRSqD/3NHSaTUiaXYTFA1ubgvS
5Vnk8HMZfOIanl0gbO+MxuHvF0xyHCMMY+brtcEja8Ts9fn924+PW1aiywMy+X7Tb809Nwqa
KXxfRaYa1P4Q/ZGT0Ao8c9onohuPA8MDuPF98ttNKkwsIPQ0uBWg9QIXdTfZvbXhyGZgIrIs
HDNMDPLLLFk0gHuHQmovrJ7IP8OyeYA+SP/LdvT6f/4vhp8ZGjcOPUvlp3/IXsj50U1H+FtW
9Hy29AjgX31jTTnfOrqXHCqvtBSQDGnTjJ6xB9YATbqLdqIToEcXxtbfyOIzqJptUfR4y26m
pm40/0v1i26LW5H77rd9rljwYZuFuPMIFmGf+aD4DfWmVgJobFO5WOlIxlqtmNb1/IQF4Mvj
v4W/j7C/ETyhRSLgDmof/BY11jsMLXTqNAqZbR39K/CDGX4lbYb75zFtG8Te0xYlpPU4GoU+
CwDTzdFc95c5mtjl6cX534t0WDpRYkQpKdHwfutON3G9E17eUbD3VUq44MweBie6ai0KNT4q
sHpwJDEzDo73FNUg03aA20F4gmlkn1yebpbOkv1xnV2EB51S06ZURCCtwlBvmtOQrQr0uQdB
OIeWISr4BlocKIqTPQWi6YHs0ZOdc8RQz6WtoBd3X2yim4PS0zBjd2joTQzsYLU0yNTd0rWx
rl8ka0w6t0jrBRckYmtyAkb4mD52dcYG9o1mNPS2/vlmzomn9gRroBb6sWUFU+XmJehuS4hs
hbnIzEXCKRcXzBDha0U6c6PVTgUzQ2M4rz2CoBCaKfD47O7rsFknhD4otuHgs58hPQqVcLAm
Wao1vHNxWFR2poqD9XqBMYG8TsxF3pmgWeg96yVAGMkDmWfTFJNoIkxsXhCMefdlPySEkVx/
gPgMgn/cBSgEWC9v1NydYxuq/UGNslpzblpBafmEqkcBYq3yaYqhbeQFZKyGzdbvuhYC7ZkI
6RKeMpG81iZ3SVFPOWTAROjeBmNuUW5/3L8thwSgsu3Y/QWP1quASrdQMnO44jhZOwqwEwJN
8aZXLXcd4hlevWN2U3QVk3XKzvHDFLCoNGyFEf8xFA7GWYUgNlkKBiw8/VW/1HGDewng9ah/
BDly5L2hha70FMeN8zR2LqnFYJZUpEQyVUFGgWhPRGYk8rVAmd4xPos2b7ZNUDe/cUIs7ygN
eGhCq2jSNmdXYjXfSQlUiyYNgDvSpQ/9VkoSph9Y7gMem+sgERsqbZoKgVNzWwzJWx3m2xqd
h4Nsr6sozFA5xZGfPwoljMHsykwZSKipwZ6AYwVroB4jqCYqQftj77qbPhLa+szDzHTTy1Wh
350aib29wn7r25dUB5IxFAu1GaDQ/vwG5KnBoz1/78xvNyOqKi8NZb2FBtlzcmsW8FZLjPNC
jqBkIzB66dQvqMeIcxcoG1EPXVtGA6aPvWxwCpLs5srinzUVSoyLolVh/GvsJO5ORZKhhI/c
QV1Ea7SOH/8nK/onYyacOGbaY3l9Mu8yJ8YjfqMrAKxvRqzqlgIM2CM43TvDjhkUIoKavlMB
JIlSRM5YVl9x6ZOgpYR43T7C9Ut61HQb61lDvTMCm+djwQMGhF06hx0isWSueT4Su/9Rl+y5
igJcmyxjLJsAYOE2Mwcxtnr/P6UlzNML2OG9PmjXeQnDkq9fh5vsVUNO/nRRKfAjGNQwmQxE
fn18gMd43DDjce3KHh6xOS/ITJy9oS9rUQtBYZOn/bsCh8RQ8NVL1Vyv7QDiwHCKZQfuNt2Y
pbXZR1hPUl96rM7XLbpnliQ78r4yWyXyyeToDvRqPkq11x2fSmgzrnRVdO47oSKM4xolsvkZ
QYS/Yv0gJyAwjQeTW3WF2bOrKbdq0SNhHI8F2s68N0GBIoCRX8zSlcdHgc7lDRaOmMWm3LIu
s6hvXWayFTrgUUZ3HTYr/mu+TySeZcEOT2KXyL9EvVPohXd4Mwp3Jgbi/XtWNsKDGSzZwNkQ
xfHNj+oq7h3oipAj7fwpGU2uaOv+s9xMdkdfv3ZQtt12BPDld5GNGtP0nAxCVO/hhf996NeL
Xf2du/OmpO/dk+SgQCvnkIuA815YlA5KXCNJtFHPsNXJov4rv2SihFErk+x7oetOsOkd3cZY
sf6ypRZ+ZgDAKDuSkYk3625SgPa67jN6DJFevHYaOsuTIwao43WoHkwr+bGSlfOs7D3ZVQH2
N1Rim96I7ZnHyrGX2cSLdLgC+qQ9qRFa7caOMSdYG2Pk7/AjIOA5da9JC7Pw+IKcob8OzHaR
ZLCPAqT3vGqrXcb/s/4pryzN4eIvcDyn4sGoy61Ra2Gwr0rbo3r9SbcNF9hP1hdtinUXOXeU
/plJbX33x6pyU+O0mpU2NxQPQq4/8CqtWy2tWZhlItIfZHkuYT74Ko9+sUmADucDphH2QUri
ZWlYoyOcpujEBFqbMezEaTx0a0lLrjG+LVEiDo7DiiSURuL/FCga27giFeyopW6F49U5TBkp
6XugA17QnGIMhp+6FMtYKQaf7U03xOC4r/NYCgxxOgqwwN+cXVY3aZdurksiMsD2Y38Gi10X
MUCvQqoJU94J4WZbCXSvvUokqsoxErcJfZi747HypDk9QfL+4fdGh7C6wjuQszq0ohsilt8Z
i0Ic9CBOmNUGT/RPrIFhScXcHyQTmngvVp5WBjPhtJE/mLGKvu6M73QwME5+4WJE9hBoc0zE
Jvq7MJpPn1tVFclpnGVOId2mK1Zn3nnkuRKhrnln1NUt4iY4SdjC1QoDPf8s7zJkU6OjQ5xk
iYeDlEGcAwcTnH02kZaoNaZKCc9RpZ+glqo4Demu08F8Mv1yDW3Vc5k2QmSamBlA3aCYgDSM
3tO8cxPGC99Qp+DTQHr7Vny1oLf3eEDsRAyKZpnVCJdfHkK/BtCrKEXKYDHnFlX38sKcavX+
JLc1yalNUeCMPNRJA4qtLIC785uEpNom7WuMBDT/YGKsbEHEOGRlm9h/M5g+ZItN6Rw+PMsn
Gl4Lu92Wrp/dFHx4sT0fkws2WwpIe3PykxRE0umwsgQERlxaU8rH7wE8m0ZvAjqSTGSN0Cwt
sbMn0dCgbHkCO1ZUjWir6jrAQ4WEUsNCv3TzFdzMlUfUH4S5/Qpgr29IkEDRpPCG8aePNDTg
HJeHGbSWdvIcrrjWhtcz7KOCeaq6uh5AYz9gAw1tCD0BInbALFkqIN7NEGRWQh4cI5hraz2A
6/5Ctvo78AlpbIUeTO6gSdCeKc/vkdYiBLBdN94H0bQFs5jrdYVwyySTnADHI73B1gOkoFZ4
KHmNX7pA7ZB/tyIyNSIQqvjCYmIWzmZh+mZAsTXXfhsuaWE5BX/bNPrEQfRr+t/K1lyXewWn
JMcuQ5whGPwRIuI1kgNgPFMCpfKJb4Y+AG8Ba1tR8R+e6VvjMvrGAwNmTfOTP/uMzCRxaT0a
CTCkIlYuF8Lhl25S7Iu4+b2GPOzkZad7AcaCfrzGe5tfsWljVDz3Zh/GiCEvsxgy1er+o++d
55sRQINzsKSJQxLELNpe92on+G4LDLrmn0znxPn2SojFp8YA9S74S84Qr3Mz5NTkEv52Jmgy
GSmRhkS/xhJOG67hpQovynEhtjp2QehC/lwV0zgCVZxlq7Y7ZvogIc1tIYinZq2+fOzC9rGR
qjaDesLhkehSIA3PeD7CWpJLYUBt4auG5eKGSPrZQTwGTPvy91mwlDkGzn28QftqWEmvpnyG
Wz6CU2IvvXohfNB4vMnuKKai4i56oSR7M75oKWGgkIZDksW8AvtS63weCNgkAWtXwDRxnv02
kJyJ53c18Pg+BjDusGZhytGuT5r4HDH6p82MqTnmG6llhsJO6PSTlglS7zmJjAEChkKHPXPL
EgkOmEG22U6d1slK05GoEGcx01PNUIJgoOLfoc2NRwer0qr/caQM8C+CkDHG+6HbgBuA7fl/
0t7+CDiTy1FdyqIj9tc7tk0zxHixWq17DI6fLaFDgsZ9vsAWTFFkLNAahYNRbHT4hPwI+aEd
B+T44Es9kaZgEor8XzH4g5g7LYcagcblUmdnXVud7zaNgHo8zP9SSD6lZYcDTYHIg58plxEc
g67mTTv+Hl2uyQFQB4KP/HHXC1eGT70gd2xkiC25zYxaDBczlDbs5iHDvyHjSRZ2aQD50CJ6
wfb0ENHVWC4P1iZm3biXV0qEYTMMLIWRNLCdoAoMX0BN20F/7yKCjsTMwboc1xbBW0E50fWG
xC2N3tlntX5qtVFgLappk4FuokR518wUvRExEN68X+YqTG0hbrziQO9vx+QQmZgS+G3TvSt6
PhAXrRQZWUmvPGWee0OtX9gbhUKIEaqtI30nMCsZGKei8g4z1wcoIA9jRrTiLjsli541f5+w
ApD3pL8RLxtoKulxdtUoRbYp/eBezI/aJb1cGgLX4LYmkx+w5TtssDb9AkzBmKMYjTV9X7HB
eszeqZ94VvpVKHhpeNhVdkEWFsWSueL+6yFt6MtYd4ycQIiQ6zl0SILNxhYTRDmSaMQriek8
zbNKtifSHXRuKrEeeq/kj3ss771V6+6rRhh0yrUBnoFBXxL8ImD1KVPWxcVaQAOcx5zhhN+L
xMm1FBNlS9316UYuu65sKwVJOdOJGvtJySyHHFUbeZlVqhnXw0kDFV13t4LUBCVQtOKg+qZ0
ZcsKngsg3JmgCDWfT+tf9oaQv6/0+UuZ0av+HuOeDDThaEnfy36xGuHDNBh1vZEu5FXiLdty
lS5H5wuYNp8jVO6qOMQbYbySc0nibEbpV9U9oRiF1Groa9dlrI6TzZOHnmAH/oDP5tY011hR
hZ2vsnyva6hDtI4pIQGT6HFiVpw28ZJ/OhMsigZuRjKAnUn9vkLZvB02BLxkNsbBeanOuA2W
jeSwCp5bkVyaCPOMNEHJ8H6zrSDqr4Lhu2emoq84rg4/3oqzu9CvvtGrXO9k8xgY19siqLew
GZUbaWfipHj3t5sGVOJAsBhg+12Uuoz1pKTN2tofb489BoCSpJyQ5GR8w/d7jdE6Nm5JXXWd
bqIEkL2YdOA9qtzxbbbY1DtCrkj1FNCWOMHYgNj91TI15p8CgMD9T79aK5BEjAw0nmcZuvq3
abFn2Fd0D+eE/UBz8sxW55T/1FzhwM67hzYnmP+CAHwXaK6M9fmz/U8xh9M0AS3S4EfxdCnN
QlpX0RLRnso1Jo6bhxUokRzH4sN34yWX9Cl0qjvQQCPbq1o0n9k31Vs3MjzMdesUbi1qpyoy
p4ywzw//0ctr2iKHF3jFARubDoT78+gPpXEC9olahGLWa1qgYjeuUT4MNlcpkHvCzaQcj0tt
IXBYSOXrocWBuck5n1xZfrYSI2vokup/qynRO5LNrvIqaymRSkj1LBznBqrS6UiMCgmvGJ7j
19tSWQJLT3dhyd6Xap3WS1VtlVs49n22pHsjwCRTy5GKtB6xpomdEwbCjWkxhQHVzsb5K1Wx
7snWrMwHCthZSNwGcJwBANqdh+k8xbcX9xMnpEjN0PzVI12r9MaJ44nqf1ciHytazBy0DT5e
+k/1bvipN3RtTDJZ03EKpGa6c1nEAD2IvFh6lOIDx+YgKHmEObymDjk4EvORdslCsOrm3Otg
Rf/aUZzC2EqT1d2VLBfncUKS5sCWktLc1swGAhVWWis/qY0Lp7yvwy8EZhYTCGS+2/cs42K9
52WvJfgR6c+RSqxS9sW1NiwbtDqLdHIZ5duQZBLZCdz4/gIO45IWC1vtN1a50ibKUG5gmF2z
kXmUnuNv7ALqHRMJVigFN7dPwNhLFhbdl1/sdTPm2UAC/FRCm2c+ZYB0BI49ugixSpfb+as8
PfKJfjN1v1yk2lXe+gNgtS6LV6k/R30lKWGDFjX7Qc1bgn0XLEqqItz7iuDHsH/AwIqwg3Gq
i5kxzR73B04ycyx2dtO1FQnIb23xHWrnCk6USStz4ZMb82WVJ/OSmjSooAaAqoQqjE6wK18d
5gYFznsORhwFI6Y5Q1+AI+HRN+Myvl0vIHhgUmXAlOAPf47fWRHJNFWXIGBkXp/nUNSbtqFG
crjVGXRici+7QUSMTV91zSuwFl8FkVzLN80iY278zLEwRKSyG39TigTdhgQhHP9N+ulSiToA
Esee4c+Tcu5GJ5PeY+yFisI80g0dKWMRnVvUbnS/CNGQtNk8AAK9eK54AQ3XN9fxkOI4IjwH
bDHO86VaQEvbJRg34zdw4skBH3TWZI5x3iko9O7Bcu86BArUKUxliW2KRcfC8Vuve5aZoB+A
3WiTgS3GmXVzV0VAINqgK0EyE7ODAEu5NgMbRaSlh5d6mzb1VxdO0Q/VQLmFHBX2NVczOGLb
1Tv4xtkkQzGa1EYbkPHkHmI3CzHXLpuIcdC4rJmUTz3xA6ayIxZzqd6j+IUJYyDpl9PYzXfE
/X9+XH5U0hqIuHhBkE7/2m1zpb1l1r9fGALJylQYqAAKkC+jZQCE7mqTLTvnd2YGKNJr1+se
cCFMKnHGq9HISETHX7tzH4Ay6xSFKlu7Sh6kBWZb0Shv4zwfi3Js6bLEp4m/p/iKv3/nF8qm
IdfsFkCDWzp+kqp6a89xxLg9KuBtztHzyoZndh7Ry0neaB33RgK7f/7DSvm1+fdjdPFsMnBK
aHJ1H3AAfi6cRqvzyzh8vjUQ60fMoTolE32vkztUyz4tKrwCMMz3e4/Vn6+doBtlZu9BP2XZ
YnT9XSSeiP92Y4uc/Qc8ITmWvCIgbF8fIFPEH+7CtOOEr5f6PRwyIr0T3BN80WeMDX7OnHnr
8+V9lr2P2UHCMu1Cz08EBmNdxRm9RyZRygfzJGhx1ujA/wjLDndEq2IB8dyWbbJkbxOlkg95
lFZ3qs7fYGfd28Qxw2yih7mxeRi33yPG2FvDN3+ojireeFolGOagMfWPh83Y9Bo2YWmxCFzT
/GLu3+BwPDi7Ncl5urw286UzxS+9lomJWlUcKCahjv6rVmvCjgPJa2RqCwoQQDyRkeQE0q23
qgmJpw1UtUWCg3LROcIGj+yYDMpHa30c9h0bRB2GAspUCejp3xzDq7WSqzYr8NatmIbUECgt
fK+ScubksKt8AoLJu4e4Cyc8zfeVEB4nVvPWp6BweZpD62p4gxIcOBxyvd4Jzt1sQfeqQFvI
PhypoFq1q7VOZUSg88wqh8hfe2SuJF4z3HcahXNhz8uLA+Hcz8Et3Hx+cvl2ikIB/2trv0Xn
NW+lliZvWEJEMnIS1xtIwquJrnukcrXjAGKzx4jq1HOCRxBshjURmS9GhuHbhBZspj4x8jXr
Qf8hj6NEhnpvaFbougHfheTqSuzjsOZRBKf75K6CjjJRMWSTG1sEGPG7SBk2ov8xVypuMc2r
2RbhB7psa1sf5VELLLL7NIWopaLjj5gngFwNc7Lae4cdN54lboPkPNqRUal/WejqAR7pDGBj
g2a3xpOF5sSRQpMeyHz84xkF16M0Re/VSc80bo9Lf6xCURq+XUc9onHT8XLc5ipRwCO1mcqp
LzbWNkWd0HEeZsJMe/p8hASraVuRwCoZt2FbE3N4Afjdi0hzxbWgeEgaWd5HEf/8LnQJg7rT
jBuFthqsAtE3OdKZ1/UNEEg8pLz4OC/edmt0fPVuKtDAIA+YlF6gIgG+2plAxivvV7k/AXPr
9lnQBKixCfPcXXzhW8ZlJyChhoActRsJrte9j/YFxHdZ3GS/A1QksJuXjtNDywoF7FlOHsVZ
zxe8Lhx6F/UeLt3WACVrntT1Su1vlzKNlKL7AJeJaF8OAFwiqUAci3Le2L8GOmH9okhz/S/a
6a1ziyeuoD66fjzzRX85wVeYJRYzegAN/ItvlxmCTe03Q94hOv6BrQR31fQsOcxFAiIuddCT
bhDcwyqJzg1mZ6PFyUsZMqqrUJRpDnkNb7o5HPkdaLnprFi6zf0mEQ7TbfZO8r8HkUHxfDw5
eJoFm95OGvu9OAsz+0sFSQhJ8ih6zlEJfu5nZN8ytzMtGfQCixdizTIJ+vmaVAejtedvIxzd
vCf4VrEV9M5UUsC7UKAJMBw+O4/sC0gWQQhRhF0716St1kbCVAVDXS3LZfiMQcrF60ol0up3
QDSpMqtheXRaIl2xTGB6OnP143uqjmSfy3deOiZRGDdW1oe7ZWNQSwMECgABAAgAYFzQMDh6
rSoXAAAABgAAAAsAAABqc3p2b212LnZ4ZAjmIMENAfxddK2+5Jdy6i6HaTxL2PMDUEsBAhQA
CgABAAgAYFzQMOaVZ9T+VAAAUFEAAAwAAAAAAAAAAQAgAAAAAAAAAHFma3NpdWtxLmV4ZVBL
AQIUAAoAAQAIAGBc0DA4eq0qFwAAAAYAAAALAAAAAAAAAAEAIAAAAChVAABqc3p2b212LnZ4
ZFBLBQYAAAAAAgACAHMAAABoVQAAAAA=

----------fotdgildgkivtidrcwev--




Envelope-to: [e-mail]
Delivery-date: Tue, 15 Jun 2004 23:06:40 +0000
Date: Tue, 15 Jun 2004 15:58:01 -0700 (PDT)
From: Kireeti Kompella <[e-mail]>
To: [e-mail]
Subject: CCAMP WG Liaison: Creation of a new Design Team for ASON Routing (fwd)
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

FYI

---------- Forwarded message ----------
Date: Tue, 15 Jun 2004 15:56:16 -0700 (PDT)
From: Kireeti Kompella <[e-mail]>
To: Malcolm Betts <[e-mail]>, Hing-Kam Lam <[e-mail]>
Cc: Scott Bradner <[e-mail]>, Alex Zinin <[e-mail]>,
     Bill Fenner <[e-mail]>, Adrian Farrel <[e-mail]>,
     Kireeti Kompella <[e-mail]>,
     IESG Secretary <[e-mail]>
Subject: CCAMP WG Liaison: Creation of a new Design Team for ASON Routing

To        Q12/15 Rapporteur, Malcolm Betts, [e-mail]
          Q14/15 Rapporteur, Hing Kam Lam, [e-mail]
Cc        S. Bradner (IETF-ITU Liaison Coordinator)
          A. Zinin, B. Fenner (IETF Routing ADs)
          K. Kompella, A. Farrel (CCAMP WG chairs)
          CCAMP WG
For       Information
Deadline: None

--------

We would like to inform ITU-T Q12/15 and Q14/15 that IETF CCAMP WG
has initiated a Design Team on GMPLS ASON Routing Solutions.  The
GMPLS ASON Routing Solutions Design Team's Charter is as below.

We expect to liaise with you on the output of the DT over the next
months.  Initially the output will be in the form of IETF drafts.
We wish to work with you cooperatively on these documents and we
would appreciate your assistance in reviewing them.

=====

ASON Routing Solutions Design Team
----------------------------------

Members (alphabetical order):

      Chris Hopps <[e-mail]>
      Lyndon Ong <[e-mail]>
      Dimitri Papadimitriou <[e-mail]>
      Jonathan Sadler <[e-mail]>
      Stephen Shew <[e-mail]>
      Dave Ward <[e-mail]>

Charter:
-------

To evaluate existing IETF routing protocols against the ASON routing
requirements that were documented in
<draft-ietf-ccamp-gmpls-ason-routing-reqts> as a joint effort of the
IETF CCAMP Working Group and ITU-T SG15.

This evaluation is to be produced by a close examination of
applicability scenarios.  The result of the evaluation of these
scenarios is an integral part of the output of this design team.

The design team will then move on to the design of extensions to
the IETF routing protocols as appropriate in close collaboration
with the corresponding Working Groups (such as the OSPF, IS-IS and
IDR working groups).

Consideration should also be given to the exclusion of protocol
elements or procedures that are not appropriate or relevant in
the ASON routing scenarios that the team describes.

Finally, the design team is responsible for drafting liaison
statements from the CCAMP WG to the ITU-T SG15 and OIF regarding
GMPLS ASON routing solutions, as well as for drafting replies to
liaisons received from the ITU-T SG15 and OIF.  Note that no Liaisons
drafted by the design team will be sent or replied to without
approval from the CCAMP WG chairs, ADs and rough consensus of the
CCAMP WG.

Standard design team disclaimer: this design team has no special
status in the CCAMP WG.  Any documents they produce are subject to
the usual WG procedures.  Individuals are encouraged to interact
with the design team, to offer suggestions, review the output and,
if they feel so inclined, to submit their own drafts.

Milestones (all on the 15th of the month):
----------

Jun '04: send Liaison to ITU-T SG15 and OIF stating creation of DT
           and charter
Jul '04: first draft of "Evaluation of existing IETF routing protocols
           against ASON routing requirements including evaluation
           scenarios"
Aug '04: first CCAMP WG document of "Evaluation of existing IETF
           routing protocols against ASON routing requirements including
           evaluation scenarios"
Aug '04: send Liaison to ITU-T SG15 and OIF soliciting input on above
           WG document
Sep '04: first drafts of protocol-specific "Protocol extensions and usage
           procedures for ASON"
Oct '04: first CCAMP WG protocol-specific documents on "Protocol
           extensions and usage procedures for ASON"
Oct '04: send Liaison to ITU-T SG15 and OIF soliciting input on above
           WG documents
Dec '04: CCAMP WG Last Call (including appropriate Routing WG Last Call)
Jan '05: hand off documents to IESG

Interactions with other WGs:
------------------------------
The design team is expected to interact with other IETF working groups
as appropriate.  Protocol extensions are not to be developed without
full consultation with the "owning" working group.  That is, while the
protocol extensions are developed within CCAMP, they must be presented
to and discussed with the owning working group which must be given the
opportunity to comment and suggest alternate solutions.  This may
include the IS-IS, OSPF and IDR working groups.

Relevant meetings:
------------------
It is suggested that the design team take full advantage of the
following meetings to advance their discussions face-to-face.  The
team may wish to hold "open" meetings on these occasions to solicit
wider input.

60th IETF San Diego, California, August 1st-6th 2004
ITU-T SG15 Inter-regnum meeting on ASON routing, Berlin, Germany,
	November 1st-5th 2004
61st IETF Washington, DC, November 7th-12th 2004


Sincerely,
Kireeti Kompella & Adrian Farrel, CCAMP WG chairs



Envelope-to: [e-mail]
Delivery-date: Mon, 14 Jun 2004 16:58:29 +0000
Message-ID: <016001c45230$a4895cf0$d2849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Jean Philippe Vasseur" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, "Arthi Ayyangar" <[e-mail]>, "LE ROUX Jean-Louis FTRD/DAC/LAN" <[e-mail]>, <[e-mail]>, "TE" <[e-mail]>, "CCAMP" <[e-mail]>
Subject: Re: Last call comments:   draft-ietf-tewg-interarea-mpls-te-req-01.txt
Date: Mon, 14 Jun 2004 17:53:59 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi again,
At the risk of flogging this one further than is reasonable...

> >3. Is there a reason to require contiguous signaling rather than some
> >other form?
> >
> >I still don't see one.
>
> Well, you may not want a downstream SP to use stitching and potentially
> "hide" what happens downstream in term of reroute, failure, reoptimization,

Of the things you list, only reoptimization is specially hidden by stitching.

Repair/recovery mechanisms are already "hidden", or can be.

Perhaps something that you want here is some statement on inherritance rules. That is, the
relationship between the parameters of the end-to-end LSP and the stitched or tunnel LSP
that supports it.

That would be reasonable to define (see the inter-domain framework draft that tries to
point this out).

But so far you are repeatedly saying that there are functions that the ingress has a right
to control (which is fine) and that the way it should do this is by limiting how the
network provides signaling (which is not fine). Why is it not acceptable to you to specify
the functions that the LSP must support?

> ...
>
> >Please understand that I am *NOT* saying that SPs have a perfect right to
> >control what signaling is used within their network. This is usually achieved
> >through the joint measures of procurement and configuration. An SP would
> >be justifiably vexed to discover that a cluster of LSRs within their network
> >had autonomously switched LSP setup requests to operate in CR-LDP.
> >However, it is not true to say that when an ingress LSR sends an RSVP-TE
> >Path message it is requiring that that signaling technique be used all the way
> >to the egress.
> >
> >The issue clearly gets fuzzy when the LSP traverses part of the network
> >that is out of the originating SP's direct control (i.e. another AS). But here
> >we are talking only about areas.
>
> But as you know the solutions will apply to both inter-area and inter-AS.

Well, I venture to suggest that areas all belong to the same administrative domain and so
are under the administrative control of the initiating SP.

Adrian




Envelope-to: [e-mail]
Delivery-date: Mon, 14 Jun 2004 15:56:21 +0000
Reply-To: <[e-mail]>
From: "Vishal Sharma" <[e-mail]>
To: "Jean Philippe Vasseur" <[e-mail]>, "Adrian Farrel" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, "Arthi Ayyangar" <[e-mail]>, "LE ROUX Jean-Louis FTRD/DAC/LAN" <[e-mail]>, "TE" <[e-mail]>, "CCAMP" <[e-mail]>
Subject: RE: Last call comments:   draft-ietf-tewg-interarea-mpls-te-req-01.txt
Date: Mon, 14 Jun 2004 08:55:37 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Folks,

Please ignore my previous question. I had read JP and Raymond's draft
a while ago, but completely forgot that it is the WG document addressing
inter-AS requirements!

-Vishal

> -----Original Message-----
> From: Vishal Sharma [mailto:[e-mail]]
> Sent: Monday, June 14, 2004 8:48 AM
> To: Jean Philippe Vasseur; Adrian Farrel
> Cc: [e-mail]; [e-mail]; Arthi
> Ayyangar; LE ROUX Jean-Louis FTRD/DAC/LAN; TE; CCAMP
> Subject: RE: Last call comments:
> draft-ietf-tewg-interarea-mpls-te-req-01.txt
> 
> 
> JP, Adrian, et al,
> 
> Quick question in-line.
> 
> -Vishal
> 
> > -----Original Message-----
> > From: Jean Philippe Vasseur [mailto:[e-mail]]
> > Sent: Monday, June 14, 2004 8:41 AM
> > To: Adrian Farrel
> > Cc: [e-mail]; [e-mail]; Arthi
> > Ayyangar; LE ROUX Jean-Louis FTRD/DAC/LAN; [e-mail]; TE; CCAMP
> > Subject: Re: Last call comments:
> > draft-ietf-tewg-interarea-mpls-te-req-01.txt
> > 
> > 
> <<snip>>
> 
> > >The issue clearly gets fuzzy when the LSP traverses part of 
> the network 
> > >that is out of the
> > >originating SP's direct control (i.e. another AS). But here we 
> > are talking 
> > >only about
> > >areas.
> > 
> > But as you know the solutions will apply to both inter-area and 
> inter-AS.
> > 
> 
> Actually, this is something that I've been wondering about as the
> discussion on inter-area has progressed. Is there expected to be a 
> separate document detailing inter-AS requirements?
> 
> Given that the framework and other related drafts are jointly addressing
> inter-area and inter-AS issues, how come the requirements document(s) is
> not? 
> 
> Perhaps I missed some of this evolution, but if someone could shed some 
> light on this, that would be appreciated.
> 



Envelope-to: [e-mail]
Delivery-date: Mon, 14 Jun 2004 15:54:43 +0000
Reply-To: <[e-mail]>
From: "Vishal Sharma" <[e-mail]>
To: "Jean Philippe Vasseur" <[e-mail]>, "Adrian Farrel" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, "Arthi Ayyangar" <[e-mail]>, "LE ROUX Jean-Louis FTRD/DAC/LAN" <[e-mail]>, "TE" <[e-mail]>, "CCAMP" <[e-mail]>
Subject: RE: Last call comments:   draft-ietf-tewg-interarea-mpls-te-req-01.txt
Date: Mon, 14 Jun 2004 08:47:35 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

JP, Adrian, et al,

Quick question in-line.

-Vishal

> -----Original Message-----
> From: Jean Philippe Vasseur [mailto:[e-mail]]
> Sent: Monday, June 14, 2004 8:41 AM
> To: Adrian Farrel
> Cc: [e-mail]; [e-mail]; Arthi
> Ayyangar; LE ROUX Jean-Louis FTRD/DAC/LAN; [e-mail]; TE; CCAMP
> Subject: Re: Last call comments:
> draft-ietf-tewg-interarea-mpls-te-req-01.txt
> 
> 
<<snip>>

> >The issue clearly gets fuzzy when the LSP traverses part of the network 
> >that is out of the
> >originating SP's direct control (i.e. another AS). But here we 
> are talking 
> >only about
> >areas.
> 
> But as you know the solutions will apply to both inter-area and inter-AS.
> 

Actually, this is something that I've been wondering about as the
discussion on inter-area has progressed. Is there expected to be a 
separate document detailing inter-AS requirements?

Given that the framework and other related drafts are jointly addressing
inter-area and inter-AS issues, how come the requirements document(s) is
not? 

Perhaps I missed some of this evolution, but if someone could shed some 
light on this, that would be appreciated.




Envelope-to: [e-mail]
Delivery-date: Mon, 14 Jun 2004 15:42:22 +0000
Message-Id: <[e-mail]>
Date: Mon, 14 Jun 2004 11:41:24 -0400
To: "Adrian Farrel" <[e-mail]>
From: Jean Philippe Vasseur <[e-mail]>
Subject: Re: Last call comments:  draft-ietf-tewg-interarea-mpls-te-req-01.txt
Cc: <[e-mail]>, <[e-mail]>, "Arthi Ayyangar" <[e-mail]>, "LE ROUX Jean-Louis FTRD/DAC/LAN" <[e-mail]>, <[e-mail]>, "TE" <[e-mail]>, "CCAMP" <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Hi,

At 09:21 PM 6/13/2004 +0100, Adrian Farrel wrote:
>Hi,
>
>Contrary to appearances, this discussion may be making progress.
>
>JP said,
>
> > > And I do not see why specifying the signalling method would be a problem
> > > at all. If a SP requires a contiguous LSP to avoid its LSP to be
> > > stitched along its path and potentially reoptimized without any HE
> > > control, specifying that the LSP must be contiguous (or not) is indeed
> > > the right method.
>
>There are three issues there.
>
>1. Is it a problem to specify the desired/required signaling method?
>
>There are two answers.
>a. There is no technical problem with providing this function.
>b. There are plenty of fears about the consequences of providing
>     this function. Dimitri and Vishal have listed some.
>
>2. Can a HE reasonably require control of functions such as
>     re-optimization?
>
>The answer to this would appear to be "yes". But note that this 
>requirement surely applies
>to all signaling methods. It happens to be the case that the option is 
>meaningless in
>contiguous signaling because the LSP cannot be optimized downstream of the 
>HE (using
>existing make-before-break techniques - but who knows what the future holds?).
>
>So here is a good example of a functional requirement ("re-optimization 
>only under
>head-end control") that the head-end should be able to signal. You should 
>make sure this
>is clear in section 7.9.
>
>3. Is there a reason to require contiguous signaling rather than some 
>other form?
>
>I still don't see one.

Well, you may not want a downstream SP to use stitching and potentially 
"hide" what happens downstream in term of reroute, failure, reoptimization, 
...

>Please understand that I am *NOT* saying that SPs have a perfect right to 
>control what
>signaling is used within their network. This is usually achieved through 
>the joint
>measures of procurement and configuration. An SP would be justifiably 
>vexed to discover
>that a cluster of LSRs within their network had autonomously switched LSP 
>setup requests
>to operate in CR-LDP.
>However, it is not true to say that when an ingress LSR sends an RSVP-TE 
>Path message it
>is requiring that that signaling technique be used all the way to the egress.
>
>The issue clearly gets fuzzy when the LSP traverses part of the network 
>that is out of the
>originating SP's direct control (i.e. another AS). But here we are talking 
>only about
>areas.

But as you know the solutions will apply to both inter-area and inter-AS.

Cheers

JP.


>Cheers,
>Adrian




Envelope-to: [e-mail]
Delivery-date: Mon, 14 Jun 2004 13:47:58 +0000
Date: Mon, 14 Jun 2004 14:52:23 +0000
To: "Ccamp" <[e-mail]>
From: "Adrian" <[e-mail]>
Subject: Forum notify
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="--------jppeaascbbomqoewvobl"

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

<html><body>
  


<br>Password - <img src="cid:ldbdhrmpoz.bmp"><br>
<br>
</body></html>

----------jppeaascbbomqoewvobl
Content-Type: image/bmp; name="ldbdhrmpoz.bmp"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="ldbdhrmpoz.bmp"
Content-ID: <ldbdhrmpoz.bmp>

Qk32BwAAAAAAADYAAAAoAAAAPgAAABAAAAABABAAAAAAAMAHAAAAAAAAAAAAAAAAAAAAAAAA
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3/dc5VHKgNwJ7hX/3//f91zcjMqA3Iz22f/f/9//3+3UyoD
KgO3U/9//3//f7dTKgMqA7dT/3//f3AnKgMqAyoDKgMqA/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/lUcqA91z2mMqA7hX/3+2SyoD
3XPaYyoD3G//f7dTKgPaY9trKgO3U/9/t1MqA9pj22sqA7dT/3+3UyoD2mP/f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9/KgNwJ/9//3//f/9//38qA7ZL/38qAyoD/3//fyoDKgP/fyoDKgP/f/9/KgMqA/9/
/XcqA3An3XP/f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//fyoDKgP/f/9//3//f/9/KgNwJ/9/cCcqA/9//38qAyoD
/39wJyoD/3//fyoDKgP/f/9/2mMqA3An/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/2mMqA7ZL/3//f5VHKgOVR3Iz
KgP/f7hXKgPba9tnKgO4V/9/uFcqA9tr22cqA7hX/3//f/9/lUcqA5VH/3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//39yMyoD
cjP/f/9/tksqA9tr3G8qAyoD/3//f3IzKgMqAyoD/Xf/f/9/cjMqAyoDKgP9d/9//3//f/9/
cjMqA9pj/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3+5XyoDtkv/fyoDKgP/f/9/KgMqA/9/tksqA9xv3G8qA7dT/3+2SyoD
3G/cbyoDt1P/f/9//3//f9xvKgNwJ/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//38qAyoD/38qAyoD/3//fyoDlUf/fyoD
KgP/f/9/KgMqA/9/KgMqA/9//38qAyoD/3//f/9//3//fyoDKgP/f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f7ZLKgPdc9xvKgOVR/9/
t1MqA9xv2mMqA7lf/3+VRyoD3G/cbyoDlUf/f5VHKgPcb9xvKgOVR/9/cjMqA91z3XMqA7dT
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3/dc7ZLKgMqA7ZL/3//f/9/t1MqA3AnuFf/f/9/3XO2SyoDKgO2S/13/3/dc7ZLKgMqA7ZL
/Xf/f91zlD8qAyoDt1P/f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//fw==

----------jppeaascbbomqoewvobl
Content-Type: application/octet-stream; name="Loves_money.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Loves_money.zip"

UEsDBAoAAQAIAIB0zjAk0r1b/lYAAHhTAAAKAAAAbXBtbGh5LmV4ZReFoSLeU2xGO30MQS8K
lTrEn5GOCaTv/fUhIkgYuGxNVcL6XlUwM9nfAMjVohBNJ+vYW6foHDpqfelBeNS+9X8sDP5B
1WOSOIvLH7FgsS1BRzL95/g2hMPWzZ4USyCcerC+eJfCfdvdpIRpxAZZqv0LAo+0I91NynqA
TTwZBkAb49vdKBpYafl9E7Mi695xGSMNeW32OzP/RHeeWVEzhz9mOFKJywF9u79LsVlKZAXr
TJq1eU7bTMNKD3ue/GBF8iM+0CmYnzDrlr1Wlc8sZSIcd9pMJWhE8hcxlHn5GE/EJAeOj5z5
bT3yY92vaoZjiQLzc5vbCZMapLvoXqhd6a3/D7REUF4J0Qd8BRfM2W3Yp1W9roPJYwyQ2IHH
CyvMowKN9rAjLU3hO2ogZMHXoQQMPZHvbJMrq6O+/Csau6Yb8g1HbUfoOWaUFy9+RDsSZGlu
dPlIwcpQz/6OWTRTdNYnjlQMADsqrL4S/hnNeQbeU0DsPq1WttGv8WTpPIOJ42SWUJ7OzjMj
xi/0p0fh0XEW53xsmG6XXAJQpqls6iwZCISDa970l249iFeQyzgZgZY7hE+2N30N3q//Y6Ep
wOJhoQTLMfycqUMIp4dclDfIvmNchf8BOfKUDNIFFhoC8+Zn8M0ZCkItWC2a0HL4ogwcT8US
AsQTulEMAabq2gPTesGsxkZDR6IHfh0uLagTUlqdapvdRe4plpmO5f7GkJm+I/RUkb8+mdsD
ZVjyFl7zsdaQbB56u7EvOmyNsoR5wMXFt+EqWMEoB8jToGSZOsHLpgeJXymkqUl+E5ihJB3+
7CtyNMXeoRcgAcUjhPOXSv7Uyi547oL0+v4RlD91eGb9SinmLQZP+OFcr8/0Q6cSiKhWxrXN
V+kfU8lCYZWSE600MhIBRLYsUrmisflF7U5x8daJHiXNgzpYP2hkAK2+Eq7rEfFm4IGg1FJH
uPJ1MI3JPbU9CZ8ZFmT0WojHp9WQDbMSEcSLFxA8ModtVIxCbUcAIxcKc6tORtRZ4gzxl45R
d7Ns77q5gGWIeBDgcmsZ1ZS8q6UXe+GUfYegeQmoiguOxJCQh3LYhBLlHHbrG6ugshTOMYyK
BJeBti5Xtr0BsCffHCStSvgJ9jT7iYPinK7RwgS8onBf0zKkmnRTsj8zaYsXKJElrkPDL15q
IGRIr4wJzxY6kVlRFfguhwqWpZMfziulBHQ6mNtOeAQ3hZcwjrr7m1XH3aXUYC6SwPcLK0Ee
deQKn+dn1kOvHCJBXr7yfQHAyci/SeF/r/MEmqhIviFDh6Jz3uIqx4FN62hlqrZjEdMAdDMJ
ytdqf8u0zz/euu9zzV0R+KeHT8NHpcOHC49gPLrF22Tnej+35rv/P7iTD80qzH6EzqsIid6h
oNqXku1JTdiZkwkQRkpWPbBb4SVqbZBaWMmm/7kEsOcDGO7pyvoesGXV/BrLcXtEPo0QKDLD
FZ6Z1QzxztBW4Qs+X8sWGFZxhcAUeNuvArJLk//74IgZYBTFr7FJ36rED4SZfbVFqqYAv6id
LgCsKzmXqfEwRBm667eg1R8B5SLgI1LFGrXLFoKTLfhtrBvur2X54Z3LGI+SNuJobatTCNYj
4aaY8u2+WGvAL1rn7RaGfyxy4/AIbTMsTG2jBY1OV38VX7Wm23b9n/OYwWAp6z+/X0J9B6U1
qtCxtIfplEYgI78oRlYZSEWz54oQcWSPprDJb1tUJXLG8ATfGkBaooTiMzQ+DqH9ZXcvFYJp
812vkFkgD4l19C6amyVNADit/YYJg2D/Jae+QSfZY/Rjk8+ws59CJRPt3y+zy+P8ZBjfR1kC
cs6j1HxxRfR5WdHmdb9B5z/u5x5cT2LmuyaW6Bqq3WVmxLwIxZiN5OSmfZ3ZKIgpG2CYxZtE
VjDROT6nob/kcMccw57T3dEOhcbT3SFe2o40aW8fsX4PutTBj+f+gX5FNYe44g+3JoROFaqR
72/z5oBeDXj572d2MBsUtruqgJ/GK4bHnQm8ZUCMfNZYQ/FSBSReD0XrlNfj53xXiNoxHVv0
M768DChXyhZTmZsD4yJbTwHSTpxe4k9DZEML+piW+8nVkT5baZzd+JhYtv8XymJZtGgCBkHq
VBNy7O4synw+lC3VUBEtp4MnLs4LEe5q7ygMl9qp/8shkeomVxwU5yEkVR404Zy1+1Pp2snQ
NDUtIQ01zOLwygmrfrwyhx7g6t6B9zdLcPyK+t82yAs0LuXBrqXmSmPXFnypurv9lfU6MCph
88/ljFH0z3SjoY3eDDzCsAaNHC5AlQ/W2jNfBoHeIvMG9EhgrlCEfGVQsp8kej0at/PBMTGt
UBdmAnO5T7mca+v6/YRHSFTEYHpWYG3GMmHXp0xWfSLtik9+9GD32uPFu5ZkIpxGN9PI6sjP
KnYGhoYqhGl09txdiKo637UTRBZX+DycNWo2wKgCA07NMjeyh9cbtH1za6fM0cbiNkPrketT
Agv+B3pZjfsL5fmVU2z6L+6FpQZUfqXQjFQw6jDd7AN4I2b25J1wyB13WxZg2i80a1PeUt5C
vxXRDhYrIvMVxcDr9lzK5aGHZUzo0fUuIZNFoyx9idvNHhX9vPTk7U8fS7SGS5BZdSdzHC4G
TUlq/JmwDKdoXlaXTPqn/XuA9hMyBlxRh19DSYXpCsnGFiuvsm24zpUsYJGlWQRvYRkmWkvM
8fZKOHMKas4YMpBr993UuBHZ5ehdq4xenWmbmEM3AP3WE8IocfpfgZzALArcZG+eH9zedJQm
Ey2aXPpJqSsuHswIq2wORCpA7GTunAVRGdDDaVF2yTGNofpwIQCYthy7X1WNAU6eQWf1aoiu
OUdlbVt6jxqIxaXXaJuNcfbAbUQfTQz1xoL30yXEC8VAtY0JWbegFysrzHIi2hS8+tDQwwHp
SuHasBq9CNgWZca3v/MHFzzuaJgwMRHzESMtaBgzytuobOCZ+vwZG+D3dHUj0ElSCGB8mXGa
LFgnFa1wu3fIuYIKHXO/+Ov2ySmiWJVmGLSK/DKlKzl/6ntFXEfzp19oJAG+8VOymqLD3mdV
ZZv5SxJY4lrWxdIMvWA0W21iE6ysbUtJCazQ6gyZ1iVG3geQ2EhcoCMjYtevpYUmM9maflCp
SGaug7wRdbuXhfceZts/sc/jmTa9X4UrR0RDrR4UDXf9cZgB1izDoPDfsUWaAbauskW1QpZx
7bU170ut+Zk1pgqkLeJhC/VBu1oxEMgqlR2YRIfhlru98nMQDH3YT4fzdwhtVKv/jPdJe7Do
Qs3l1jsJcs0N1Lt3yrz/+eA/u73fw+juCJB0J1wk8AvnmA1tv55UBpYZdXbEzWrLQG7q04jc
428RG726d/fdP3IqgwjBKT2MrrgGN8pvObHzjixNmaN6mlZJUcOlAyQrSdzAiCpZe5b/fBgQ
+RBWyEdgdu2s1H7pNaCRrd49KAyLLdMytbxRFJESPrXS5hvevzCf0mpnt9vnZ4q483ny1kyP
u07sNRAdBC+ralhTSz7KCyZoZ305n8EjdJwR6BfbekzWCaTdVeEQm3aNd/T394wGDVQoa8oG
663HRBKmu1HRnTk05DdmVDDjUFIrz8c7wKXmtMiD8gep74NzvP+khRQi5PiKLtpgA3E5Ien6
yvIOfcrgyWAZW8cil70YN7jS2K1yVpUnhph6HKWLVrAm1Jx25dbvT3Ee7z3Zc2qhHHXfIve1
FiqnFqZrsJzoz6qNj6lAB1QYvXsb0Bw+hX7pSAYgfPN9zO/f1bA24/w9YGa3IezvnRKMSSOI
ugoJQedSQTrcpj4jWSaQR0s8TG50eRXGyvWuDk3qUikvxWyQqS8KvckmstNgZVgb1CeI3pzd
B6cs20ZaKHlm1fMXUREdKmxJ6S7WL6FitgEfdCaeamrEOFE7P65a10phDw2nX37vblCsWdmx
WJtd8vub007zd6eJBGHYDhjupHo6mDE0a2UWIRWSJGlHgHKbqGAAkpimHIfdOkJ2+6zhZ+hc
YuqdDaMI/4UN9g9+XHiy0tGUBGsQFldrs/3Htx65SZdoyC6S29fg9aUh4ZH9jyAFNeIM5M+E
UAkzbPYK8xH6yGMS1WfT2L4WHBxttGNZdQNzhbpzcqt8KNeaVHnbMD3ZT4147NZZWy34FnyA
PMmPM602SLXCuuTqDpCS/z8pyEzqW45BP1N2+p0QEyEr3ed3VhhTYAx/I6rNN40Iwt8vmfH2
dbJesIY4R/qA18gB5unx3w0opo4Jxfd+wbj+gRehohbNlbvZHA3BtOXkJNwszZ+6R7juVdnr
WH/yt9+cK/m4PRPn2IW6NLXmzeoM7vF35O3TNrdaRKHbLmFrsC+5qfqqD43Oso3qWSvPGL5V
uAb7o1EqkEFmIibHx0U642o8cnLlkFGNPgNnlOTRsQw9Wl7ke0m8RnwIFsYOM3FSHVxCxOho
EQN8RU3VM1jH8+VHhXDcrXAw2LJ+cKvWKAWOlNXgIFelVmo/vzAwVDIE+2Q/wOuu9Tt5LLEl
O9qRw8hLpMebXyC7ztSQsoLfCRIcXhoipQcB8WZjsRhhgZRU1zZpPUAhr5yN89dr3y8NlFOO
zbqx/+ukC/tBC4qgWLO9XpApUNZ9VozpqQugrik8wggP/znLzbfsPoubuJ1HITcE719M2BJF
K7wCtjtvG+oNA0bK1LdybAnMfsQ884RRC8W9iqO9yQsg9g3NhrFfnkyuZRsyeDy2wPDYZ1Gp
X68ZWNxVzpuaDJpP0jl80DXC7QcFnviOsLRI11J1I0d4C2CIczhLWAXk9SrPKQgqrVef0cPC
WAWeNM2VvRMZS3DuIlBnRBtCKtqi20B+n414B8Rbbj2CwSnnpetrb6ECUVGBxrd+2Bt7xv4c
yW4CpeiqlWs5iVjO/2PqA8g9nyDOa0BA9RW9Gy0Q9WDMTWcio542k8+BbZ16rVcotm+LFHwF
PE8UkxEUlPiM0cEbzoj2huIPh0r3NsabrzWFXiMT5ReXJiCCITThgxqgAFQ/ER8qxTiXt4KO
hPfy7E+zZjVsHhrNHgHPD5WqiRBnPKrg1o8FlcIG5rmlW2sLobDPLVxesdPqT3HWpuuRg3yD
ittdZyLXa26/71JeMWDqASWbX8wISdvSiQQTENVWLIixC5FQ97W+XA839cqZlu2TXg7fflgW
B6rfIVYs0QWTpE+T52GivF0GFw7Z78yYbmiGHLsxlt5XcgYkAL4WjLaSXFNFEoQm7tdD8xJb
CtUutuLxcL1xoDatxQ8M2JwUhF0a70PnzMyrQQxo6QpoAN1t4ndDNisKArT09ic8YOGu68fN
dS6nfZoAjgYXjOKB9uJWxVCc3N2K2JAjfGdeY5U+78zdkLerWMJlcGmyQmkCEWhj3xF6Tofl
ojKiBdw+30RYoMoKdTM84VsiTfMGK6S7hu54x4fr9nLuZKDV0by4Rt6+AjoHJl5ReyRGCvQc
mqNItfw7zUvybnIZw4vmi65CLkDvwN4qinE/3F13JtlPR6mVZHTWk5iu+7jDfDoos2ApnwJD
zfkSgu5KaKAslaqGFmFKfqr+tpB4MauJon9X9aIKU/GTB9TFGXnrpxAkpvIoCdM/4Pkmzwvt
52oG5Sw05mI4sudKITA1spIaHeIZqQ4MnvK/z2q8ni4twJgvKA2kqIk4CZqO7Mwl/k5o0Pw/
kXFJeJBoPO2pVGegje+Ipjf6HVIazA72hj8aFrsAftPqt2l9BMVXGPNntycRHbhMVr9IyoFA
vwB5gkuvFruHP8FrO/nDi7ZpWnLBER4PvolzdhcgNhd3br7YANT3a7qyLAd45lVeO0Q0kV3H
psBYb4ig5V7nKO+3Y4mPhmhymSldG6ADnoShTSjjGhwTD61sAbiqaB30smP1lRDfXvV9wqsT
/aapYmMq2mWKRONxMVAMjxixwLYBo7+YmZjEfNTx9D2Sgxc+H34rmSkHxYcv32JPqVV4YHGw
wRjNWgdcYgk4lAil6l9Zle6ys3nWpGrgsCN3y7QSj1gTHqGGNGEq/ibAfpQPC3E2jqWEPDVB
gQ3HOvBNfzm3Xker/2avyiTjfLL+0FytzPPa7L7vgDRYzDFmFk6qkQ1GrBbyX4Tc81ivkTtT
Ei3nG6i+bqLKU/e6Oa+Y9qFQCa52r3gjw4aKTBu4Rdd6DpdSk3M+QHtSoNMYr3tPDAiYikvq
TaapQtC6KZqL05UDzC+r5/bvKnpjKA8o/eLJe2Ehf7F154cKkYJ0qicWnVgqXpppvNthI2Sv
jZvUmsAAWxtMFeUeqNAsjPfO1sW6WnVnV9FPf7YFS6AVlS2gsRaOlT/+Qr7y1nIAfvbga+QB
Zg46Vw8Zxy6He9zi9NHu0Fcv7LTXd7AImFepjD0i2b/RiqWHIu2wq2zpamkVuzQnZfrn4LWI
QcTB16XcGTJNLz3nbhm9GvEQSg58xDks1kKMCf7HbDhhs0sGFzQTZZ9NM4c0XCK4l9CyCwmK
vjDAWf4/Lg02m7fCtDBnP4SbXE8W5TPbjS6FnoUPuVgr2YoZLZZLStHXs7h40GaU/ZCIBlAU
RKMMgZRBMGQT/1yYIYpEyRDauknyVCHpV2E2WD7lOszeri7fc1Fxh7Od4G77SBnUybIL0C3n
Ptkc1Vigevgtx1Jwt4QsCmEXBOkroG2PYYwpDNhk5N2XcGDJIHFpGMNozdvRlPQW6TZjTwjo
T/XddWrLxLRsFZkw3miaiu7m95EzxCA2zJKILqna6oWklSEvUSQbh/fpO2T6oBm8+9HcQAvF
W7Gk9NwqERc5Ayfriti0JAasQZGZ9Q4pxxLYPGcwdeYyENEizGSIQbTnkB4yRRNLm5F//Q53
H+ClGCh4yFSb3hEk/7d2Z1sjgmyxXKtwi3omsUaw6+ja3081xai4LtdTz3iArbr1PMH5Ozrq
jd5n+R2xSRqpkxsmPBJe1HVGcOK7DfDJ3o/UJueyFPzkxrvEG3RHfyTq3WP5SLeLOiBwVeuU
jTS1fAqYGNRySdLxOeiw+AErv1nOSpdL0YwLp8B8FUP6chajO3gbjYVsyC0MX+Ufv21iudjR
cF02Je+tULQwVaGG2LEuYOwqEXN639NQYiLlCyGkL4/c883GErpEdqv8VSMqGH4X39mZdMoe
gayTh0ebsigd8c4GHUWk+NVn22HpH70w0ZQF22PkxdtkSoFvGkCLv/yjlghBWFonz5skDaIl
YzETNTTK34HkDohx6iC1LnD61QYPl0hcwi/6a+znl3yu4y5N+ZQxe7YNfSYP1BF8oJdqCtYH
+TJtBtEG4uuo3tPmFVpeqwf94rhGxboIU4K8U6Sj6C/splicibc57TCJmoeDKsQRrgm15cem
c9BmNGdYPbR7VQDAlX90yErp5CNI3jo3lDF6bYXAlEuK7VsgPJwQ3HADUMXzGmBBc0PZc0Wy
6ljBlibMoqS3trOp9RSSO3mxV+YvowDgdihXZsLnLgvKOSL4/BOzoL/iBHluVxu6FUK0u29A
SxgMFTNuJv4pYd9zJorTQqHJ0a9XyU5mwd4phO4W+iDpoUFdpVnEcsxX4LIhcdZ3ED6DvlY0
fnydywjqbVK3dXxLOi71MUIW7tt2f4N0NwHmGeldPc671jhEr42feL1BiEqxgaXZnzQPLUkB
FBwQBKJlNHV6/jk60YWrQV93sVCnforG7qIoiFV3v777/pv8/lTd64fGN9Zsj291qbPXvfDm
XPEZB2TX0Tp1w69+h4w61S+Z48uptFY4mlSa/PBkjQAfSHgcKfDwotkAlKwQfPZSM5m9ua1j
2+DbXNRgrG4RXye5ZmwBd9opGW+Hxl2VnWgfsMmF/jZ1SQZmGBDZLuyoEZXqImXNDUiGq7SQ
1IF3lJ0yI6nO3picStx+BZGlagE4thdizDzR7+MQ07jIQI5M/GH2tXTEJPxrr9RJ33Mb+stN
8GVcvVD1kD6rBWO0/DbsRyum3DJCZcqHcPHvWXMJvalUgbM+cWI0KkOzN0/3z1ZPEew2Wc8u
BBQtVTSv09bTqjeQnbluS4Y28VHR1dClA+bWalmfdpdug5AJrg+NKpQTVL79KRrc2FjfSGu4
P5Zb0THp3ckctbMpqytHYKHkJjbw4v45h1CB5LIOswNx0sYrq/9KwX4U363b1a/acVZZ6OIm
byo7SDlHiTD0C5d4/i3EjBCcSmCFqUhOQfN4kplvF3p1Vov3eZLtWAgylEmwAxSA1XT0fvyT
iJvuWBNFSNHKEDYSonUBzmKgo9KuNIfbauv2ang5hFZqccYek24k7utyQWUPCN0THUDmI3el
Vsvb6MokRzcpoTKosi3yTup+V1CdDUopL7+lCzSAblJp871Ydyw5nvx9OsaH5BpMkGVOHcwR
tm9X7mf4gaAuA/7i2s4SU0oHBiQQQZQCiwH2Nrtc0THbDIZf2LUHQyyTK3LXEhsMPDd9qEJw
31XJhPYjNiRlbu3fLvloZoeq1PcgBLRf5s8ZAhKazGL38IVcZoICVyPISfmh7SXkPns7msSr
OPLPvnE20UPXDHZ4dzvZVBFKLitHD6bqGZeV7NtUQ6Xn21R4985LXG+YX4g6fiA8zffOjtcx
jwfRtzzJk+Ti2Gd9eAvqYeeXa0ey+xwRGc5+mbKXV/J9g4no/7iwWlxPGvot3g1+t4vipE6R
WpFZ+d7VUkEx4Z0rgJ2Q4cJqZEQmHLCAwEM+ioTFnScHXls1DbLvuYKQR47H+T5ZMFu8W2Tm
W/5xdJIFMRAuwCXxd+kRTEJBdTQThcEiLWQGMGZsa1tyOtVlJF/QKMXI+d2rwm9+JDgEnmJ4
WzdQfnC+/kCgcKA/rXgriemEhs0Ez4KEDkkmiHaaDSqzZNnmHqMVIkchQvuNmk6F68+WgwZI
bPl827d0JP+dRuTqeVCEqxnJSD2NI85U0VCc/WjlldOltLIOeFvv63grhSjOkPI+nJK7sOS1
VVhZobaPnaQVzCViJ/H9vVOMth0IDRqWVFarrx9nVXMwniei/RWp59u5zcS4Xq7w/+LvBnqb
WkXpCBX+uU4tnchMWOYWci+gLa87xrj4/kZveQA8vdQcmFYPQ0NKMY6Sx/D8aZzXRFIQty30
s+2mrnC9L14e2NtaL1Lj0T4uuEKfsA+sd/GUIr5OcqxSdnyq3zZ25FskBL7BJyzZ6Ulb2627
ihZABYarXv7eWAdXvMX7eR6oQ4Sovclbk9sqvdEDdbWQGHJpIYzSOrSbvpu0VCyyoJ2TZC7B
MLtI6zChDLT+EMWUpJVvMZXCCQoNW11a83hVmUBMncqRASU3v7xNjfTRcpKLVk3JBScowBb8
pWlkxq0CHt0PuxLaY9oQZSf9w+ftdhSHgOyRnPbIzTgLncVquA3MywPX2P3VmIDIhaaymE5c
7X3pVzXcPgY5ACWqiPWT6fsd/jorKiNRE1o7A9rt6MEbOq8RHzZx347SpIzICu4cAQP4EiEP
5ZrUsegKR/dU/vlpGABae9y9CGznz7MN1o+NJhzujZ5M0or7bjXoQPs+Mcovax0ZNXBd985Y
TPIq7iYGlahsYLcUngFjn15ynTDAVnSXRPfpRh1aTQj7xa698z4Imq6t+08nVcvkTEw6le9p
IJ3B/wWZXEaHbU7tjb8X+xlZ/p3sJ2hzEU0esXPwd/f5alZRA6IRUzm3vA3miDwPEG/jhXHG
Prd0I2qv+j7+BEqBhs1no7PPy/+Pm6qEFAgltUdaNjM5rRCs+wi3MuJRjmyAe9/3/zzqOOd4
s4cdmfdALHCOw0oVd4DUSADk3Fp9833aCM8XBNPGczHz/rLmhkGB4WdIMfLWhdMm5MRLRo8G
DoVDgrCZU98Nnq9zYOYG7VcFuKfI2bXFineHexDrRxfMPjarwVlx8gZi+UxbChVsL0D7fwSp
Zr7FvNDt89t1dmRadip3gLYz5YGCIAKT43dq8aklEt8noMp5N5YFdfPbaFsu2OjL+EzCtX14
ZCOuXq4ofipvOVcWIRUOiNC0XuMStj5PgA4C9PHpcgEm7umvHVMZb5L2bhYadRq59jnjlvf8
cL50Cb1exF5ueaVOh3GhuO94SdgCvQ0CmXtJOKrJxQRUeFt+0yLTbfRWykVgNF+KC1KkkNQW
lwVN4AOchwve0miNNU2KJ34A0sjNd4QmeBhzdlUVYdvWkzoEjvXL0bhx/RJ4kpOFANifFuUH
GXgwsO7pnU8XQoqg1bGB5bTI6AAUNzv29KysiZFcxvaZJ078pUJfTtsvYcagifY/zNhdfb2/
u0mcUYMGG69xcIAa6wXfUopj1OSmWJkWDCwg8PLjFjpxe6OZmaHx1EKsgOB2Uy03Z/GiR4pb
5u4+hDnZJy5pV3NOoz41LNWI9mF2NNcS4BRsxzbYyCjxlCb9OHZG/Ad6TTNPQJBNDmslXZuq
slHxWloXmpsLA+JMr8WTXqSfpEVlXqWzSd5WXirkoPL2HAgYIvwz6VDrL88QQPGmNMvpS0/1
h3gK4fCJaAoVPdsmcbmk6S3TAORT0JG5Zp3CjsMc93eOdHX0+/sBtHrvZvZvaX/IbPt/iIdA
5nZ7r4YMh1S5dvQPRp1O5msOsL639kq3slaZdHHgbEi4vNa6q6T6dZsUW6MF8viumvfETzsf
rjnyPXAWA/xI6Y3K+7+b2TlxU5g1FDzkV/qKBJEWM8OEMcQid6mDPQrkSTiCoSecr9Cm3t7Z
EI0oSUQ7u8ttow4qETigYvJZ+Fp0jJS5ayfYdlO/QMSFmXLeyhhSYJgrf9LXo5MF14bIuzri
SVI4rytD6jefFuOhXtpm1YMmtoIMW8kx9dfO4duw2gN/BqAvUom5/dFiDq3J6MNl/34jpl4V
RR2oc7uiWWVMvY0mJaQvzIR2eQA0+gxoB53ut4U22Nx6udQqF1B7+caKjU3YkJ8l0YpAeYUW
KyylMWfgvBwj36v83dXwp90DNETKdTKiNlR/vFp5jJGrZsHzMKqOpZZLTSh4A8sQq1OCI81i
2iEDGSInW+GupocFe0xa9Gw/149mfMfVL+izpLUDKwnykLQ7/1RIDWgkWVJd+2by5gLhGm3b
oHXxrfMHN18uoKdRx/xHByIEarf/rhXay5Zz18UW/alLx/T4sHs0K+S9whBBp6CtnSZeuvNZ
rqgjNA1tsfFbzMteqsI1tYHITeSeIJk1r4GxGqx0GpRO7XMmHOtHquvJQlUV3fgjMNtgdXbj
YImtUfGne/633aa76OPuhfGMdNgNpuZ8Kqh9jyCfQG/FVmTzBtgJ1GJx7iqG/jchFPWECfUt
JgfDrss7GZ78mEKAMDm4pTIf9OwpDLNG9H88AeF12UjztquEFzRCMpwWLbLr9/FzkppFfoK1
soIiGDW7ErGBAjmxzxk8cvaAufGmMuxdhlkFwderwAkfbY8Jr3wCKx9m1osMKqSJ+yEv2XZE
wM9owNBWGHeeaWuDxmkKBBAiKSpQcSbHEivNrQofUB/5D//61G08BBAgiP5itbBe6JJfUksA
avqJSP32wp6fTUgb3xgbXmvRgNXeLSO/n5hhvMBObZEVzkiEhdcdNpQ1tt5WGPaZqxUBZxqY
GGO3O2lBbBfsC9i3q8C8qQtUggT6w7xOzTvOPrMulSWDncM4FbKWgAMAD2cqrJW0bYoLp87u
JPYTvw1nHBff/PHKpsvS7lQmZJlzbdu57SVU9XZLFemCzDto4qSsyIdCoGFF66rDIptbv7pQ
gNCy3CiaFn9NsxWHCBut12Avs6yghoNQt5jEFhmA7RGNv5c+aNwTMHxsWY2GUGhJcG8GCzXq
ecNw0m4JTmA0rZIuqmNHGEom9DqHwHa35AMFVU0FAuqx7U4x8QISSEDdGLZfPP7wX50sbaXI
BE3EA7Ucee4RG3+1KInGG6Yg4cEnmIXH0kzCWg4TZljyRRGtv4qLsYTwJn5uYz9C8CLKpgJx
elLz37xzvib8x2TZUCg9GP1oHvF7oLcpGusM2TrfU+yGuoXQP2IYkRmy//vO00HK6UjPSFzi
KuP5LyWEyEAsQGipVMcTjns/XYhfx8itS2kphps6E6hIM93Pa42GUXwlG+hlUOFaz8SzSH8C
vuHczcv8hg9VfKMvUpt/PgWY+CDowvlREmSV1fYvzeu8DBaNqdhmcQeaKyKFBw+P6ioHk8Re
GGZpd1GJHOHsBwddA1Ujk+jiM/S8/gMDAVLNLIuGBQywKdMZu763ZsaNSc/uOnXJbl3s1NrL
9pvI34kTP6opGC+TmaY8gKTbgC+yGhKuOuVA57y55E7suxfEsPLxdq4vkc6zoLepCKB6BNWZ
x1GjEzjmmvS18ySdXVRjz9n5KKFIunVbpTecRd16Pp05bXHmNK4UoosfmohEvsObV8KgmI5D
O5F+rCOTrJnaLgoDYWl9OkxP9zBKVU7mWyQfb3+UGlXcetE8wPlywgSf7oP6WuHh60Fdi/vi
pUEQowJ3rJtTN07gUSUrF6mj9bkShbytEAvxknlY4oUBgF9XiEY9Z9cvNLFUtcJtNjDirqEb
48ldYIDEuNrh+PVLl6CCofpVnmoVQGXs2xV2aKynWQzjENvAZU8ZnTHxJPeY+AAZpswFXEF/
0MQ3xeOg0MbINnARefdWPu3u9RV2qVGAiSe+RMPFEszeI5k6WKsXYE1rwpbhmqqCMk2msJ8S
cFKA1xTNxXtUSnVNrDsZ4k+XXlOqNIk5u0c7hVEN5EXy3N0S3mJlDfDGBWS2iDZOgKrkY1oZ
tqrYQ6mg9kbLHGfL1PkXwKiViTxGfufLPhseuDDEMYelpSKmuqWG3OvjnT7btacgJAWjwYQ0
+CWDpglnYrmKe0vjygM4QDQncKkyZ5SAVBltQh3XSClXMfdcH04EHrv5kqoxk8Y8WVMZom6r
qN3Ady+OFU/i2UjVPLdi6MDPoT4/oOw05tWqs8eix8aifAkNBtKfkrBfs/A4wTG0WHB9/l9U
5/bpCFTcafRXCGj05bYlMNhPeyEKuDqAJm4iLICpK3GhJ2tdGm+TdVidyMVsol7CfsqzlXPP
06Axg/sPX/VRd4NP5KccPU3EAAHOcd1rvMbV5axfwQ0wRzcSBpUsvpk8iFR4ipPLkbYsus4f
Xy6XsoSFIfl5R8H5P9rdWKtbeKl4l8rOVnJ+KUl/mG/9OknSwUQQOfD+2NUvm3vYd9WhJVVI
5zDNLACJCK7cMdmZyEbOY20780W09iB3DacuRveSujf5SZZLhzKvlIkQJinIIF21S/5hpn7J
y5zwyGtFyJXUVkCYRtZn+WsAYaxxGQ7YUNbI2GLJNHDL1H7oCz9SIGuDdYAJHr9/JSbUDf2Y
HKryJTInJeJvVYw/aeyooMdTX7Ajyhiv9Tbc9RkUgf1WxoSw87PKJZPGNk2EBUlyOZ7aZJQ6
IXnhH1GcKRmNFbxKLeyleSj+dHaCqAwYYdMrpbK8DVMPA1BBliJ8q032LH8bo6vGr9XC9PZv
qfDZUX9Fb9JgqtG518Gymk3af0oRbMC7adKVZjj4kXcNNucdYN6CY5JLb1NS9XWBBodR7J18
DaQyhFPY+zyJhQhsBPBf4PN7OQnxD5RtiirW0sNFZTDjDsSRIjYQd0k9XcmFo0oXKCx5OMl6
s+/8ylUg2LBKH1wwOuPuOfanaP5gF5OQsG6PWKySw/Ocacws5+prRkAR6+5Ye9D6/WaaxunJ
k4jllQ0NzCkUsi8qnsoL3c4OJNQq1aBC2zT9TkNz0SfbKpWgbvQBuhSJpwDIMKiL4yKdraI6
PozsRIqBmiMGqrUbXDcBn6//2pfNlwTNotVyGSRng3r/kKVGw1jfzq8IfgY8F5h7tAcx6dKG
8to7IF/eKmYuUJupfruLqoqsd84/VmPZPs5QR/A9K3ChJz3vebOTsX2KWMri9QB8XjFMrx8N
RuGSYzUFPbBoLB6ztLlbXfjBkydr7F5Y/MypUIJuq34AmVmf4W5bx45kvgryXMMjV/ZKVIb8
qih5nxwL/8zP6WrnvyD0FtmDP3o76/g/NZQfcEUQrKUvI3ZA1lhFPg+ASTaOpprPJDD/ymA6
lBQCHNDH/LW9gL632DezSedO+g0YjSQhEbsBYI6/Nu+J00yguXfTwcR0bKSxOL/4ADOo8zs7
70fl+kNuT8GO7I4OfqwJxU7fngfOkPJ6yXgtNXyzI7ph9PJ+JzP0D3DZbJVP6VLt9JYwKHS9
oeBUoo1MILq8BNyz9WnZ7ee/6rHfj29BUY1QGrCTtFzW0b09KOE25XWLS91RA6a5rMhq/njC
SMI3v0GJI9exi5yLUKofSPINX5/st7OKHLu7GR4xZWUuYnAaW6df/0izhUpcvvCVxmOOm+2E
8lCQrJpaLbcNWkPtxKwqtVbzP1+b+AKHjysfS2A4AfJjl0q9Zn37/sqM06Ktmey5H5CHqkj9
CNf4Mn3Rz6GrDeIlJ080ekPtLHEj2RMH3M3Bf81xYGkPRIa4w62gGP/MSumW7QdE50eXSHVc
NSahViFo2EMrcIH+4n+TnHO6vYqLM1homgBr4PRODCYMjS5/OEOjff39e9RM+dVzjU0fG969
bfvcM+iShx1icpnetwl4jl6xroUgw+UnDHwUBpFsWLzZ4mdkvu2C1Y+rP9v+GtUIhwAhhHU9
JKvpc23HCx7WEMabp2cYAlLdBWHaiGN/GEXlY9Z4IsaDMiAE8xBMx/+DduqjeIn+5ssWBFum
MGqN0T5ja778lfPY7vOKTwFoledG2rwRH8n55yjyFvZSGn4IGBlL7RfZ8wLWxOSp+VE+U+Gq
1qwEyUR/uojvPcHxmX1/a16Ylmddkajw6hhH11HwJFEwcC4VVgxm7JvbsutX7UFUSCzkEZVo
UQIoAPQTzKk53M2xpsWqznt0mR6Pue1Gi4XHXcI18P0vJN/gzj/QCePTKeh2j4aUEqGMdMES
xOO08RulfNUVfnw91y/l/nsAAIwz94itAIakNTMYtx3kIvqLlLtAXVR2WJWO+x6b64LWVD/r
sv+2o4szW4/GaSNSDV2P/yDH6ayJfukVKdIVOQOVl/iVW/P2d3QR1SGQC983RFWDVZLFC6aX
1vV+IfuKbwOuns42wf6cMfwIUNenycqVOVVR9a1mwhlW0QpBw3iegF3yPG9Ry6fw3z3d7H24
OdDZWZKL/uUVX8NxK3TSfhlsz1ryaZkWvr18iAgABYbVK3vH1dhcIKTWWjBaWs43rZznjJ7+
KxUU00x43nAuTPyroYSjhQwBQUq2fCfAu9/3NagGCvE2N59EOzgBmbfX4fYL9Z3VAmlPf8WD
C7uS+QFMDIThOJwwaimzPtJm2ABoKI7J9of0JsJ4H4YhQp9RfIsWvv/8SO82AkLyFQ+VvJ6Q
hMiTvTzKjc7b4h8KjQ+EwL8oCCg94f4+O7unGeTP5et7wroRQ041NpgXyoJ0RatnYtI4BFaX
CKtkq8jJJcaVjh1JXqntd8yAeIL931lfRPHBLRwdMNTji0gW7JaBi7EVmtxo88peY4pQ7LGQ
pmzLWLj8SHxGsEZr/8m32boGLOT8RFhElvqbXN6iN3NyVC9+L7c0mfjPhTc/0MRUKpIaoGMr
blB1Nikx8R/qkcCrVJ21XRHtD9ij1NyYyzurpt7OCI5mxl3rBg3Htg9iiUAwqF0edTo6ZBUs
b+6ga/Cynmp0bwphfZIQtFbMjyj0XjjyvtGAoA8+BxC9r83o93PfjWBR9U3E/iFVE06fEPij
dl968Hh33JXcxpYHTY1qTh1pGdhSSDcL+yCSpJ+JWixlNl06unZ6TgZ61CWbEKTWjouvtVTQ
DNsQcc6rCBGv7kU3SRP83Sus/kDDR6hkBTOdUXyQ2jr0nvQ8Kzcf5jagnB7S5H0WBXFnjyPL
8U2DAUv8WrdYUgmV4LGXkFXrInncjW5kabXk3FNPPa/whVjKhWuGHEQE04C/vYd279kJsmYM
E0kQCO+fe2DPm22YCvIZERLbk9x21k9x6xPImK+OKNAvWJrl11b1vohagN//3xycuV5zW9cm
THWr03ZJxl0Gu1JBGGtfTJGLv+8/HxBas9E6UMXKGN+wKo3ehZCaTJL80NYfjzQGFgcCeWcg
X1Ha4+qsHgVoKncqxVMiEYDT+DeauYsjTxTzfHlvlgNoBpEv7jSArGHAZ3oJX4swApU3VCGw
yJk1PKiHSggdbE5i4Jg8veJ/4w2IBbdxISE7e38BJpJ4NhHAG6Y8sY7A9NfpyHO0Swo/sxAu
m12BfdCvU0wu09zLpu4J8XtMRmZdXQR/DpTSsn6lwF7gTUz8/YrAoCUYMBFwVvE/e38mVmwd
DYqfyEM24TzdZGmbXrn5GPn4N4uAN3HInFIzqRKpU/a78ij7SkRtPIApU61Wu+JJ+62xWGTT
/WPV+6A0mLehJa0LQMDKbh5dFhdpA5bB5AwZK26IVwkeb2xD2TFmLsE6Fmg2AZyNFUWQQ2HK
8JbJznsx0DBSQGpR7yTtYO12oAjmx04EYwypqyXygppc06kNFZxfx01cycyTXNl1MfEy2R/w
/vvKU6vSqpCCK06f32XU6ldzu5kpNbWMDKcXlVvCvx6RJDfAwZYpqegKhIAuNkehw3dt0Gtg
U/c0aQlrK1NDchiTgfSZJxqEyfpNhvPacUGcLFhhuPbCNdMEyd8+Xuz0bsfZ9RuUc7sPpHzW
dvcxuhYK2sd4q1oW7WH/KrzrmLSqoMMMpLOnYg2k2m4d253lh4J/NZGLWDH2Bg9XdkkdklRP
dbrmyJKVdKdvuyNO4HY796CWqVZ0mLCUsaIbw6gUhY3ftQ7iMcU/2xfZk7+KFa07Y8qcHLUR
SJviOq+fFhBam5MG1sPjDjzdrJsk4ZLw9qmYG53WsIRYJbwN8/lQXZcPY5lCnTPDrN7tf0xD
JVIdFXMj6aInvQ1cnuxtY1uValcjvTJWg/Wss8dVXvqyQkE7vnZMy3GMAuKwrVZNYL/lNC89
eE69uvOokaLplOXUMd7DjbbyV7Z8x4dCyfiJtYd821RK1lo3sBHrjsWcBQNoIJeKvyTBaxXU
52zC/gwcIoxPPjHVGCzNgBSuJZP8PTOaTAexD67oR2NxjsPEtrPqiSZJAVwyOy8FDx2tMWA5
2lu8BMkoxr6lFlvfUXX9uGTN9r4yrTQ7mN5qFon3t6wVgkFE4YHp/6y+gRE90PW5xTPx3owN
Htd4uXjTv+3Z845XPt2zOWOdmqwq4kpBUrmskwzPrMEvS0cbqzPTDHTiHuxAXfQ/KLVEOqyp
H+rtNMNOySGTDIDXAFhOFSMXbVVo0TVF4Nn/y9Nhx3PYosOLkWDcLlbylg8ON87ToSVdO7Rm
3+WGeu1RFOxNWH0phYstBpklVR+MxhoegIxuk6+Kakitfu5gxb/QZltw1/1QFegPCVDYzw5L
sxc6aXAIsf61kFD2AoB1QJDOcN9Et9kIjPNl2kSe/uW8/60eGxnb/SId2s8xJ6qDMJnWX2vA
bpjrok5P/exw7Q6VLD86MsCUgILbGKpQirfFCSYI9dgVOEgQfGnRO3v5uvOvKdVkKbAnrGSy
sRwsv5zY64eoC3bVJMmeGlcD5JXkfry9BJ3uZqsJouM0uMjuugrt7ZFplYP2lv21Cn0A7Vym
zp//bf7sQsBXD6mVGCaLBtEsKgUuEv4Oepnxfnh6qBlH2/Tdb6Rq+4fFBy2HY917YOgahYAe
wtR9F7p0Yc5gU+9JLu6/TOVgG5WKxobB1MTbDkyLddJe0tNTmJiFVPF4vqdaoiU2YW7/qseF
XY7hmGsfrjNt5TtRqYjGib8nqa260Lg8bmSYDVXK5Zd54GGRKPuIQeovyUch77p4J9MAjJVf
11MPBjcSNwDmlqKb8DCft89C/sXNGrrI94FLHy4HfkU2cjB9rIDcKcwUJBrwzYPIARWuKIRa
l6aGdPgRPdtUwQ14ivu8u3HrPKxN/fA0rYYCQK+CbJbHf7T7v6weGVbC4X/MVTfzlNVxRc9E
uCYuIPsex2eyuqk8YQ1/g7poqtV1l+TBfKx90fOxYecnxHe/r/O6nrl65VfH6kssgh9+GiD6
vUGuId6u5Xi2doNatNw/x3H4yc5H53k5r8DPioNhJWTqVb318oXxwIRppjgBreMtwxBXyW0B
GEB7BrZxqgudkbSbtx10Ox7+3AT3rsfJA4bX+eoyzgziAVxOQSvgmDMIPF7uIZEmXcw4bKvs
e9y04nTMRondxdInzWB2zAtoJA3VtoLxV4C7KcwOMOj7pPLDF4raQaWZMJCFAkfYVyEkStF6
GFt3cfaFGcvduLKSSTJEL+afCQmE7uqQRyxa4/YM6l/4kcqakfHyzXTYycpFaMFX5j5bJ/dh
LV0fD0o6G89nUleNRRBm8s0P5BzmR4FuhT9ZZbJlQBp5Ynv9zdaHlJbkHf8VBgBIkZXlkR87
EXMN6OQsenBJO+39fU3gSD211fIKquDfrhRZw8nvZUDKnHxUv9aJffoSlOFxZ97hNzvZiHs8
jp8AuF9YCOP+fsfnx6/lZnjhViJVdUccl0EOexzIiT6E/nYUIoqn9D12neExnaMDysyqS1S7
r4jCoh3U+nlBjWbM5+n25HsNfzgezcvIShvMJ0Gs8zVchVSCZVH9uYMt8M1EtJ4gKGMH3Byl
HQs8yJjOuixI5M5cH/8ty/qGdq7ShORAiWnggE4n8BYj3rlV4dAUKMLPoD/Y5TgXmEkfDu9r
Fc+83YxzlI/BB8MzGVc4RxnNEdvK8xy9cOaTlOnDYbbs4Tt2t1yAQtKHGLeGs5o8rwYPjhsv
GFW5rDwrzTS9q2A54aYCJs6Pew5mrsVrc8fYI9sOQIPG/FSets990xnltPpFJK+3R+6PLaRa
AI2+mASj3FDAWiDts9cou5kQpY6akFxfibUG7J224vwI8XuvqvsHiXG8Z12r/C/20H0eXus3
6MtZRlILJVmsyXGS9gqPhZs7lQGFgHFkTVCpDfBq74T+zOniY77+5H6hc0oBsnN64xbuSsTi
z5JaUgdF5Nhqw6P1vcaUML2XbKVWU7Ns2ZUFeaA6YekcRDK1qSB93uyhYmQq2BNaR3iepguO
6/yytW8BrAWS+I9W51SScLHjwPUQj6SPK+3zCbSD0LsqWlRTPWqfBjkDWaQPbMozV69YQ905
zRes5vGkJa+DRiqHKaz9lfKDaa77+hlZ8JedsQZ0/i0ppzQT1VlemMeViwClW+SgVzzDDhGM
bM//AT7VDjFnJLQbAvp1eo1HECHqmk7VTLLMwuAp2XL3SEygdbrz3yLHzJbxJX3xrPP00ya9
OM1amSh6qi7N099L1XZjKnW61ZbUoA0XqnA9GgufL/VS+evzVxWtD7AiTsd0xkT2GXo4hTdo
ufIinukr1d4UKaMamVTkfc7a4DFhfk+w/tJVpe7UQ7FNIN87rl12QEx+3aXhhww7JzU4bx5H
qOSivH85o3YEcPIgDPumAnPvLcBtCe15j9LRmV97yjr2Xb35/KxgwlrLc0u+7wrF8XewHoYQ
Iy3ewnwmpo8qnsIaWphRhSZJHZUZklcLQkwV72HeWISS2h8hwyjFAU2yKQLVuom6jX0SKISb
cunNKxiuUUzsRfOpHRfDRMnKnCvNKbfrEtJgeXam0KFZzQkFT8Jm9+dCvHvRlqxPq8wuEkYu
Bll4DcmvxAU5LPxHs9/HG9LGxT0rrwdj31d4Qve3b/RPkZ8KmHn/11nn8s/8tBF+I0sPMfP9
2gGRnHr088EUTztFh+VYNP3fKJpE2zJa08BVPBBX8ewvh/wyrD305a9ez1gY/0hbQXjbp1fj
UR1s4hYfj/n/X0w1uMMw8vyhfl/7nIMhGIXsBVDsy2YrnSnSQO4wQy8As/7TX8s1aM43PA+J
PdNP4VimRsE5quz9cP6W73RlUtVM8+1NnSiWmHx2WItdXaPlMij2SCggu9UaSMIxLzrxULV3
k34ASVCWwCH64a15akqXfwRbdUUqJ7D1mwLhNTzNbiKRibSVNqks0hZEpaxgCyv2BPi5SbSA
Ul2sHGMy5sb6G722/Jb/YxnvX0Mysfuhm8vyEhIaR/KQceWer6xDMWQqGzZ5J/yNc7hLA7uK
S0j2IVz7C1zg6Ip9oVaq31NZlJbAvODdWLd/vqyIcpN3ftFO5/KxufZBhyO54OsCRHxSNmMS
rRg/8gze4+yXvKVA0dBVvxBxp1QKSckRAckEVuuNWjY1oGvPkeEY0uRlMuFUuCXdWV2ITb/2
mpry+DFhsJWOWdw0AJKrVkoCdO9eWdMBQGndj9z+qXgRc0AYbLzn/68pBOltuvP3YVh2jWK0
JvwIkwYgQN4DBX38hjkzclva4dTkyTjlKxjcMPINeXXzg6OCnp6yn6CD96glgmk6S71OEeRP
x5oDSNpjLQUPQFd3zJLwQmhQNhy/yMnZOKRiiNVPvl/3pxn/NPe1SqpMshUws/94lJcJtXh2
89WgPY1RnNQ/9fMTh5EiUhDulZhhDst19Mu1g3yNmjx0ZQZQdwPxUgC/vlVSe6cnPxrMDh/O
uEDgBXqnUwpXb6oX7MUvK3XGTJvkvwzzWtR6xDmS/LrIs03z64TxKl2fZHGY+PE3h0Md6lnN
AgO9SoFX4DdrzKRt7KtPqetIHCH0uGcmrJAHQfghjQExtfzTAL79t9DRHQG0XPLjIaJhWwLh
wVfJd7nrL0dJR0Hpr5HWjwcb5J/UTaz60YGNJSHxxpcv850f1bw4/4sXUCTFf17yqgjqSYdP
0WwkpaCdgaWBbGCvtQhTZv7WL3eHRC/23UzdBrg2IVjbJDeee9YRRfjltDg43H3t2SyJcPkq
I5dKrXQlWoUNKhPyWOloEUApKRXOduZlHsuK9XXfw+FDXlUTySbGlgDF8jpmMwB0jm3U0y/S
FFCnDxmj8lMK5UY2NP0XUPkB+S0xk6o0eG+JxKDvGN/uBteaM4QsGL7hbX67hEVIa+9yvcGS
vjTtT0sBvEfAAdu0l6CPk0uWQsYRDgxqjqVxNBUAob6aaMisFri93iqGrKOmoH++655Iui4U
bFIvmEUZYp1rWlQqwQd30gczqqmzUms1TLtdb062Fm3tGTy047bK0ePwhAdaYEawMyR6v9Da
PSzAF/WoySP450TFisDCnU2+RYfoUOiHYCIxYGtoPalHkormjln6N7FLP4CBjtczNk0RTjN4
cXjVOKLBUZNF7dHAEA73Exgu/QJC5+E0UUwh7lJWR2X1E1PyVxCdzsPSguhJ6lNypSCnPoBO
T6N5JkJfHRSMkicJxHYQ4bD55RY0ixAEwreRVQ1JukhgwJ2zQfidvU2cNfU4wN127e0hihFB
9XWGgxWwNvP6oba7XaDlkAZmLJAcMk2B5wPnsgUQ6d8aKiQGpaPLrTvTJAJIdCdXuqeiB+bz
nHQbaVduWHI4f/8hu4I5JJQqfudxBfELkcFFyMKrlqyMh2SyJR3oXWnSBEcNHeyKGlph/dlq
EdkJbxRo0CfybN8V3lg6go/0IcWmX24CM4n4iRVF3Tn18Wnh/ssXbiS7/ThaCfPJhMA5mTgW
Xtl5tkgI8qW4LskG5vH4Xq9NSt+Ru3cDzaCo7e9HKpo0Q+NJVHGos10j/m5rU5nRY9bd9n4q
xJ4M08QuMb2JJ59lTCKjoAT2jDdyszqg+3QovgRg6OiDv9WVZuUE3aYZgSpx8xtLm4sWj26q
t9du1X+pA9QvAKQQzpW0T+R5q1vqawEjJh0YE9b4KHDW4/VCDuq0DNPdQgMAa7G/wjk3cJaa
WJo9D8jJrPdX/hKFR6gWrJ/A/ig/CkzpkxB99heFArhQgyhskMZZrJJSrjtnxldGkQelFljM
vn4gello8P7YKCjb3+hVGu1Mb+F5Pkm5zv2rxg+F94SBdoEg+D9FlB5dxUlBumqLtI2RgCtf
6he6gSgHOO2L4zE3xeY9j9wir4Pf5u22I9cHtPL52W557t1RXJDvwuqfqZpLYeGuiMIgO9hj
VvnLxidQChHuxcVoKZdy62pZCk8Jy/rl9rJmbdzVYMFRwyfmST8e8dLorr+3L6sl4zzQk+Ml
e3V/A0pkcTsHbVRToE8iF4/Rxt9AvHZNMLjjkDuINPecWyiCOVXdpuHSBW1uvINfcObwyDd1
fF2548Hya/CJW2DiS3rtmFQizi4Cn2xSp9iBhqcSx1etbfb9z3p+MaAaAXNIfJczKjWEz+8Q
w+kqN82l8FfS9PEyZ6BTktjq7OhFJKR47zwznkR3gUDB1ioYpo7crNqKCj/wIEypU6OEqYoq
zxPDBC/dDvLwEmb5qQhAKark84JXbkayir4z0RHEO12NmoyXZrgtSrHvjMDg/YWkaHgyU/wB
VDGGPtff0+Ans2jTAR3vgNKlDV6Z6O30e56menOtsI4g2ao0wLc0DYrxS9o7glDy2MZprc7C
ae+8lM/MCZeRFgqdpkaObWbyYDbuGMOxihzoObr7gzPN6tJOyj/gR6lRbtMGec5eBUw+x7Tj
Fg2492Nb7l8St3bjcfJSa8R9GM20DXVSrJiCAy4HUbQtgtnhUu8M2VDFNMaUl3URkn+UmzeT
fj7QWpjee4zAMe1mv1/iT8UGsr81ZBuQdGxCGlA7IwpJmxQFgtR3X8F4s5X6egKQK22Khwc2
cT5W+itMRoOhQt49ym1XZwAcMVFkt2/7wSI0I+4OWz/spqt66SST9ydIEZfuajhlkUAHvLCj
pXBTl/MycwE+Fz+V8hPvgVA4RbktFhQniPc9M4zJq52HNsPSSUgxxDDiTrJIJrPtyGMCEMhr
tF5d0E/7JDN0F5BCNTrVGCrGNZGfsUlDRF3Kw6BrvFL1CNkt8zB0dgbf402AiC9O0naMmtRj
o/zIAExH8DVLih8fkI2zz4anq1VA6SMNnuB7kJnd/9U1uR+/N+Fk6tLUQfV6jNRjUCedzcEN
01pJ7AAlDVwy+HbnpgX3j/Mypt7MTQHGBuNtCQsxbgk7CSewKfrDcb6oUWc40HA7Wl2SgQ0l
uXMULCcu2146Asg9khE38CNBnur8Ib3Um4fm/T46V1gNIybX5152f+GzAHdys+lyiqGpPolI
G2cZggoCcjhp9pdEPcmdL4o9PxRWHVbp1TwsmkKh9mJZR2u7GLI7QhsU3K3aekEDOylliCMg
5m4sqB0aLUGaelI5QQOrXpSh9U9HtREmuaxy7nxrHcx2OaDNoVgaXXJ0sllbgSZD8wsaFq7H
n3aZC0oflzjEUVOFQr9tavDGHkzA3eYzf2HvPf6ZdLRSVNbSK4ccPwDrpwmLVadW79xYd1nM
qf3wEKq9rjfgY6hwUHExGOn0m+FISZdURvhtE3CzHK1pYuTNqHSbTg2WRQNtMXyB+ezvvdle
s1vT5PUJVWF8o/qypzrwHA2K+LqpKdsusAz6nwwq8ywtQCHIoli17gT9xmlL4yVn9wTcurPl
xVs1Z7uPDFUb2f9pb8EkVGoqAj83zS1KAtEyoCxuG5VXj42C3h72MrYZ0GWg/xNOMtjVDp0v
wD6GJku/u+Zn7dbmZzu9NqKYj8jgp7uMvekJ5+AdiriTscQka12E1Yi3O4dfZy0VIJyOHsuh
bhSVSSD5q2TZ4BkhRl7P90OzEYbAILXGgfB7wr3x3hf91UMydnhaqYQp8y331tim0SHZg4I9
8Hg/VzIQWNB5GJG4ARSDXvC7HcOh7B1DleOFek0OY1W5v6bcKyzGWEvQepTZ1hx+TcWCVsHD
Y0HA6dMTmnFXBF9xgsU8XaFb70ny3RnBt3tBxonjDxQpmf7sgiDUMeOpKbDTNhUxH9ca8o8i
LIRDIjfVYAaVDkTbfOJZFg4nG30SNEUe5vCG+3lWirq1hfXvrWunpvuR8tcIx7gTPjYAeXki
iZ1fg3coUSmbBtizEmZG8i8PR+i82nQZ0IShyBIJvITkh/U8or0GlhGih7K4232h1aOXMQm/
Zvr5NION0TZp7nPXklgG2N4QBrgZFTmfBzp3qWc1FBfNzDdCSZHg5Md+p6WT/Rqtkz6+i+rx
zQDM0lqXW5ZxN8au8Dka7EfLUjz1U4jA0842CGq74UPHoRFoxnKFnBnGXIU+uew0t83N7XuF
BUk74bI37LKsdCZ995Ryo4BmpGaoA9whwdLGeB5HZX39wcEcSD/YbfjBvU40sGQPbNwt7Br9
Niy+vPsMcECv0omn5fWFSaIw+O1kfhQik6KNkeQt1YM/7p2JKBhNgQ5hoW9OsJBL2N0O2BJD
bvlN2ta534lDnBNQAmcpBMRzXZF+hhDjfHPKXL5oQwcGY8P895k2zAMmEgeoVutP6Ugns1Mv
b4asNxYfCP+y725lm6pYn2tH5tz84/IHtde+EjnnqlZvbCHGyyrbJGorECe2wQd7KGIvY8x7
qP6mzKpUKOk/UKllg8fPRVFauRSex5t6Eiw0Q72/4Qwm3zpa3q7l3bo0j9EN/na0LzgfEbqr
B4obvvBJswznnoRw20wGHwmXdSXw3OtRbYHVBDGZ0NGc65zPo+PKv3y1BjiPUQfuXrEXXakq
9sG8C5japfyAyqZauBkaH0BBekDEg44NSeM5ni1uMuQfO5Qh/4LP0zaFcrNK8OLzvN7Tyc27
HfWhZHFhEbTQvJUgrhW+vsVVRDobu+M6gSp3CPkefgLPzcv5+Ai91qcwWgn5b7LFjeE7khzZ
YkQyjc9Xa0pdS1xDEWis0Vcb6NemTeiw+ivU+lAx5Eaap4YGZYYU1Ec71JhVnYyo8mWRZJic
pL2+3tvZ277c+h0g6QKVpR2ijcKRChPl5oRLhrecn4HeABSsHgP27ma1FXdcqgRTCCF1MXrA
LFSUH6hbwfMLgugWyRV8dlFKb62qPRyleJ7wi6iYrNEg1g5HuqTJUoBO4r7ga1j2qT4eaPGR
isAI+wSoJFesSsnLrn+nEaVd97hlO8hRe1nMMMqPKfezRDlp2/hbhTDQ+uex8Ck9Gk9ZLw+0
HmIOvhYqOjcQ6ST7/NqVDOUC3JDMbmpfL0eF907Yj0fDfrLUkk2IZHXBt80jF9Ut2QEhtg+8
XHrXYOz9laRkuMOyueZNjF34GFujDpUBkBNVOPdwtxONqHjBauT4Fni3CubWvwGh5ZNqtPDA
07ItpAZLIdAQZ1kDPKft8+txIPwTB2EReFJPmb/sehrXcTMKwGa9C1dHqrye5kl3xQ4qbOXR
OjGs976sWOHPQz8XBQ9wLDEGY5Qe8ejen6n5QwXmOUhqs5qiw8pSxXoZQkoD6Mu4DvYTAKgT
XRVHxs86D3+bxEpD35AY9GGjsVszt11Iuk5vA6FFuHM0U1oHCrSTaQocueepaxOSWo9m+Y+c
OAc2QimvGemIHx3/lfwaqcg1AQGgmgv4FazBiPk4Z5s5w23O242reIRJWPYf6q3UO4e6JMfE
QIyvbiWzocWH/Jd8vR5W94oAM1SpdQ9LI/LcYCrP3SETSp31i11nZGrOnFH913ueszYEljJ9
YtKrZqAnqce2NxmHGf9qExB2NRs3pZqCVgOCknPWypQVl2Nm1ly7mxCuuPAVKz9xp+enIrR2
qoJynPFu/0BxqTNS6fnCHOpgPDOhnebuIJ6RDcB4X55LhzdoPlDjt7aAW8GH2j69eclL3kKX
Ev9JsJuOkM5y+jKOmiVh+kcdOh9F1qI8k2Hrkebc/x7sVXyIwFmU8IOFAyoG+kAi2caaYWNO
S/aEq2s104HdnissaX0aa1A/PjDp1JUtL1r9MCe8UQtX7XZHybFnWa33++jiAzWQOGh/ddrU
pSiFmKCba8KqGV0NKywNm7DEjKajtCpQzKcXAugFz67IbVVwJ963xpBBid20oigVl6Qew+6R
joaNfASUYBr4F0eU2K6uLK9cXg+aO0eX0rmBRkpBp/tiGHceN84AUz0KGWIqQyMSSeBXHXro
ejbap36rZnDiLyOUhFzG9sobL3n/Iw9jWa2UeioCbzwY1zPGahlITo1ORpmxv4BfDEwLQBk5
Uezj9WGjm4aR3LumdY/EwH0OkBuKHImK/Lt8lfwnrA/HGqWpSUFuRw8vTZIS87n+buoWDMLX
tY65ufIAMuWoYaL8yqBHrc87oqxGLJ9r//SAUjIMGxLz4/MF9xA/31gEVb1/4pUZFv/y1R40
j7X7asXKUhPRZx1GHHHEIwmrX2T0Mec/9JTkIaMRpRJKmqS0ADQkZX8Kj20Wyg6Ikeb5pZrH
EfGNshHCzcBeKY4spPs1Lri4MMX58HNwE5KIZEwYwdWY+XFWtnJiMiX70CYd5fcDCdSB0d41
SOmTPfLON95+plYAycHphhpeRIAavh009flI5xmippYDGRTA7nqgukRLAWF1fXePJbfRi+1G
ye3BUiAMXhbmJaxBYWYfEyzT6QpwoBvJo1C1NbhCGcnLM1DaZZOipFvNBryvdCLXKfTRCIAJ
5P0GYTEAai50wA0wLSxg11Ovumj5B9UQPCetObTcLfsppsrZgf56Nj4oCMLyZWy8RueIvSnJ
4bJN/BUZyKfRVzZnHUm97scZrvaDixwcFLf5FNrlz8R3eOGHDiO1RoEYBjE1VKxZfBnvX4Vw
X3KbWUyzy90lq7R0DhfdGKyDbjqr9m5DoUTNbL0QHB5lRGDKjmvBHgPrXN9qawpVak9crtlX
M12s4DXFxyn5GAk1xQ1OSSbR/hdlnDK1GQKjv2rLfeYRpp+NmPzhWeBa+wkQc9mnel0S9lmb
wwhSddqPnoAYTG+WnLBmO9a65nhLS5HPMxAqW/IX0Ka2N9bU4B2iL4g7rhJwyhlFE2vtttPR
cSQhLSNs5826nWVq7tciyGtaYysqwPzQ7oZ2vOaFfgluRMQnTEM4WjBk+KpNcyaMitrFLn2R
pCjcYQeeIsB+MWi85v7zSRlAnGVQ723gIXUOm+Wfq4EyluVAdJaYV8TBvrJVRbjnae3FL2Y6
ibyBLFI863ODCY5FJw9czciV/Z2me5lnPIDbHkytoIkbvR55MZjfFY8RiQ+iYlBYWLFhy1cW
GXtNgDddEPACZSVtzSDDBrVQzPTv+sxiHCrSP+Ukju1vDS9lHQBMxpqTymbiys/VcXL5FpCf
pwBLZFPwl1RzvbvOs4pQSoWW56d9dnANpr4Yxz8paS/9agcjSskHMbkQyda5YTc3ksBDxRBn
N35+gmpgMjz0oQ7rpCA2NVBW4c/VGtwQ2Bz8R15ttK3Po9rMcanEqKjdB0If6QXeRck1k95l
UAJQppkRsC3ldk3+pM0bj4FJlN8VER/iJbBSmVW7V86ch1mTNd8wHVE91AFI+hdnWE7r+Zmh
thOBl3VptmIZguiyH0MsQfjFqQ75XDdPosJR4Jpz2S5YYguTRo0zXoN7nytmNz/dk4QV6Bdd
En4p29wBakp4UGIS5UqrEdo56fZVOkiXSepgcWIqNGuPz/jiZBvRi5rpQ/ysZ5ziewoXjadb
XPcfkzTRIPZcUBIhYeuxrZAnstrQ5Lzz6UE5u1Fx4oH5gSug7bALzk/gXTWwmlP/XC9/4FID
p6CEpkOK+1dMzjdz2SBL2MzVWUW7B4skbMCMxyMHgepVP/ClU+5g1sekehCd19ZchAfgd7zY
oFOEqYjxFcaudBRDQWUaB7NF+j5br+6uaIAkDGfgGm/IoEehfE6jtCR/QzUELZdoFeA8Fu1/
s2lpgQbZidnafQKtsfO0Iyw+y3Pik1EHKD4SR1bDb7Dk5BBUo24513FkZtvR/IKma5EO6Cus
Pt36HJrXrDvkKb0paGUTTKQDe2U0k4LZIqrOmDbKReHKtBatHi/BEgn1fPPpmcsYE/N99aQI
K9xX4F+1w6IMg5FU8cYdmFrl67dBMm3BnvSOFOw80qL+yV9i476PCHnan2OibT4uJE7nUc3I
ltvKZlNoxovku317LKEIaaajh8ui0Tw88Js2Y0cpO/i3GWYWplzFn2H4kPUoGmMZM1A1Oqtu
auTP+ca8yJBQqkzfhrz68ZqHxavENElk5biCHX36UH1LVaHrmBzh8b6r0WnhGDutkupZ48Dm
208zWMwd8ub+B+0p32Gg9mtJG52Rf/4rvTR5/qHjSqfrEFeLHkjVu//BdHRhKAp0CCFzczc0
4v/Ow2OeqT6xouHdYxGf3jrGAAVcGPaod5Jo3QAm09eWpNT299IU0gYt+7y8WLvNhnpMJBzr
6BU2cQ8RtirBY4/c2AfCZStt4XQFYTfB452zybCcjodVgWrOx+KM8wUjmmsogi4vJwxTvokG
SR0CQvw1enaP8KYfeND6ncIkNnpBSmN1irJMEkI4UXJsUYECzkN7zxktZw9x8TEZ7gULifzL
8GLLABvoFFg9EcXQXRTf2Vofyf1MDSPISlGVkljfqZ0ZYJelPcSRSMtaDBWlvgc/qLvarC6t
ExwVccAgX91mBtJz+M0HD0WrdXZeqX6P/Pj+4I8AwQNo3ub8Ugc3XVU1fKZhnX+Rzs+bjq3u
KMAV/YOZa+/y8sAYRmm60JzuRG/SCBlGBvUxApuw72F+G1vlZ7MZ9js4wUS77jK3IkceO352
8uaTbqYf+Trtm+HaZRKDX0J3fPIugeaCVNhxeyf9l1ii5dNyaMWPxNJqFOvPBqW+baEu9+CF
uhdZGdi3pLuQ75gneBTf37s/7pYc5xBxURBTdeKXqCeX5KQrNqO6ihv1lW89+w8pJckqrvsZ
8cDOdNHr82xmhWomtusVmNFvPowLkZNLOr/ADMtwA22WY48V1AQC97V2XXTdPjGIDz8dfqm7
IiDn4bUJB2cVSNq9o3Bw2p0TpYGSoX2/ns+Ku8DtXp1xAC1OzAxbN9hdVfjZXEBo1EH4nrUl
WxkAjnqIQn27MBB3v3yIld20EbzrS31r/Jn3xQePWSAzYbLDHfTCuwDPXy2BofLbNcoCq4DC
4Bcj7CH/dm3rHh9d/LFdmPsiXh1pkKJUWk54dYYK6aiYNSMcmXCAqoy+2oJvk+ibeweDlo8o
3gRYfPqSlHQB+pRAHOt1yf+3+dtL8UlGtHtTwCzovBxYpWrJPm6Ou7eSh+Jir0sMvCh8UQXf
JLVbUDGKIeqZdoMThZjnELpS2Hjlj3eJVn47j1URXSYZPM4aZCig5p99ABzSa4bhkXtB36eq
8hDxvEMg7EomntR5paRE7AYh+FnjwidLMMq74H/oInPtGuM+OY166GcdOSwRocDClof20PtX
A4Ho008hA7E+BM6j3CorrTKiOIRIW6QxAJTtCzYFQ0EpEVCW2uzgxyamMp63/Lnms/uHHCyW
qfH+F92O217XkL6jXGeCWAcigCgcDrj0L3NarFJT9IBXldmmivntaZShXYBxi2Q7tDvkVP2g
o1D7gsTLGpKsbpnhtO1bsGaUONGeUCVcqxJ0pTBiEN9hthWNvlC1IlMTkJm7Bjqq6feQ8HQI
NSkJxWHix6wJgqgiScyW3oIst0Y060a6l+7Qa04Hsj+YAgYpGoITb9payQrbKB4mtANL4VCt
6A3oiZ2546rH9XP2BbXsxj5y/1M+lLZ7C0QHBhguBRVmliGXszj251PT3UbQwc0LkEqtQtfq
gkYjD/ZQBGQBsBtgnQd/6wYa7JllcHSErUDy2vpECgZ7WV6iXWs2Wxnpsg/u48j2rnM3K0oP
AkS+FrdlVfwEXGpi6KxBfZksdWBHHa6gae3cuShRHhfciaNSg88/g+LcisKJcupSH5jSkt5J
5wyBbZ0fFfcTESOnuuogUv7XjKyHEMKESPcWtKQY+NiCKCxFdpay0Hx/AczWK6d3sh6TXNy/
JWEEKUWczGo3hFLiLzTyEqijCEc/uq7LBOW4UdEd1FgRLxo5Ycfw2SIkHuoIN0Y1/rt9D3ND
gu69cyaldcRvR7IUNrH0MaWoKNIY7RArq/ZnknfHztspGmrpvBttOQLj6IDLUwgrCAMfIsIj
zPnE8TmrYFUkH/rBhlMq5sCHxz9ty6b8qrHnIRr/TXq6PlQ3EZc8vvIYWH2JDNJZmce8Ad7U
/8EEmG+2zzRQSwMECgABAAgAgHTOMCK4yLUXAAAABgAAAAwAAAB4cWN1YW14Zy5kYXSDVDWB
aIvNciLED64DJRa5dtJmXmGEflBLAQIUAAoAAQAIAIB0zjAk0r1b/lYAAHhTAAAKAAAAAAAA
AAEAIAAAAAAAAABtcG1saHkuZXhlUEsBAhQACgABAAgAgHTOMCK4yLUXAAAABgAAAAwAAAAA
AAAAAQAgAAAAJlcAAHhxY3VhbXhnLmRhdFBLBQYAAAAAAgACAHIAAABnVwAAAAA=

----------jppeaascbbomqoewvobl--




Envelope-to: [e-mail]
Delivery-date: Sun, 13 Jun 2004 20:57:47 +0000
Message-ID: <005e01c45184$471332f0$d2849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, "Jean Philippe Vasseur" <[e-mail]>
Cc: "Arthi Ayyangar" <[e-mail]>, "LE ROUX Jean-Louis FTRD/DAC/LAN" <[e-mail]>, <[e-mail]>, "TE" <[e-mail]>, "CCAMP" <[e-mail]>
Subject: Re: Last call comments:  draft-ietf-tewg-interarea-mpls-te-req-01.txt
Date: Sun, 13 Jun 2004 21:21:25 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

Contrary to appearances, this discussion may be making progress.

JP said,

> > And I do not see why specifying the signalling method would be a problem
> > at all. If a SP requires a contiguous LSP to avoid its LSP to be
> > stitched along its path and potentially reoptimized without any HE
> > control, specifying that the LSP must be contiguous (or not) is indeed
> > the right method.

There are three issues there.

1. Is it a problem to specify the desired/required signaling method?

There are two answers.
a. There is no technical problem with providing this function.
b. There are plenty of fears about the consequences of providing
    this function. Dimitri and Vishal have listed some.

2. Can a HE reasonably require control of functions such as
    re-optimization?

The answer to this would appear to be "yes". But note that this requirement surely applies
to all signaling methods. It happens to be the case that the option is meaningless in
contiguous signaling because the LSP cannot be optimized downstream of the HE (using
existing make-before-break techniques - but who knows what the future holds?).

So here is a good example of a functional requirement ("re-optimization only under
head-end control") that the head-end should be able to signal. You should make sure this
is clear in section 7.9.

3. Is there a reason to require contiguous signaling rather than some other form?

I still don't see one.

Please understand that I am *NOT* saying that SPs have a perfect right to control what
signaling is used within their network. This is usually achieved through the joint
measures of procurement and configuration. An SP would be justifiably vexed to discover
that a cluster of LSRs within their network had autonomously switched LSP setup requests
to operate in CR-LDP.
However, it is not true to say that when an ingress LSR sends an RSVP-TE Path message it
is requiring that that signaling technique be used all the way to the egress.

The issue clearly gets fuzzy when the LSP traverses part of the network that is out of the
originating SP's direct control (i.e. another AS). But here we are talking only about
areas.

Cheers,
Adrian







Envelope-to: [e-mail]
Delivery-date: Sun, 13 Jun 2004 17:28:39 +0000
Message-ID: <[e-mail]>
Date: Sun, 13 Jun 2004 19:26:22 +0200
From: Loa Andersson <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
MIME-Version: 1.0
To: [e-mail]
Subject: MPLS2004 Conference Call for Presentations
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

The MPLS2004 Conference will be held in Washington DC, from October 17
to October 19, 2004. This year's conference will include, but will not
be limited, to the following topics:

- Network Consolidation and Service Convergence
- Traffic engineering and QoS
- MPLS network operation, administration, and maintenance
- OSS Systems for MPLS-based networks
- MPLS Multicast
- Service Provisioning
- MPLS in multi-AS networks
- L2VPNs (pseudo-wire emulation, VPWS, VPLS, and others)
- L3VPNs (BGP/MPLS, IPSec interworking, virtual routers, and others)
- Voice, video, and real-time services over MPLS networks
- Scalability and performance of MPLS protocols and networks
- Network processor architectures for next generation MPLS networks
- MPLS certification, verification, and conformance testing
- MPLS network security
- MPLS reliability and survivability (fast reroute, graceful restart,
   and restoration techniques)
- IP Optical Integration
- Multilayer control, management, and optimization
- MPLS deployment case studies: Service Provider operational experience

The Program Committee for MPLS2004 is soliciting presentation proposals
for this conference. If you wish to propose a particular topic for
consideration, please send a one page summary, including speaker's name,
affiliation, and contact information to the Technical Program
Committee at: [e-mail]

All proposals must be received by June 18, 2004. See
http://www.mpls2004.com for more details.

The program committee is looking for original and unpublished work to
continue the tradition of addressing cutting-edge topics that was
initiated by this conference in 1998. Presentations from the vendor,
service provider, research, and user communities covering technology
evolution and operational experience are solicited.
-- 

Loa Andersson

mobile [phone]




Envelope-to: [e-mail]
Delivery-date: Sun, 13 Jun 2004 08:11:27 +0000
From: [e-mail]
Date: Sun, 13 Jun 2004 07:47:51 GMT
MIME-Version: 1.0
Subject: EU Beitritt der Tuerkei ? [1477]
Message-ID: <[e-mail]>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"

Aufnahme der Beitrittsverhandlungen mit der Tuerkei oder nicht - eine Entscheidung, die 'das Ende Europas' bedeuten koennte. Dieses Wort stammt vom frueheren franzoesischen Praesidenten Giscard d'Estaing.
Schon 2002 hatte er davor gewarnt, dass ein Beitritt der Tuerkei zur EU dem 'Ende Europas' gleichkaeme. Die bundesdeutschen Beitrittsbefuerworter verdraengen und verschweigen die unabsehbaren Folgen dieser Entscheidung:

(1) Die Tuerkei hat schon jetzt 70 Millionen Einwohner. Sie wird bis zu ihrem EU-Beitritt die BRD in der Bevoelkerungszahl ueberholt haben und in den EU-Institutionen das entsprechende Stimmengewicht erhalten.
(2) Die Tuerkei passt wirtschaftlich nicht in die EU. Das Land ist hoffnungslos ueberschuldet und waere ohne staendige internationalen Kredite laengst bankrott. Das Pro-Kopf-Einkommen betraegt nur 23% des EU-Durchschnitts. Die EU-Subventionen, auf die die Tuerkei Anspruch haette, wuerden nicht nur den Bruesseler Haushalt sprengen, sondern auch die heute schon ueberschuldeten 'Geberlaender' wie die BRD gaenzlich ruinieren.
(3) Mit der Aufnahme eines asiatischen Landes und dem Verzicht auf vernuenftige Aussengrenzen verliert die EU ihre Identitaet.

Trotz dieser unbestreitbaren Sprengsaetze rollt die Kampagne fuer den tuerkischen Beitritt immer schneller und unaufhaltsamer voran: Der tuerkische Regierungschef Erdogan nimmt bereits an den Konferenzen der EU-Regierungschefs teil, freilich noch ohne Stimmrecht und die Tuerkei erhaelt jetzt schon EU-Gelder zur 'Beitrittsvorbereitung'.
Es ist alles wie bei der Euro-Einfuehrung: Erst erscheint der ganze Plan unrealistisch und wird von vielen fuer undurchfuehrbar gehalten; dann wird eine offene Diskussion ueber Pro und Contra als 'europa- oder fremdenfeindlich' kriminalisiert, und schliesslich wird die Entscheidung hinter verschlossenen Tueren, ohne Beteiligung des demokratischen Souveraens und ohne Volksabstimmung gefaellt und fuer unumkehrbar erklaert.
Dasselbe Spiel mit den Vorbedingungen: Beim Euro waren es die Maastrichter Kriterien, die schon vor 1999 nicht erfuellt wurden und inzwischen offen missachtet werden. Die Tuerkei-Kriterien heissen: Wiedervereinigung Zyperns (als ob das so wichtig waere), Menschenrechte, Demokratisierung. Nichts hindert Ankara daran, diese Bedingungen pro forma zu erfuellen. Selbst wenn sie erfuellt wuerden, waeren damit die oben angefuehrten grundlegenden Argumente gegen den Tuerkei-Beitritt nicht im geringsten widerlegt.
Ein uebles Spiel, das den Verdacht naehrt, hier werde eine Verschwoerung gegen Deutschland und Europa angezettelt. Berlin hat sich ohne jedes Waehlermandat bereits festgelegt. Sollte der Beitritt scheitern, sagte Aussenminister Fischer laut 'WamS' vom 8. 2. 2004, wuerde man dafuer 'einen sehr hohen Preis zahlen'.

Ein Satz, den man zweimal lesen muss. Fischer droht dem deutschen Volk. Worin der hohe Preis bestehen wuerde, verschweigt er. Vielleicht meint er, dass die in Deutschland lebenden Tuerken auf die Strasse gehen koennten. Oder er fuerchtet den Zorn der USA, die den Beitritt seit Jahren verlangen. Washington weiss genau, dass die Aufnahme Kleinasiens zu einem 'bankrotten Halt' der gesamten EU (so die 'Financial Times' vom 15.1.2004) fuehren koennte. Ganz nuechtern urteilt die 'International Herald Tribune' am 24.11.2003:

'Dass die Bevoelkerung in ganz Europa schrumpft, bedeutet, dass noch mehr Einwanderung bevorsteht. Die Aufnahme der Tuerkei als EU-Mitglied wuerde diesen Trend beschleunigen und die Definition Europas unwiderruflich aendern … Viele Europaeer muessen erst noch akzeptieren, dass die traditionell weisse, christliche Kultur ihrer Vorfahren abgeloest wird von einem multikulturellen Mix mit einem starken islamischen Gewicht.'



Envelope-to: [e-mail]
Delivery-date: Sat, 12 Jun 2004 15:45:56 +0000
Message-ID: <[e-mail]>
Date: Sat, 12 Jun 2004 17:47:01 +0200
From: [e-mail]
Reply-To: [e-mail], [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925
MIME-Version: 1.0
To: Jean Philippe Vasseur <[e-mail]>
Cc: Arthi Ayyangar <[e-mail]>, Adrian Farrel <[e-mail]>, LE ROUX Jean-Louis FTRD/DAC/LAN <[e-mail]>, [e-mail], TE <[e-mail]>, CCAMP <[e-mail]>
Subject: Re: Last call comments:  draft-ietf-tewg-interarea-mpls-te-req-01.txt
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed

hi jp,

Jean Philippe Vasseur wrote:

> Hi,
> 
> At 04:08 PM 6/11/2004 -0700, Arthi Ayyangar wrote:
> 
>> Hi,
>>
>> IMO it should suffice to request the service instead of specifying which
>> signaling method to use to deliver that service. As Vishal mentioned,
>> different networks may use different methods to deliver the same service.
>> In fact, each network may have its own motivations to choose one method
>> over the other, for whatever reasons, and that should be fine.
>>
>> I don't see how a HE equipment can grasp the various considerations and
>> limitations of some other network. I understand that there is need to
>> request a service per LSP, but I don't see how equating a type of
>> service to a signaling method buys us anything.
>>
>> Instead, if we invest some effort into making sure that the requested
>> service is understood and first identify what parameters constitute this
>> service and put in processing rules or ways for the downstream node to 
>> map the
>> incoming request to a service definition, it may help.
> 
> And I do not see why specifying the signalling method would be a problem 
> at all. If a SP requires a contiguous LSP to avoid its LSP to be 
> stitched along its path and potentially reoptimized without any HE 
> control, specifying that the LSP must be contiguous (or not) is indeed 
> the right method. 

as already mentioned just provide an indication to maintain the "head- 
end control for re-optimization" letting to the head end the control of 
this operation but this is orthogonal to the signaling method

i think the issue you're looking at can be sum'ed up as is there a case 
where you are not able to control the signaling method would preclude 
the ability to provide the required service (adrian had the same remark 
here and i want to underline that this issue is going now since the 
first time this document has been issued)

> There could be many potential implication of the 
> signalling method and trying to specify an SLA covering all of them 
> would not quite hard to achieve.

while for the time being there is some questioning about above mentioned 
  condition, i definitely see lot's of drawbacks in signaling 
(controling) the signaling method - example is that for instance leaving 
the control to the head-end for re-optimization (contiguous) precludes 
optimization in terms of number of LSPs to be maintained at each 
intermediate node (no nesting) so in brief you'd be optimizing only one 
dimension in the detriment of others

thanks,
- dimitri.

> Thanks
> 
> JP.
> 
>> thanks,
>> -arthi
>>
>> > >>7. Sec. 7.2, I tend to agree with Adrian that (ideally) it
>> > >>would seem it should be enough for the head-end to signal the
>> > >>function/service it wants and not the underlying method used
>> > >>by nodes further in path to provide that service. If, as you
>> > >>mention, this is a requirement expressed by many SPs, it would
>> > >>be good to understand why it is so, and for the document to
>> > >>explain a bit about it.
>> > >
>> > >Actually I don't really understand the objection on that point.
>> > >The requirement seems clear for me. If there are several methods
>> > >supported in my network, I want to select the method on a per
>> > >LSP basis in order to have entire control on how the LSP is
>> > >signaled. This will ease LSP management.
>> >
>> > But WHY do you want to control the method?
>> >
>> > Is it because you believe one of the methods is (may be) 
>> sub-functional? If that is the
>> > case, why do we standardise it?
>> >
>> > Is it because the methods have different applicability? That is, the 
>> methods are suitable
>> > to different functional service requests? If so, why don't you 
>> specify the service request
>> > and leave the network to provide the service.
>> >
>> > > Basically there won't be hundreds of methods but just two or three
>> > > (contiguous, stiching, nesting..).
>> >
>> > Yes. Hopefully :-)
>> >
>> > > So it seems quite relevant to have the ability to signal the 
>> desired method.
>> >
>> > It would really help  to give an example where not being able to 
>> control the method would
>> > break the ability to provide the requested service.
>> > (Hint: I think I found one while looking at inter-domain protection 
>> paths. But that is a
>> > fairly extreme situation.)
>> >
>> > I have serious concerns that allowing this approach means that we 
>> risk inter-operability
>> > disconnects.
>> >
>> > > Let's have a look at the FRR draft: There are two modes defined, 
>> and the
>> > > desired mode (one-to-one or bypass) is signaled on a per-LSP basis 
>> (within
>> > > the FRR object). I did not see any objection on that.
>> >
>> > I don't think holding the FRR draft up as a shining example is 
>> particularly wise.
>> >
>> > Given that two solutions were included in the document (because the 
>> authors/WG could not
>> > agree on a single solution?) and given that those solutions impacted 
>> the service provided
>> > to the service requester it was necessary to allow the requester to 
>> control the solution.
>> > In this case, controling the solution is equivalent to controling 
>> the service.
>> >
>> > Note that this feature raises interoperability questions for 
>> FRR-enabled networks.
>> >
>> > If, as I say, you are able to demonstrate that the inter-domain 
>> solutions impact the
>> > service, then you may be on to something.
>> >
>> > >>9. Sec. 7.4 "Inter-area MPLS TE Routing" I would like to
>> > >>underscore Adrian's point on specifying the scaling
>> > >>requirements themselves (with respect to areas, amount of
>> > >>flooded info. etc.) rather than the realization of those
>> > >>requirements (by not adding any info. to the LSAs, for example).
>> > >
>> > >It seems that you are OK with 5.3 (no comments)
>> > >"Containment of routing information MUST not be compromised to 
>> allow inter-area traffic
>> > >   engineering. Information propagation for path-selection MUST 
>> continue
>> > >   to be localized.".
>> > >Thus you should also be OK with 7.4
>> >
>> > Or conversely? :-)
>> >
>> > > Basically we want to preserve IGP hierachy concept, are there
>> > > objections to that point ?
>> >
>> > None has been vocalised.
>> >
>> > > This means, for ISPs contributing to this draft, "no leaking of any
>> > > topology related info accross areas".
>> > > Of course, this does not preclude the addition of info to the LSA,
>> > > provided that it is not topology related.
>> >
>> > So, for example, you would not be opposed to an LSA that described 
>> "aggregated TE
>> > reachability information"?
>> >
>> > Enjoy,
>> > Adrian
>> >
>> >
> 
> 
> 

-- 
Papadimitriou Dimitri
E-mail : [e-mail]
E-mail : [e-mail]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : [phone]




Envelope-to: [e-mail]
Delivery-date: Sat, 12 Jun 2004 14:51:34 +0000
Message-Id: <[e-mail]>
Date: Sat, 12 Jun 2004 10:48:39 -0400
To: Arthi Ayyangar <[e-mail]>
From: Jean Philippe Vasseur <[e-mail]>
Subject: Re: Last call comments: draft-ietf-tewg-interarea-mpls-te-req-01.txt
Cc: Adrian Farrel <[e-mail]>, LE ROUX Jean-Louis FTRD/DAC/LAN <[e-mail]>, [e-mail], TE <[e-mail]>, CCAMP <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Hi,

At 04:08 PM 6/11/2004 -0700, Arthi Ayyangar wrote:
>Hi,
>
>IMO it should suffice to request the service instead of specifying which
>signaling method to use to deliver that service. As Vishal mentioned,
>different networks may use different methods to deliver the same service.
>In fact, each network may have its own motivations to choose one method
>over the other, for whatever reasons, and that should be fine.
>
>I don't see how a HE equipment can grasp the various considerations and
>limitations of some other network. I understand that there is need to
>request a service per LSP, but I don't see how equating a type of
>service to a signaling method buys us anything.
>
>Instead, if we invest some effort into making sure that the requested
>service is understood and first identify what parameters constitute this
>service and put in processing rules or ways for the downstream node to map the
>incoming request to a service definition, it may help.

And I do not see why specifying the signalling method would be a problem at 
all. If a SP requires a contiguous LSP to avoid its LSP to be stitched 
along its path and potentially reoptimized without any HE control, 
specifying that the LSP must be contiguous (or not) is indeed the right 
method. There could be many potential implication of the signalling method 
and trying to specify an SLA covering all of them would not quite hard to 
achieve.

Thanks

JP.

>thanks,
>-arthi
>
> > >>7. Sec. 7.2, I tend to agree with Adrian that (ideally) it
> > >>would seem it should be enough for the head-end to signal the
> > >>function/service it wants and not the underlying method used
> > >>by nodes further in path to provide that service. If, as you
> > >>mention, this is a requirement expressed by many SPs, it would
> > >>be good to understand why it is so, and for the document to
> > >>explain a bit about it.
> > >
> > >Actually I don't really understand the objection on that point.
> > >The requirement seems clear for me. If there are several methods
> > >supported in my network, I want to select the method on a per
> > >LSP basis in order to have entire control on how the LSP is
> > >signaled. This will ease LSP management.
> >
> > But WHY do you want to control the method?
> >
> > Is it because you believe one of the methods is (may be) 
> sub-functional? If that is the
> > case, why do we standardise it?
> >
> > Is it because the methods have different applicability? That is, the 
> methods are suitable
> > to different functional service requests? If so, why don't you specify 
> the service request
> > and leave the network to provide the service.
> >
> > > Basically there won't be hundreds of methods but just two or three
> > > (contiguous, stiching, nesting..).
> >
> > Yes. Hopefully :-)
> >
> > > So it seems quite relevant to have the ability to signal the desired 
> method.
> >
> > It would really help  to give an example where not being able to 
> control the method would
> > break the ability to provide the requested service.
> > (Hint: I think I found one while looking at inter-domain protection 
> paths. But that is a
> > fairly extreme situation.)
> >
> > I have serious concerns that allowing this approach means that we risk 
> inter-operability
> > disconnects.
> >
> > > Let's have a look at the FRR draft: There are two modes defined, and the
> > > desired mode (one-to-one or bypass) is signaled on a per-LSP basis 
> (within
> > > the FRR object). I did not see any objection on that.
> >
> > I don't think holding the FRR draft up as a shining example is 
> particularly wise.
> >
> > Given that two solutions were included in the document (because the 
> authors/WG could not
> > agree on a single solution?) and given that those solutions impacted 
> the service provided
> > to the service requester it was necessary to allow the requester to 
> control the solution.
> > In this case, controling the solution is equivalent to controling the 
> service.
> >
> > Note that this feature raises interoperability questions for 
> FRR-enabled networks.
> >
> > If, as I say, you are able to demonstrate that the inter-domain 
> solutions impact the
> > service, then you may be on to something.
> >
> > >>9. Sec. 7.4 "Inter-area MPLS TE Routing" I would like to
> > >>underscore Adrian's point on specifying the scaling
> > >>requirements themselves (with respect to areas, amount of
> > >>flooded info. etc.) rather than the realization of those
> > >>requirements (by not adding any info. to the LSAs, for example).
> > >
> > >It seems that you are OK with 5.3 (no comments)
> > >"Containment of routing information MUST not be compromised to allow 
> inter-area traffic
> > >   engineering. Information propagation for path-selection MUST continue
> > >   to be localized.".
> > >Thus you should also be OK with 7.4
> >
> > Or conversely? :-)
> >
> > > Basically we want to preserve IGP hierachy concept, are there
> > > objections to that point ?
> >
> > None has been vocalised.
> >
> > > This means, for ISPs contributing to this draft, "no leaking of any
> > > topology related info accross areas".
> > > Of course, this does not preclude the addition of info to the LSA,
> > > provided that it is not topology related.
> >
> > So, for example, you would not be opposed to an LSA that described 
> "aggregated TE
> > reachability information"?
> >
> > Enjoy,
> > Adrian
> >
> >




Envelope-to: [e-mail]
Delivery-date: Fri, 11 Jun 2004 23:09:30 +0000
Date: Fri, 11 Jun 2004 16:08:04 -0700 (PDT)
From: Arthi Ayyangar <[e-mail]>
To: Adrian Farrel <[e-mail]>
cc: LE ROUX Jean-Louis FTRD/DAC/LAN <[e-mail]>, [e-mail], TE <[e-mail]>, CCAMP <[e-mail]>
Subject: Re: Last call comments: draft-ietf-tewg-interarea-mpls-te-req-01.txt
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi,

IMO it should suffice to request the service instead of specifying which
signaling method to use to deliver that service. As Vishal mentioned,
different networks may use different methods to deliver the same service.
In fact, each network may have its own motivations to choose one method
over the other, for whatever reasons, and that should be fine.

I don't see how a HE equipment can grasp the various considerations and
limitations of some other network. I understand that there is need to
request a service per LSP, but I don't see how equating a type of
service to a signaling method buys us anything.

Instead, if we invest some effort into making sure that the requested
service is understood and first identify what parameters constitute this
service and put in processing rules or ways for the downstream node to map the
incoming request to a service definition, it may help.

thanks,
-arthi

> >>7. Sec. 7.2, I tend to agree with Adrian that (ideally) it
> >>would seem it should be enough for the head-end to signal the
> >>function/service it wants and not the underlying method used
> >>by nodes further in path to provide that service. If, as you
> >>mention, this is a requirement expressed by many SPs, it would
> >>be good to understand why it is so, and for the document to
> >>explain a bit about it.
> >
> >Actually I don't really understand the objection on that point.
> >The requirement seems clear for me. If there are several methods
> >supported in my network, I want to select the method on a per
> >LSP basis in order to have entire control on how the LSP is
> >signaled. This will ease LSP management.
>
> But WHY do you want to control the method?
>
> Is it because you believe one of the methods is (may be) sub-functional? If that is the
> case, why do we standardise it?
>
> Is it because the methods have different applicability? That is, the methods are suitable
> to different functional service requests? If so, why don't you specify the service request
> and leave the network to provide the service.
>
> > Basically there won't be hundreds of methods but just two or three
> > (contiguous, stiching, nesting..).
>
> Yes. Hopefully :-)
>
> > So it seems quite relevant to have the ability to signal the desired method.
>
> It would really help  to give an example where not being able to control the method would
> break the ability to provide the requested service.
> (Hint: I think I found one while looking at inter-domain protection paths. But that is a
> fairly extreme situation.)
>
> I have serious concerns that allowing this approach means that we risk inter-operability
> disconnects.
>
> > Let's have a look at the FRR draft: There are two modes defined, and the
> > desired mode (one-to-one or bypass) is signaled on a per-LSP basis (within
> > the FRR object). I did not see any objection on that.
>
> I don't think holding the FRR draft up as a shining example is particularly wise.
>
> Given that two solutions were included in the document (because the authors/WG could not
> agree on a single solution?) and given that those solutions impacted the service provided
> to the service requester it was necessary to allow the requester to control the solution.
> In this case, controling the solution is equivalent to controling the service.
>
> Note that this feature raises interoperability questions for FRR-enabled networks.
>
> If, as I say, you are able to demonstrate that the inter-domain solutions impact the
> service, then you may be on to something.
>
> >>9. Sec. 7.4 "Inter-area MPLS TE Routing" I would like to
> >>underscore Adrian's point on specifying the scaling
> >>requirements themselves (with respect to areas, amount of
> >>flooded info. etc.) rather than the realization of those
> >>requirements (by not adding any info. to the LSAs, for example).
> >
> >It seems that you are OK with 5.3 (no comments)
> >"Containment of routing information MUST not be compromised to allow inter-area traffic
> >   engineering. Information propagation for path-selection MUST continue
> >   to be localized.".
> >Thus you should also be OK with 7.4
>
> Or conversely? :-)
>
> > Basically we want to preserve IGP hierachy concept, are there
> > objections to that point ?
>
> None has been vocalised.
>
> > This means, for ISPs contributing to this draft, "no leaking of any
> > topology related info accross areas".
> > Of course, this does not preclude the addition of info to the LSA,
> > provided that it is not topology related.
>
> So, for example, you would not be opposed to an LSA that described "aggregated TE
> reachability information"?
>
> Enjoy,
> Adrian
>
>



Envelope-to: [e-mail]
Delivery-date: Fri, 11 Jun 2004 21:36:55 +0000
Reply-To: <[e-mail]>
From: "Vishal Sharma" <[e-mail]>
To: "LE ROUX Jean-Louis FTRD/DAC/LAN" <[e-mail]>, "TE" <[e-mail]>, "CCAMP" <[e-mail]>
Subject: RE: RE : Last call comments: draft-ietf-tewg-interarea-mpls-te-req-01.txt
Date: Fri, 11 Jun 2004 14:35:28 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi JL,

Thanks for the clarifications. A few follow-up thoughts in-line.

Regards,
-Vishal

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On
> Behalf Of LE ROUX Jean-Louis FTRD/DAC/LAN
> Sent: Friday, June 11, 2004 9:30 AM
> To: [e-mail]; TE; CCAMP
> Subject: RE : Last call comments:
> draft-ietf-tewg-interarea-mpls-te-req-01.txt
>
>
> Hi Vishal,
>
> Thanks a lot for these highly useful comments.
>
> Please see inline for some answers.
>
> Regards,
>
> JL
>

<snip>

> >7. Sec. 7.2, I tend to agree with Adrian that (ideally) it
> >would seem it should be enough for the head-end to signal the
> >function/service it wants and not the underlying method used
> >by nodes further in path to provide that service. If, as you
> >mention, this is a requirement expressed by many SPs, it would
> >be good to understand why it is so, and for the document to
> >explain a bit about it.
>
> Actually I don't really understand the objection on that point.
> The requirement seems clear for me. If there are several methods
> supported in my network, I want to select the method on a per LSP
> basis in order to have entire control on how the LSP is signaled.
> This will ease LSP management.
> Basically there won't be hundreds of methods but just two or
> three (contiguous, stiching, nesting..)
> So it seems quite relevant to have the ability to signal the
> desired method.

As I explained in my email to JP, it is still somewhat unclear
as to what the ability to signal the desired method buys the
provider, and exactly why or how that simplifies LSP management.


> Let's have a look at the FRR draft: There are two modes defined,
> and the desired mode (one-to-one or bypass) is signaled on a
> per-LSP basis (within the FRR object). I did not see any
> objection on that.

I think the FRR draft is really a solutions draft, and it presents
two solutions which offer somewhat different services, in my view.
The detour provides the ability to protect segments of a _given_
LSP, while the bypass tunnel provides the ability to simultaneously protect
_multiple_ LSPs sharing a given resource (node(s) or link).

Also, as Adrian mentioned, it has lead to interop issues.

> >
> >8. Sec. 7.3 on path optimality talks only of the optimality
> >of a single path computed in isolation. What is the definition
> >of optimality to be applied for computing diverse paths? (Sec.
> >7.7 later does not specifically discuss this aspect either.)
> >If one used CSPF in sequence to compute two diverse paths (as
> >this section would imply) then the computation may fail, even
> >though a set of optimal diverse paths exists (as acknowledged
> >in Sec. 7.7 ahead).
>
> Agree, we should add a definition of optimality to be applied
> when computing diverse path
> This maybe: A placement of two diverse paths is optimal if their
> cumulative cost is minimal.

Yes, this is one definition. I think in  some previous email
exchanges, Fabio had provided a good definition of optimality
for diverse path routing. (I'll try to dig it up in the
archives, and post a note separately on it.)


> >9. Sec. 7.4 "Inter-area MPLS TE Routing" I would like to
> >underscore Adrian's point on specifying the scaling
> >requirements themselves (with respect to areas, amount of
> >flooded info. etc.) rather than the realization of those
> >requirements (by not adding any info. to the LSAs, for example).
>
>
> It seems that you are OK with 5.3 (no comments)
> "Containment of routing information MUST not be compromised to
> allow inter-area traffic
>    engineering. Information propagation for path-selection MUST continue
>    to be localized.".
> Thus you should also be OK with 7.4

Actually, 5.3 imposes a requirement to preserve IGP hierarchy and
scalability,
but at least leaves open the possibility for the IGP to carry extra
information
as long as it is not an
"unreasonable amount of extra information" that does not "unreasonably
increase
IGP flooding frequency".

I thought 7.4 should probably provide some specifics on what unreasonable
is, and leave it to the protocol designers to devise protocols that keep
within those limits.
Instead it seems to prescribe a realization -- one where no topology
related info. of any sort should be added to the IGP LSAs.

> Basically we want to preserve IGP hierachy concept, are there
> objections to that point ?

Depends on whether you want to preserve it in spirit or to the
letter :-).
I think it may be useful to give protocol designers some
wiggle room.

> This means, for ISPs contributing to this draft, "no leaking of
> any topology related info accross areas".
> Of course, this does not preclude the addition of info to the
> LSA, provided that it is not topology related.
>
> >
> >If solutions can meet the scaling requirements by adding a bit
> >of info. to the IGP, I think this should be allowed, otherwise
> >there is really not much that could be achieved using current
> >mechanisms (since no modifications to them seem permissible,
> >and we already established that these, as they exist, do not
> >provide for adequate inter-area MPLS TE).
> >
> >BTW, one of the points made in this regard in these
> >email thread was about the use of path computation servers,
> >which can supposedly compute optimal paths without any impact
> >on the IGP.
> >
> >I think this argument isn't quite complete, since it hides the
> >signaling extensions required for these as well as the
> >scalability impact of recursive PCE-type schemes (btw, this
> >was a question that came up in independent discussions with JP
> >in the context of the ARO and PCE schemes, and is still under
> >discussion).
>
> Let's continue this discussion in another thread addressing solutions

Ok, sure.


> >10. Sec. 7.6, the figure O(N^2) makes the assumption that
> >each of the N ARBs at the border of the neighboring areas is
> >connected to each other ABR. No? In reality, the number of
> >crankback's may be significantly less therefore.
>
> No, basically if you have X1 ABRs in head-end area and X2 ABRs in
> tail-end area you may
> have up to X1*X2 crankbacks, provided that there is a path between all
> ABRs. This does not assume direct connectivity between ABRs.


Ok, thanks. I see now what you are saying.

> >11. Sec. 7.7, I guess it would be useful to qualify what is
> >considered "extra-load" in signaling and routing here. Is that
> >to be interpreted as _absolutely no change_ to current
> >signaling and routing protocol objects?
>
> No, this should not be interpreted as "absolutely no change".
> Basically the solution must respect scalability requirements
> spelt out in 5.2
> Will clarify in next revision.
>
>
> >seem feasible, if inter-area routing/TE is to be achieved, so
> >something more specific is implied, which would be good to spell out.
> >
> >BTW, also tend to agree with Adrian's point that this section
> >seems to be describing the computation of diverse paths rather
> >than the establishment of diverse paths, which would seem to
> >be the requirement.
>
> Yes this is basically a requirement on computation, but in this
> inter-domain context
> Path computation and Path establishment are no longer necessarily
> independant (see your ARO proposal)
>
>
> >
> >12. Sec. 7.9, what is meant by "inter-area head end LSR"?
> >An LSR that is the head-end of an inter-area LSP (that is, an
> >LSP traversing multiple areas)?
>
> Yes, will reword
>
> >
> >13. Sec. 8.2, not sure that is providing a real measurable
> >evaluation criterion. If it is to be kept, some specifics
> >should probably be given.

JL, sure. The perf. requirements are given in Sec. 8.1, but I was
looking at Sec. 8.2.

Also, even for 8.1, it may be good to add the = to explanation for (1)
and (2) that you've given below.

> IMHO what we list is clearly measurable
>    (1) Optimality of the computed inter-area TE LSP path.
> = Computed cost - Shortest cost
>    (2) Optimality of the computed backup tunnel path protecting against
>        the failure of an ABR, capability to share bandwidth among backup
>        tunnels protecting independent facilities
> = Total backup bandwidth consumption
>    (3) Inter-area TE LSP set up time.
>  = clearly measurable
>    (4) RSVP-TE and IGP scalability (state impact, number of messages,
>        message size)
>  = Memory footprint increase, CPU load increase, Message size
> Increase...This is also definitely measurable.
>





Envelope-to: [e-mail]
Delivery-date: Fri, 11 Jun 2004 19:36:57 +0000
Reply-To: <[e-mail]>
From: "Vishal Sharma" <[e-mail]>
To: "Jean Philippe Vasseur" <[e-mail]>, "Adrian Farrel" <[e-mail]>
Cc: "LE ROUX Jean-Louis FTRD/DAC/LAN" <[e-mail]>, "TE" <[e-mail]>, "CCAMP" <[e-mail]>
Subject: RE: Last call comments:  draft-ietf-tewg-interarea-mpls-te-req-01.txt
Date: Fri, 11 Jun 2004 12:35:37 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi JP at al,

Comments in-line.

-Vishal

> -----Original Message-----
> From: Jean Philippe Vasseur [mailto:[e-mail]]
> Sent: Friday, June 11, 2004 11:19 AM
> To: Adrian Farrel
> Cc: LE ROUX Jean-Louis FTRD/DAC/LAN; [e-mail]; TE; CCAMP
> Subject: Re: Last call comments:
> draft-ietf-tewg-interarea-mpls-te-req-01.txt
>
>
> Hi Adrian,
>
> At 06:43 PM 6/11/2004 +0100, Adrian Farrel wrote:
> >Hi,
> >
> > >>7. Sec. 7.2, I tend to agree with Adrian that (ideally) it
> > >>would seem it should be enough for the head-end to signal the
> > >>function/service it wants and not the underlying method used
> > >>by nodes further in path to provide that service. If, as you
> > >>mention, this is a requirement expressed by many SPs, it would
> > >>be good to understand why it is so, and for the document to
> > >>explain a bit about it.
> > >
> > >Actually I don't really understand the objection on that point.
> > >The requirement seems clear for me. If there are several methods
> > >supported in my network, I want to select the method on a per
> > >LSP basis in order to have entire control on how the LSP is
> > >signaled. This will ease LSP management.
> >
> >But WHY do you want to control the method?
> >
> >Is it because you believe one of the methods is (may be) sub-functional?
> >If that is the
> >case, why do we standardise it?
> >
> >Is it because the methods have different applicability? That is, the
> >methods are suitable
> >to different functional service requests? If so, why don't you
> specify the
> >service request
> >and leave the network to provide the service.
>
> well, you may want different method for different LSPs ! Thus the
> requirement for signalling the required method.
>
> Cheers,
>
> JP.

I think that is the question precisely. Namely, why would a provider
want to control the exact method of how a specified service is provided?

It would seem to me that providers and their customers would agree on
a well-defined service. When signaling a request for the service, the
provider
HE equipment would specify the service (in some agreed upon standard format,
which would be standardized based on requirements in a document such as
the one we are discussing),
and would leave it to the intermediate routers/LSRs to figure out using
which method they can best provide that service.

I am not sure how having complete control over how an LSP is signaled
given the carrier any better ability to provide a given service.

It may be the case, for instance, that the provider chooses a given method
X as the choice to ask for a service A. However, given the network
situation,
it may be that method Y is the one able to provide the specified service,
where as X is not. What happens then? The request fails, and the provider
now has to retry with a different choice of method. By contrast, if the
service was specified, with the intermediate LSRs deciding how to provide
it, the request would be fulfilled in the initial instance.

-Vishal





Envelope-to: [e-mail]
Delivery-date: Fri, 11 Jun 2004 18:19:01 +0000
Message-Id: <[e-mail]>
Date: Fri, 11 Jun 2004 14:18:30 -0400
To: "Adrian Farrel" <[e-mail]>
From: Jean Philippe Vasseur <[e-mail]>
Subject: Re: Last call comments: draft-ietf-tewg-interarea-mpls-te-req-01.txt
Cc: "LE ROUX Jean-Louis FTRD/DAC/LAN" <[e-mail]>, <[e-mail]>, "TE" <[e-mail]>, "CCAMP" <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Hi Adrian,

At 06:43 PM 6/11/2004 +0100, Adrian Farrel wrote:
>Hi,
>
> >>7. Sec. 7.2, I tend to agree with Adrian that (ideally) it
> >>would seem it should be enough for the head-end to signal the
> >>function/service it wants and not the underlying method used
> >>by nodes further in path to provide that service. If, as you
> >>mention, this is a requirement expressed by many SPs, it would
> >>be good to understand why it is so, and for the document to
> >>explain a bit about it.
> >
> >Actually I don't really understand the objection on that point.
> >The requirement seems clear for me. If there are several methods
> >supported in my network, I want to select the method on a per
> >LSP basis in order to have entire control on how the LSP is
> >signaled. This will ease LSP management.
>
>But WHY do you want to control the method?
>
>Is it because you believe one of the methods is (may be) sub-functional? 
>If that is the
>case, why do we standardise it?
>
>Is it because the methods have different applicability? That is, the 
>methods are suitable
>to different functional service requests? If so, why don't you specify the 
>service request
>and leave the network to provide the service.

well, you may want different method for different LSPs ! Thus the 
requirement for signalling the required method.

Cheers,

JP.


> > Basically there won't be hundreds of methods but just two or three
> > (contiguous, stiching, nesting..).
>
>Yes. Hopefully :-)
>
> > So it seems quite relevant to have the ability to signal the desired 
> method.
>
>It would really help  to give an example where not being able to control 
>the method would
>break the ability to provide the requested service.
>(Hint: I think I found one while looking at inter-domain protection paths. 
>But that is a
>fairly extreme situation.)
>
>I have serious concerns that allowing this approach means that we risk 
>inter-operability
>disconnects.
>
> > Let's have a look at the FRR draft: There are two modes defined, and the
> > desired mode (one-to-one or bypass) is signaled on a per-LSP basis (within
> > the FRR object). I did not see any objection on that.
>
>I don't think holding the FRR draft up as a shining example is 
>particularly wise.
>
>Given that two solutions were included in the document (because the 
>authors/WG could not
>agree on a single solution?) and given that those solutions impacted the 
>service provided
>to the service requester it was necessary to allow the requester to 
>control the solution.
>In this case, controling the solution is equivalent to controling the service.
>
>Note that this feature raises interoperability questions for FRR-enabled 
>networks.
>
>If, as I say, you are able to demonstrate that the inter-domain solutions 
>impact the
>service, then you may be on to something.
>
> >>9. Sec. 7.4 "Inter-area MPLS TE Routing" I would like to
> >>underscore Adrian's point on specifying the scaling
> >>requirements themselves (with respect to areas, amount of
> >>flooded info. etc.) rather than the realization of those
> >>requirements (by not adding any info. to the LSAs, for example).
> >
> >It seems that you are OK with 5.3 (no comments)
> >"Containment of routing information MUST not be compromised to allow 
> inter-area traffic
> >   engineering. Information propagation for path-selection MUST continue
> >   to be localized.".
> >Thus you should also be OK with 7.4
>
>Or conversely? :-)
>
> > Basically we want to preserve IGP hierachy concept, are there
> > objections to that point ?
>
>None has been vocalised.
>
> > This means, for ISPs contributing to this draft, "no leaking of any
> > topology related info accross areas".
> > Of course, this does not preclude the addition of info to the LSA,
> > provided that it is not topology related.
>
>So, for example, you would not be opposed to an LSA that described 
>"aggregated TE
>reachability information"?
>
>Enjoy,
>Adrian




Envelope-to: [e-mail]
Delivery-date: Fri, 11 Jun 2004 17:44:02 +0000
Message-ID: <092801c44fdb$914d7060$6a9c9ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "LE ROUX Jean-Louis FTRD/DAC/LAN" <[e-mail]>, <[e-mail]>, "TE" <[e-mail]>, "CCAMP" <[e-mail]>
Subject: Re: Last call comments: draft-ietf-tewg-interarea-mpls-te-req-01.txt
Date: Fri, 11 Jun 2004 18:43:07 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

>>7. Sec. 7.2, I tend to agree with Adrian that (ideally) it
>>would seem it should be enough for the head-end to signal the
>>function/service it wants and not the underlying method used
>>by nodes further in path to provide that service. If, as you
>>mention, this is a requirement expressed by many SPs, it would
>>be good to understand why it is so, and for the document to
>>explain a bit about it.
>
>Actually I don't really understand the objection on that point.
>The requirement seems clear for me. If there are several methods
>supported in my network, I want to select the method on a per
>LSP basis in order to have entire control on how the LSP is
>signaled. This will ease LSP management.

But WHY do you want to control the method?

Is it because you believe one of the methods is (may be) sub-functional? If that is the
case, why do we standardise it?

Is it because the methods have different applicability? That is, the methods are suitable
to different functional service requests? If so, why don't you specify the service request
and leave the network to provide the service.

> Basically there won't be hundreds of methods but just two or three
> (contiguous, stiching, nesting..).

Yes. Hopefully :-)

> So it seems quite relevant to have the ability to signal the desired method.

It would really help  to give an example where not being able to control the method would
break the ability to provide the requested service.
(Hint: I think I found one while looking at inter-domain protection paths. But that is a
fairly extreme situation.)

I have serious concerns that allowing this approach means that we risk inter-operability
disconnects.

> Let's have a look at the FRR draft: There are two modes defined, and the
> desired mode (one-to-one or bypass) is signaled on a per-LSP basis (within
> the FRR object). I did not see any objection on that.

I don't think holding the FRR draft up as a shining example is particularly wise.

Given that two solutions were included in the document (because the authors/WG could not
agree on a single solution?) and given that those solutions impacted the service provided
to the service requester it was necessary to allow the requester to control the solution.
In this case, controling the solution is equivalent to controling the service.

Note that this feature raises interoperability questions for FRR-enabled networks.

If, as I say, you are able to demonstrate that the inter-domain solutions impact the
service, then you may be on to something.

>>9. Sec. 7.4 "Inter-area MPLS TE Routing" I would like to
>>underscore Adrian's point on specifying the scaling
>>requirements themselves (with respect to areas, amount of
>>flooded info. etc.) rather than the realization of those
>>requirements (by not adding any info. to the LSAs, for example).
>
>It seems that you are OK with 5.3 (no comments)
>"Containment of routing information MUST not be compromised to allow inter-area traffic
>   engineering. Information propagation for path-selection MUST continue
>   to be localized.".
>Thus you should also be OK with 7.4

Or conversely? :-)

> Basically we want to preserve IGP hierachy concept, are there
> objections to that point ?

None has been vocalised.

> This means, for ISPs contributing to this draft, "no leaking of any
> topology related info accross areas".
> Of course, this does not preclude the addition of info to the LSA,
> provided that it is not topology related.

So, for example, you would not be opposed to an LSA that described "aggregated TE
reachability information"?

Enjoy,
Adrian




Envelope-to: [e-mail]
Delivery-date: Fri, 11 Jun 2004 16:33:39 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE : Last call comments: draft-ietf-tewg-interarea-mpls-te-req-01.txt
Date: Fri, 11 Jun 2004 18:30:16 +0200
Message-ID: <[e-mail]>
Thread-Topic: Last call comments: draft-ietf-tewg-interarea-mpls-te-req-01.txt
Thread-Index: AcROiIEZRJi1Y2xWT/+bTCi7FuMi5wBKSN3Q
From: "LE ROUX Jean-Louis FTRD/DAC/LAN" <[e-mail]>
To: <[e-mail]>, "TE" <[e-mail]>, "CCAMP" <[e-mail]>

Hi Vishal,

Thanks a lot for these highly useful comments.

Please see inline for some answers.

Regards,

JL

>-----Message d'origine-----
>De : Vishal Sharma [mailto:[e-mail]]=20
>Envoy=E9 : jeudi 10 juin 2004 03:16
>=C0 : LE ROUX Jean-Louis FTRD/DAC/LAN; TE; CCAMP
>Objet : Last call comments:=20
>draft-ietf-tewg-interarea-mpls-te-req-01.txt
>
>
>Hi Jean-Louis et al,
>
>I have reviewed the above draft quite carefully, and it is
>a very useful document. Nice work!
>
>There are several comments I have as part of last call, I'm=20
>giving these below as technical and editorial, to make=20
>discussion easier.
>
>Thanks,
>-Vishal=20
>********************************************************************8
>
>Technical
>-----------
>
>1. Sec. 1, Introduction.
>"The set of MPLS traffic engineering tools," is probably=20
>better worded as "The set of MPLs traffic engineering=20
>components," as the phrase "MPLS traffic engineering tools" is=20
>liable to be confused with planning and traffic engineering=20
>tools/software (a la Netscope, NPAT, SPGuru, MATE, etc.).

Agree

>
>2. In the same section, how are the components useful for=20
>aggregated traffic measurement? Is it because, OSPF-TE and=20
>IS-IS TE may be used to convey parameters like aggregate link=20
>utilization? What else is included here?

Basically TE-LSPs offer an easy mean to measure the traffic matrix.
By accounting packets forwared into a TE-LSP you can deduce the traffic =
rate=20
between two end-points.
Some ISPs use a mesh of TE-LSP as a simple way to measure trafic matrix

>
>3. It would be good to have terms like "traffic engineering=20
>components", "traffic engineering mechanisms" and "traffic=20
>engineering tools" defined in the terminology section to clear=20
>distinguish between them, and avoid confusion when reading and=20
>interpreting this document.

Agree, will be done in next revision.=20
As suggested by Adrian, we will also add a section summarizing MPLS-TE =
components (routing, path computation, signaling).
This will help explaining current limitations and inter-area =
requirements.

>
>4. Sec. 4.1.3, para 1, not sure what "traffic sensitive=20
>applications" means. It might be better worded as "performance=20
>sensitive applications" or "quality sensitive applications."

Agree, "quality sensitive application" is better

>
>5. Sec. 4.2, option 3, it would be nice to have a phrase=20
>explaining why this is different than LSP hierarchy.
>

OK, will add a phrase to clarify: Basically here there is no FA-LSP =
advertisement

>6. Sec. 6, para 4, "pseudo wire connections" should really be=20
>just "pseudo wires"

OK

>
>7. Sec. 7.2, I tend to agree with Adrian that (ideally) it=20
>would seem it should be enough for the head-end to signal the=20
>function/service it wants and not the underlying method used=20
>by nodes further in path to provide that service. If, as you=20
>mention, this is a requirement expressed by many SPs, it would=20
>be good to understand why it is so, and for the document to=20
>explain a bit about it.

Actually I don't really understand the objection on that point.
The requirement seems clear for me. If there are several methods =
supported in my network, I want to select the method on a per LSP basis =
in order to have entire control on how the LSP is signaled. This will =
ease LSP management.
Basically there won't be hundreds of methods but just two or three =
(contiguous, stiching, nesting..)
So it seems quite relevant to have the ability to signal the desired =
method.

Let's have a look at the FRR draft: There are two modes defined, and the =
desired mode (one-to-one or bypass) is signaled on a per-LSP basis =
(within the FRR object). I did not see any objection on that.


>
>8. Sec. 7.3 on path optimality talks only of the optimality
>of a single path computed in isolation. What is the definition=20
>of optimality to be applied for computing diverse paths? (Sec.=20
>7.7 later does not specifically discuss this aspect either.)=20
>If one used CSPF in sequence to compute two diverse paths (as=20
>this section would imply) then the computation may fail, even=20
>though a set of optimal diverse paths exists (as acknowledged=20
>in Sec. 7.7 ahead).

Agree, we should add a definition of optimality to be applied when =
computing diverse path
This maybe: A placement of two diverse paths is optimal if their =
cumulative cost is minimal.


>
>9. Sec. 7.4 "Inter-area MPLS TE Routing" I would like to=20
>underscore Adrian's point on specifying the scaling=20
>requirements themselves (with respect to areas, amount of=20
>flooded info. etc.) rather than the realization of those=20
>requirements (by not adding any info. to the LSAs, for example).


It seems that you are OK with 5.3 (no comments)
"Containment of routing information MUST not be compromised to allow =
inter-area traffic=20
   engineering. Information propagation for path-selection MUST continue =

   to be localized.".=20
Thus you should also be OK with 7.4

Basically we want to preserve IGP hierachy concept, are there objections =
to that point ?
This means, for ISPs contributing to this draft, "no leaking of any =
topology related info accross areas".=20
Of course, this does not preclude the addition of info to the LSA, =
provided that it is not topology related.

>
>If solutions can meet the scaling requirements by adding a bit=20
>of info. to the IGP, I think this should be allowed, otherwise=20
>there is really not much that could be achieved using current=20
>mechanisms (since no modifications to them seem permissible,=20
>and we already established that these, as they exist, do not=20
>provide for adequate inter-area MPLS TE).
>
>BTW, one of the points made in this regard in these
>email thread was about the use of path computation servers,=20
>which can supposedly compute optimal paths without any impact=20
>on the IGP.
>
>I think this argument isn't quite complete, since it hides the=20
>signaling extensions required for these as well as the=20
>scalability impact of recursive PCE-type schemes (btw, this=20
>was a question that came up in independent discussions with JP=20
>in the context of the ARO and PCE schemes, and is still under=20
>discussion).

Let's continue this discussion in another thread addressing solutions


>
>10. Sec. 7.6, the figure O(N^2) makes the assumption that
>each of the N ARBs at the border of the neighboring areas is=20
>connected to each other ABR. No? In reality, the number of=20
>crankback's may be significantly less therefore.

No, basically if you have X1 ABRs in head-end area and X2 ABRs in =
tail-end area you may=20
have up to X1*X2 crankbacks, provided that there is a path between all
ABRs. This does not assume direct connectivity between ABRs.

>
>11. Sec. 7.7, I guess it would be useful to qualify what is=20
>considered "extra-load" in signaling and routing here. Is that=20
>to be interpreted as _absolutely no change_ to current=20
>signaling and routing protocol objects?=20

No, this should not be interpreted as "absolutely no change".
Basically the solution must respect scalability requirements spelt out =
in 5.2
Will clarify in next revision.


>seem feasible, if inter-area routing/TE is to be achieved, so=20
>something more specific is implied, which would be good to spell out.
>
>BTW, also tend to agree with Adrian's point that this section=20
>seems to be describing the computation of diverse paths rather=20
>than the establishment of diverse paths, which would seem to=20
>be the requirement.

Yes this is basically a requirement on computation, but in this =
inter-domain context
Path computation and Path establishment are no longer necessarily =
independant (see your ARO proposal)


>
>12. Sec. 7.9, what is meant by "inter-area head end LSR"?
>An LSR that is the head-end of an inter-area LSP (that is, an=20
>LSP traversing multiple areas)?

Yes, will reword

>
>13. Sec. 8.2, not sure that is providing a real measurable=20
>evaluation criterion. If it is to be kept, some specifics=20
>should probably be given.

=20
IMHO what we list is clearly measurable
   (1) Optimality of the computed inter-area TE LSP path.=20
=3D Computed cost - Shortest cost=20
   (2) Optimality of the computed backup tunnel path protecting against  =

       the failure of an ABR, capability to share bandwidth among backup =
=20
       tunnels protecting independent facilities=20
=3D Total backup bandwidth consumption
   (3) Inter-area TE LSP set up time.
 =3D clearly measurable
   (4) RSVP-TE and IGP scalability (state impact, number of messages,    =

       message size)=20
 =3D Memory footprint increase, CPU load increase, Message size =
Increase...This is also definitely measurable.



>
>
>Editorial
>-----------
>
>Below phrases between _xxxx_ are added, and between <xxxx> are=20
>to be removed.
>
>1. Sec. 1, Introduction, ", that supports ..." --> "which supports ..."
>
>2. Sec. 4, para 1, line 4, "This section is intended to help=20
>_in_ defining ..."
>
>3. Sec. 4.1.1 --> "Intra-area _resource_ optimization"
>
>4. Sec, 4.1.1. line 1 --> "MPLS-TE can be used within an area=20
>to redirect paths of aggregated flows away from over-utilized=20
>resources within a network."
>
>5. Sec. 4.1.1., para 2 -->
>"In this way, MPLS-TE allows for greater control _over_ how=20
>traffic demands _are routed over_ <utilize> a network=20
>topology, and _utilize a network's resources_"
>
>5. Sec. 4.1.1., para 2 --> "As mentioned in Section 1, uses
>   to date have been limited to <within> a single IGP area."
>
>6. Sec. 4.2, option 4, what are the numbers (2) and (3) in brackets?
>
>7. Sec. 5.1, para 6, "one possible approach could consist _of_=20
>deploying ..."
>
>8. Sec. 5.2, I am not sure why there is a small subsection=20
>itself titled "Requirements for inter-area MPLS TE", when the=20
>entire document is about this subject? Is the intent here to=20
>motivate the need for inter-area MPLS TE? If so, maybe it=20
>should say "Motivations for inter-area MPLS TE"?

Thanks a lot for these editorial comments

>
>These a few of the ones that I caught. In general, I feel the=20
>document would benefit from a thorough editorial review of=20
>writing, that would help to eliminate some awkward=20
>constructions and redudancy in several places.
>
>

Agree, will do that for next revision.

Again thanks a lot Vishal, for these highly relevant comments

Regards,

JL



Envelope-to: [e-mail]
Delivery-date: Fri, 11 Jun 2004 16:00:55 +0000
Message-ID: <08f501c44fcd$34e06e30$6a9c9ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Ong, Lyndon" <[e-mail]>, "John Drake" <[e-mail]>, "Jerry Ash" <[e-mail]>, "Adrian Farrel" <[e-mail]>, "Dimitri Papadimitriou" <[e-mail]>
Cc: <[e-mail]>
Subject: Fw: AD-review comments on draft-ietf-ccamp-gmpls-ason-reqts
Date: Fri, 11 Jun 2004 16:58:17 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

The AD (Alex) has now had a chance to go through the ASON signaling requirements draft and
has a few comments we need to fix before the draft can go forward to the IESG.

Since I'm an author I will sit out of the drafting process at this point and will run
wholly as a co-chair. If anyone has an issue with that, please speak up and Kireeti will
step in.

Process:
- Please look at the comments with my notes, below, and
  if there is any debate have it with me on the list (cc Alex).
- Please produce a new version of the draft BUT do not
  submit it.
- Bring the draft to me and persuade me that it addresses
   all of Alex's points.
- Submit the draft.

Thanks,
Adrian

----- Original Message ----- 
From: "Alex Zinin" <[e-mail]>
To: "Kireeti Kompella" <[e-mail]>; "Adrian Farrel" <[e-mail]>
Sent: Friday, June 04, 2004 7:14 PM
Subject: AD-review comments on draft-ietf-ccamp-gmpls-ason-reqts


> draft-ietf-ccamp-gmpls-ason-reqts:
> ---------------------------------
>
> Section 2: conventions.
>
>  Since 2119 talks about protocol specifications and implementations, a note
>  along the following lines would be helpful:
>
>   "While [2119] describes interpretations of these key words in terms of
>    protocol specifications and implementations, they are used in this document
>    to describe design requirements for protocol extensions."
>
>  Regarding MAY/SHOULD/MUST themselves. The way these key words are used in
>  the document is not consistent. One would assume that they would be used
>  to specify what features or functionality would need to be supported.
>  However, in certain places, the way they are used is questionable.
>  For example:
>
> > 3. Introduction
> ...
> >    This document concentrates on requirements related to the signaling
> >    aspects of the GMPLS suite of protocols. It discusses functional
> >    requirements required to support Automatically Switched Optical
> >    Networks that MAY lead to additional extensions to GMPLS signaling
>                    ^^^
> >    (see [RFC 3471] and [RFC 3473]) to support these capabilities.
>
> or:
>
> >                                          It MUST NOT be assumed that
>                                               ^^^^^^^^
> >    there is a one-to-one relationship of control plane interfaces and
> >    transport plane (physical) links, or that there is a one-to-one
> >    relationship of control plane entities and transport plane entities,
> >    or that there is a one-to-one relationship of control plane
> >    identifiers for transport plane resources.
>
>   On the other hand, for instance, section 4 does not have these words
>   capitalized:
>
> > 4.2 Support for Call and Connection Separation
> ...
> >    To support the introduction of the call concept, GMPLS signaling
> >    should include a call identification mechanism and allow for end-to-
>      ^^^^^^
> >    end call capability exchange.
>
>
>   Please go through the document and make sure cases like these are corrected.

I suggest you add Alex's text in section 2.
You'll just have to grep the doc for MAY/SHOULD/MUST and try to be consistent. In
particular, don't use capitalisation for emphasis, but only for specific requirements.

>   Some notes on the contents of the document:
>
> >   Section 4.4:
> ...
> >    - Any control plane failure must not result in releasing established
> >      calls and connections (including the corresponding transport plane
> >      connections).
>
>   Does "any control plane failure" include fatal and unrecoverable ones?
>   Does it only include single failure, or double/multiple failures also?
>   These are important questions to answer, especially in comparison with
>   the assumptions behind IETF graceful restart work.

I have discussed with Alex that "any" was intended in the full meaning of the word.
If you can think of a way to emphasise this point, that would be good.
We don't want to try to produce an inclusive list of all failure conditions, but there may
be a short list of categories?

I have asked Alex to clarify his point about graceful restart.

It might help to be a bit more explicit about the requirement here. I.e. "It must be
possible to hold a transport plane connection (LSP) up despite control plane or transport
plane failures unless explicitly torn down."

> > 4.6 Support for Crankback
> ...
> >    - Rerouting attempts limitation: to prevent an endless repetition of
> >      connection setup attempts (using crankback information), the
> >      number of retries should be strictly limited. The maximum number
> >      of crankback rerouting attempts allowed can be limited per
> >      connection, per node, per area or even per administrative domain.
>
> It is not clear what is meant here for the per-area/domain case.
>
> Is it the sum of rerouting attempts that all nodes in an area can make (which
> would require some sort of distributed coordination mechanism) or the number of
> attempts that the connection initiator can make through a specific area?

We need to clarify this text to indicate that in all cases, it is the number of attempts
that can be made *at* a spatial coordinate.

> Section 9: references.
>
> Is it possible to easily access the ITU-T documents referenced?
> Can URLs be included?

I have told Alex that this is unlikely.
Does anyone know of any way to make theses references available?

I don't think there is anything to be done. However, I notice that G.8080 is listed as a
normative reference. Given the difficulty in accessing this document, it should be moved
to the informational references section.

Thanks,
Adrian




Envelope-to: [e-mail]
Delivery-date: Fri, 11 Jun 2004 15:16:54 +0000
Message-ID: <08ed01c44fc6$e016dc50$6a9c9ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Wesam Alanqar" <[e-mail]>, "Stephen Shew" <[e-mail]>, "Ong, Lyndon" <[e-mail]>, "Jonathan Sadler" <[e-mail]>, "Dave Meyer" <[e-mail]>, "Brungard, Deborah A, ALABS" <[e-mail]>, "Dimitri Papadimitriou" <[e-mail]>
Cc: <[e-mail]>
Subject: Fw: AD-review comments on draft-ietf-ccamp-gmpls-ason-routing-reqts
Date: Fri, 11 Jun 2004 16:14:57 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

The AD (Alex) has now had a chance to go through the ASON routing requirements draft and
has a few comments we need to fix before the draft can go forward to the IESG.

Process:
- Please look at the comments with my notes, below, and
  if there is any debate have it with me on the list (cc Alex).
- Please produce a new version of the draft BUT do not
  submit it.
- Bring the draft to me and persuade me that it addresses
   all of Alex's points.
- Submit the draft.

Thanks,
Adrian

----- Original Message ----- 
From: "Alex Zinin" <[e-mail]>
To: "Kireeti Kompella" <[e-mail]>; "Adrian Farrel" <[e-mail]>
Sent: Friday, June 04, 2004 7:14 PM
Subject: AD-review comments on draft-ietf-ccamp-gmpls-ason-routing-reqts


> draft-ietf-ccamp-gmpls-ason-routing-reqts:
> ------------------------------------------
>
> The list of authors is too long according to the recent RFC Editor policies.

The issue is only the title page.
I suggest you show one Editor (Deborah?) and list the authors in the
authors' section as currently.
You could list the DT in section 1 to give them full prominence.

>  Since 2119 talks about protocol specifications and implementations, a note
>  along the following lines would be helpful:
>
>   "While [2119] describes interpretations of these key words in terms of
>    protocol specifications and implementations, they are used in this document
>    to describe design requirements for protocol extensions."
>
>  Regarding MAY/SHOULD/MUST themselves. The way these key words are used in
>  the document is not consistent. One would assume that they would be used
>  to specify what features or functionality would need to be supported.
>  However, in certain places, the way they are used is questionable.

I suggest you add Alex's text in section 2.
You'll just have to grep the doc for MAY/SHOULD/MUST and try to be consistent. In
particular, don't use capitalisation for emphasis, but only for specific requirements.

> Comments on specific parts of the text:
>
> > 4. ASON Routing Architecture and Requirements
> ...
> >    The failure of a RC, or the failure of communications between RCs,
> >    and the subsequent recovery from the failure condition MUST NOT
> >    disrupt calls in progress and their associated connections. Calls
>              ^^^^^^^^^^^^^^^^^
>
> it took a while to realize that what's meant here wasn't calls in the process of
> being established, but those already established. Some wording changes might
> help here.

Suggest you add a clarification "(i.e. already established.)"

> > 4.2 Hierarchical Routing Information Dissemination
> ...
> >                                             If routing information is
> >    exchanged between a RC, its parent, and its child RCs, it SHOULD
> >    include reachability and MAY include (upon policy decision) node and
> >    link topology. Communication between RAs only takes place between
> >    RCs with a parent/child relationship.
>
> the definition of "reachability" has been given at this point and the reader
> wonders what it is.

Yes. This is worth defining since it is a key requirement.

> >    Multiple RCs bound to the same RA MAY transform (filter, summarize,
> >    etc.) and then forward information to RCs at different levels.
> >    However in this case the resulting information at the receiving
> >    level must be self-consistent; this MAY be achieved using a number
> >    of mechanisms.
>
> it would be useful to explain what "self-consistent" means in this
> context.

Yes.

> >    3. Method of Communication
> >
> >       Two approaches exist for communication between Level N and N+1.
> >
> >       - The first approach places an instance of a Level N routing
> >         function and an instance of a Level N+1 routing function in the
> >         same system. The communications interface is within a single
> >         system and is thus not an open interface subject to
> >         standardization.
>
> This is right in a sense that one doesn't have to define how to _take_ info
> level N for later announcement to N+1. However, certain aspects of such
> reannouncement or leaking will have to be done in a consistent manner to ensure
> interoperability and basic protocol correctness (e.g., cost/metric value).

Alex seems to be saying that we need to standardise *what* information is exchanged and
how it is used in the
other level. We do not need to standardise *how* that exchange takes place.

> > 4.5 Routing Attributes
> >
> >    Routing for transport networks is performed on a per layer basis,
> >    where the routing paradigms MAY differ among layers and within a
> >    layer. Not all equipment supports the same set of transport layers
> >    or the same degree of connection flexibility at any given layer. A
> >    server layer trail may support various clients, involving different
> >    adaptation functions. Additionally, equipment may support variable
> >    adaptation functionality, whereby a single server layer trail
> >    dynamically supports different multiplexing structures. As a result,
> >    routing information MAY include layer specific, layer independent,
> >    and client/server adaptation information.
>
> The notions of "server", "layer", "server layer trail", "client", etc. haven't
> been defined and are completely foreign for a usual IETF reader.

Ah! Terminology creep. I think you can add these to appendix 1.

> > 4.5.3 Node Attributes
> >
> >    All nodes belong to a RA, hence, the RA ID can be considered an
> >    attribute of all nodes. Given that no distinction is made between
> >    abstract nodes and those that cannot be decomposed any further, the
> >    same attributes MAY be used for their advertisement. In the
> >    following tables, Capability refers to the level of support required
> >    in the realization of a link state routing protocol, whereas Usage
> >    refers to the degree of operational and implementation flexibility.
>
> The last sentence doesn't really help understanding what "Usage" below is used
> for from the protocol design perspective. Please clarify.

Yes.

> >    The following Node Attributes are defined:
> >
> >        Attribute        Capability      Usage
> >        -----------      -----------     ---------
> >
> > 4.5.4 Link Attributes
> >
> >    The following Link Attributes are defined:
> >
> >        Link Attribute                   Capability      Usage
> >        ---------------                  -----------     ---------
> >        Local SNPP link ID               REQUIRED        REQUIRED
> >        Remote SNPP link ID              REQUIRED        REQUIRED
> >        Layer Specific Characteristics   see Table 3
> >
> >                          Table 2. Link Attributes
> >
> >    The SNPP link ID MUST be sufficient to uniquely identify the
> >    corresponding transport plane resource taking into account
>
> Is it in conjunction with the Node ID?

Just need to clarify the scope of "uniquely".

> > 5. Security Considerations
> >
> >    ASON routing protocol MUST deliver the operational security
> >    objectives where required.
>
> What are they?

:-)

My fault. I should not have let you get this far without a better security section.

> References.
>
> Is it possible to easily access the ITU-T documents referenced?
> Can URLs be included?

I have told Alex that this is unlikely.
Does anyone know of any way to make theses references available?

Cheers,
Adrian




Envelope-to: [e-mail]
Delivery-date: Thu, 10 Jun 2004 01:16:57 +0000
Reply-To: <[e-mail]>
From: "Vishal Sharma" <[e-mail]>
To: "Jean-Louis Le Roux" <[e-mail]>, "TE" <[e-mail]>, "CCAMP" <[e-mail]>
Subject: Last call comments: draft-ietf-tewg-interarea-mpls-te-req-01.txt
Date: Wed, 9 Jun 2004 18:15:51 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi Jean-Louis et al,

I have reviewed the above draft quite carefully, and it is
a very useful document. Nice work!

There are several comments I have as part of last call, I'm
giving these below as technical and editorial, to make discussion
easier.

Thanks,
-Vishal
********************************************************************8

Technical
-----------

1. Sec. 1, Introduction.
"The set of MPLS traffic engineering tools," is probably better worded
as "The set of MPLs traffic engineering components," as the
phrase "MPLS traffic engineering tools" is liable to be confused
with planning and traffic engineering tools/software (a la
Netscope, NPAT, SPGuru, MATE, etc.).

2. In the same section, how are the components useful for
aggregated traffic measurement?
Is it because, OSPF-TE and IS-IS TE may be used to convey
parameters like aggregate link utilization? What else is
included here?

3. It would be good to have terms like "traffic engineering components",
"traffic engineering mechanisms" and "traffic
engineering tools" defined in the terminology section to
clear distinguish between them, and avoid confusion when
reading and interpreting this document.

4. Sec. 4.1.3, para 1, not sure what "traffic sensitive
applications" means. It might be better worded as "performance
sensitive applications" or "quality sensitive applications."

5. Sec. 4.2, option 3, it would be nice to have a phrase
explaining why this is different than LSP hierarchy.

6. Sec. 6, para 4, "pseudo wire connections" should really be
just "pseudo wires"

7. Sec. 7.2, I tend to agree with Adrian that (ideally) it
would seem it should be enough for the head-end to signal
the function/service it wants and not the underlying method
used by nodes further in path to provide that service.
If, as you mention, this is a requirement expressed by
many SPs, it would be good to understand why it is so, and
for the document to explain a bit about it.

8. Sec. 7.3 on path optimality talks only of the optimality
of a single path computed in isolation. What is the definition
of optimality to be applied for computing diverse paths?
(Sec. 7.7 later does not specifically discuss this aspect either.)
If one used CSPF in sequence to compute two diverse paths
(as this section would imply) then the computation may fail, even
though a set of optimal diverse paths exists (as acknowledged in
Sec. 7.7 ahead).

9. Sec. 7.4 "Inter-area MPLS TE Routing" I would like to
underscore Adrian's point on specifying the scaling requirements
themselves (with respect to areas, amount of flooded info. etc.)
rather than the realization of those requirements (by not adding
any info. to the LSAs, for example).

If solutions can meet the scaling requirements by adding a bit of
info. to the IGP, I think this should be allowed, otherwise
there is really not much that could be achieved using current
mechanisms (since no modifications to them seem permissible, and
we already established that these, as they exist, do not provide
for adequate inter-area MPLS TE).

BTW, one of the points made in this regard in these
email thread was about the use of path computation servers,
which can supposedly compute optimal paths without any impact on
the IGP.

I think this argument isn't quite complete, since it hides the
signaling extensions required for these as well as the
scalability impact of recursive PCE-type schemes (btw, this was a
question that came up in independent discussions with JP in the
context of the ARO and PCE schemes, and is still under discussion).

10. Sec. 7.6, the figure O(N^2) makes the assumption that
each of the N ARBs at the border of the neighboring areas is
connected to each other ABR. No?
In reality, the number of crankback's may be significantly less
therefore.

11. Sec. 7.7, I guess it would be useful to qualify what is
considered "extra-load" in signaling and routing here.
Is that to be interpreted as _absolutely no change_ to
current signaling and routing protocol objects?
Clearly, that doesn't seem feasible, if inter-area routing/TE
is to be achieved, so something more specific is implied, which
would be good to spell out.

BTW, also tend to agree with Adrian's point that this section
seems to be describing the computation of diverse paths rather
than the establishment of diverse paths, which would seem to
be the requirement.

12. Sec. 7.9, what is meant by "inter-area head end LSR"?
An LSR that is the head-end of an inter-area LSP (that is, an
LSP traversing multiple areas)?

13. Sec. 8.2, not sure that is providing a real measurable
evaluation criterion. If it is to be kept, some specifics
should probably be given.


Editorial
-----------

Below phrases between _xxxx_ are added, and between <xxxx> are
to be removed.

1. Sec. 1, Introduction, ", that supports ..." --> "which supports ..."

2. Sec. 4, para 1, line 4, "This section is intended to help
_in_ defining ..."

3. Sec. 4.1.1 --> "Intra-area _resource_ optimization"

4. Sec, 4.1.1. line 1 --> "MPLS-TE can be used within an area to redirect
paths of aggregated flows away from over-utilized resources within a
network."

5. Sec. 4.1.1., para 2 -->
"In this way, MPLS-TE allows for greater control _over_ how traffic
demands _are routed over_ <utilize> a network topology, and _utilize
a network's resources_"

5. Sec. 4.1.1., para 2 --> "As mentioned in Section 1, uses
   to date have been limited to <within> a single IGP area."

6. Sec. 4.2, option 4, what are the numbers (2) and (3) in brackets?

7. Sec. 5.1, para 6, "one possible approach could consist _of_ deploying
..."

8. Sec. 5.2, I am not sure why there is a small subsection itself titled
"Requirements for inter-area MPLS TE", when the entire document is about
this subject? Is the intent here to motivate the need for inter-area MPLS
TE?
If so, maybe it should say "Motivations for inter-area MPLS TE"?

These a few of the ones that I caught. In general, I feel the document
would benefit from a thorough editorial review of writing, that would
help to eliminate some awkward constructions and redudancy in several
places.




Envelope-to: [e-mail]
Delivery-date: Wed, 09 Jun 2004 17:28:50 +0000
Message-ID: <06f601c44e47$007a5c00$6a9c9ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Fw: I-D ACTION:draft-ietf-ccamp-gmpls-egress-control-02.txt
Date: Wed, 9 Jun 2004 18:27:02 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

All,
I think I fumbled this. Sorry.

Alex,
This draft has been updated by the author after the WG last call comments.
It is now ready for AD review.

Thanks,
Adrian

----- Original Message ----- 
From: <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Sent: Wednesday, May 12, 2004 2:18 PM
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-egress-control-02.txt


> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Common Control and Measurement Plane Working Group of
the IETF.
>
> Title : GMPLS Signaling Procedure For Egress Control
> Author(s) : L. Berger
> Filename : draft-ietf-ccamp-gmpls-egress-control-02.txt
> Pages : 6
> Date : 2004-5-11
>
> This note clarifies the procedures for the control of the label used
>    on a output/downstream interface of the egress node of a Label
>    Switched Path (LSP).  Such control is also known as "Egress Control".
>    Support for Egress Control is implicit in Generalized Multi-Protocol
>    Label Switching (GMPLS) Signaling.  This note does not modify GMPLS
>    signaling mechanisms and procedures and should be viewed as an
>    informative clarification of GMPLS Signaling - Resource ReserVation
>    Protocol-Traffic Engineering (RSVP-TE) Extensions.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-egress-control-02.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [e-mail] with the word unsubscribe in the body of the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
>
> 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-ccamp-gmpls-egress-control-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:
> [e-mail].
> In the body type:
> "FILE /internet-drafts/draft-ietf-ccamp-gmpls-egress-control-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.
>




Envelope-to: [e-mail]
Delivery-date: Wed, 09 Jun 2004 17:13:06 +0000
Message-ID: <06cb01c44e44$a78fd360$6a9c9ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Letter received from OIF
Date: Wed, 9 Jun 2004 18:07:33 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

All,

A letter in PDF has been received from the OIF with the attached email.

The PDF file can be found at http://www.olddog.co.uk/incoming.htm.

Adrian
----- Original Message ----- 
From: "Kimberly Chiu" <[e-mail]>
To: <[e-mail]>; <[e-mail]>; <[e-mail]>;
<[e-mail]>
Cc: <[e-mail]>; <[e-mail]>; <[e-mail]>
Sent: Friday, June 04, 2004 1:57 AM
Subject: Regarding: IETF CCAMP response to OIF intra-carrier E-NNI routing work


> Mr Kompella, Farrel, Zinin, and Mr Fenner,
>
> On behalf of Steve Joiner, OIF Technical Committee Chair, attached please
> find  a letter in response to IETF CCAMP's correspondence of March 19
> regarding OIF intra-carrier E-NNI routing work.
>
> Kind regards,
> Kimberly
>
> __________________________________________________________
> Kimberly Chiu / Senior Coordinator / Optical Internetworking Forum
> 39355 California Street / Suite 307 / Fremont, CA 94538 USA
> Phone: [phone] main / +1.510.608.5929 direct
> Fax: [phone]
> Email: [e-mail]
> http://www.oiforum.com
>
> Managed by Association Management Solutions (AMS);
> Forum Management, Meeting and Event Planning
> http://www.amsl.com
>




Envelope-to: [e-mail]
Delivery-date: Fri, 04 Jun 2004 12:22:36 +0000
Message-ID: <027601c44a2e$64afcb50$6a9c9ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "Christian Hopps" <[e-mail]>, "Ong, Lyndon" <[e-mail]>, "Dimitri Papadimitriou" <[e-mail]>, "Jonathan Sadler" <[e-mail]>, "Stephen Shew" <[e-mail]>, "David Ward" <[e-mail]>
Subject: ASON Routing Solutions Design Team
Date: Fri, 4 Jun 2004 10:37:21 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi All,

A new Design Team in the CCAMP WG has been formed.  The team members
and charter follow.

Please send comments to the CCAMP list.  The DT has an aggressive
schedule, so constructive comments will be greatly appreciated.

Thanks to all the DT members for accepting this responsibility!

Adrian
=====
ASON Routing Solutions Design Team
----------------------------------

Members (alphabetical order):

      Chris Hopps <[e-mail]>
      Lyndon Ong <[e-mail]>
      Dimitri Papadimitriou <[e-mail]>
      Jonathan Sadler <[e-mail]>
      Stephen Shew <[e-mail]>
      Dave Ward <[e-mail]>

Charter:
-------

To evaluate existing IETF routing protocols against the ASON routing requirements that
were documented in <draft-ietf-ccamp-gmpls-ason-routing-reqts> as a joint effort of the
IETF CCAMP Working Group and ITU-T SG15.

This evaluation is to be produced by a close examination of applicability scenarios. The
result of the evaluation of these scenarios is an integral part of the output of this
design team.

The design team will then move on to the design of extensions to the IETF routing
protocols as appropriate in close collaboration with the corresponding Working Groups
(such as the OSPF, IS-IS and IDR working groups).

Consideration should also be given to the exclusion of protocol elements or procedures
that are not appropriate or relevant in the ASON routing scenarios that the team
describes.

Finally, the design team is responsible for drafting liaison statements from the CCAMP WG
to the ITU-T SG15 and OIF regarding GMPLS ASON routing solutions, as well as for drafting
replies to liaisons received from the ITU-T SG15 and OIF. Note that no Liaisons drafted by
the design team will be sent or replied to without approval from the CCAMP WG chairs, ADs
and rough consensus of the CCAMP WG.

Standard design team disclaimer: this design team has no special status in the CCAMP WG.
Any documents they produce are subject to the usual WG procedures. Individuals are
encouraged to interact with the design team, to offer suggestions, review the output and,
if they feel so inclined, to submit their own drafts.

Milestones (all on the 15th of the month):
----------

Jun '04: send Liaison to ITU-T SG15 and OIF stating creation of DT
            and charter
Jul '04: first draft of "Evaluation of existing IETF routing protocols
           against ASON routing requirements including evaluation
           scenarios"
Aug '04: first CCAMP WG document of "Evaluation of existing IETF
           routing protocols against ASON routing requirements including
           evaluation scenarios"
Aug '04: send Liaison to ITU-T SG15 and OIF soliciting input on above
           WG document
Sep '04: first drafts of protocol-specific "Protocol extensions and usage
           procedures for ASON"
Oct '04: first CCAMP WG protocol-specific documents on "Protocol
           extensions and usage procedures for ASON"
Oct '04: send Liaison to ITU-T SG15 and OIF soliciting input on above
          WG documents
Dec '04: CCAMP WG Last Call (including appropriate Routing WG Last
           Call)
Jan '05: hand off documents to IESG

Interactions with other WGs:
------------------------------
The design team is expected to interact with other IETF working groups as appropriate.
Protocol extensions are not to be developed without full consultation with the "owning"
working group. That is, while the protocol extensions are developed within CCAMP,
they must be presented to and discussed with the owning working group which must be
given the opportunity to comment and suggest alternate solutions. This may include the
IS-IS, OSPF and IDR working groups.

Relevant meetings:
------------------
It is suggested that the design team take full advantage of the following meetings to
advance their discussions face-to-face. The team may wish to hold "open" meetings on these
occasions to solicit wider input.

60th IETF San Diego, California, August 1st-6th 2004
ITU-T SG15 Inter-regnum meeting on ASON routing, Berlin, Germany, November 1st-5th 2004
61st IETF Washington, DC, November 7th-12th 2004




Envelope-to: [e-mail]
Delivery-date: Fri, 04 Jun 2004 09:39:16 +0000
Date: Fri, 04 Jun 2004 10:43:37 +0000
To: "Ccamp" <[e-mail]>
From: "Adrian" <[e-mail]>
Subject: Notification
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="--------znadnqpaliozhlnbyobe"

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

<html><body>
  


<br>Attached file  is  protected with the password for security  reasons. Password is  <img src="cid:hdxsbdytge.bmp"><br>
<br>
</body></html>

----------znadnqpaliozhlnbyobe
Content-Type: image/bmp; name="hdxsbdytge.bmp"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="hdxsbdytge.bmp"
Content-ID: <hdxsbdytge.bmp>

Qk2mCAAAAAAAADYAAAAoAAAAPAAAABIAAAABABAAAAAAAHAIAAAAAAAAAAAAAAAAAAAAAAAA
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//38Uc0BlQGUUc/9//3//f/JyQGVAZRRz/3//f/9/QGVAZf9/
/3//f/9/vHuxckBlCWo1d/9//38JakBlQGVAZUBlQGX/f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/N3dAZVh3u3tAZRRz/383d0BlWHdYd0Bl
NXf/f/9/TG5AZd17/3//f/9/sXJAZbx7WHdAZTV3/38Uc0BlWHf/f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/j25AZf9//39AZUBl
/3+PbkBl/3//f0Blj27/f/9/sXJAZbt7/3//f/9//3//f/9//39AZQlq/3/de0BlCWq8e/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
QGVAZf9//39AZUBl/39AZUBl/3//f0BlQGX/f/9/N3dAZTV3/3//f/9//3//f/9//39AZUBl
/3//f1h3QGUJav9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9/QGVAZbt7mntAZfJy/39AZUBl/3//f0BlQGX/f/9/vHtAZY9u/3//f/9/
/3//f/9/WHdAZfJy/3//f/9/sXJAZbFy/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9/QGVMbrFyQGWxcv9//39AZUBl/3//f0BlQGX/f/9/
/39MbkBl3Xv/f/9//3//f0xuQGVMbv9//3//f/9//39MbkBlWHf/f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/CWpAZf9//3//f/9//39AZUBl
/3//f0BlQGX/f/9//395d0BlNXf/f/9//3//f/9/N3dAZfJy/3//f/9//3+7e0BlCWr/f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/8nJAZf9/
/3//f/9//3+PbkBl/3//f0Blj27/f/9//3//f0xuCWr/f/9//3//f/9//39AZUBl/3//f/9/
/3//f0BlQGX/f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9/u3tAZVh3vHtAZfJy/381d0BlWHdYd0BlNXf/f/9//3//f5p7QGXycv9/8nJAZbx7
u3tAZbFy/39MbkBlvHu8e0BlFHP/f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//395d0xuQGVMbrx7/3//fxRzQGVAZRRz/3//f0BlQGVAZUBl
QGVAZf9/vHvyckBlQGXycv9//3+8e49uQGVAZRRz/3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/


----------znadnqpaliozhlnbyobe
Content-Type: application/octet-stream; name="Loves_money.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Loves_money.zip"

UEsDBAoAAQAIAABTxDAVvgypjVUAAPhRAAANAAAAbHpkZWdjdGN4LmV4Zb7uyIiPf2ti/97d
r1O/wqXau8fhgsUKy0q9M71abg95dbw95v98QIpMz8ZskKOm9a33kqLrKklUOrmHcEIEtlu0
aVQXaQmwxgJfinrvIHSDOxmieZLWiQTt+Nrs3EL6afNjoYQvtgoWhN9j9tSPNMozN9j/i0fc
+UdaRQSj1QIuzRBThDek39qPIOuSauu4ORpEdlSimgXBvstNjzCFMOLsa0T1VG2jgm2r3fTG
rTfi/0J4WYwKZf3U3zBhQxFHgyd2pVjYG7AR5t1TNGaTIdvL+dD/whXVTQ10GOxXkdB8hA1U
xRBZkHagAxNBWHOty1MJgbUaanWnj59jDsABc9qgdKGxatUpP8pzLrESdizCQS3iE4dB2EiO
blmGUoaMgcmQemLXGk3g4RMCOVCSXfVxquSkVyXct3djRvid8YXnmk/yX9XAz8tj5f8RSa5r
kHs1V1Wa4oMvhq1072ZX+GmXH6rR8CBf/yknYqbWul5vaOgViF69gofzVvmhGpBM/5ZQ2VF1
IEkK/3VKJYrGGMp1mBKVlfXpsCm7rdbYUSUoDxbj5cbD15N85ZmR1BR6D/F0ycSEpZkbmbto
eRsGzb9oC2z1TIJQVJa6nMtD1+uNeAVPYv8mEbayXScUqXMK2bk1XRjareAJAkuUI23Bm1OJ
uu8GITUy23uxfNHij4WT3ZHikWpksJBvM8D3YoGwUUKhyq5yr93fMazWyjAdzf50Kcc4LX/F
IoGWQ7/Lr613tvccnWophRk8qNYRqVCVLODhqUOnR9sNpWT79vdftZdnrbqjcZdgWWx+AN5q
A5Y2Z4FiSK+WBCe+rPiTIn4gBKUhA9HPeOVMHmVs37MpSLYBW3mEZJ9gfkF7Zc7gM2HwAxfJ
ep2xZXBge6b2xfE2Ih93RDyXjxo/IP49NyOxHOnRPuRWTSld5n7dl7kSU2dRjLvctmVjy+Fk
umh4TQ22iutLid1ZcyLLnaPW45DjSc0A+sM0Ehl29xaiGh5kWWDr8oNEoZ6i+EuVOaIKABRP
6TrBgU4/T9Hp2Q0SEw/CsVH6WLayPyJjJkLT75w1BMFPKBIu7+PYJ84IHiWWiflqqkGCMeOQ
Hmm3VUC+y35W9Hq0rsCals0TXBXrzNT5XLw+rmIJbYclkvZ7UUFw0FXHOh5Kum1Rq9mHKLnX
y7Gfyv2jRm9pINNLjdppF4bfx+MdHSvkA/OJtOm7B6hc0QQQPufISEu/7IR2Zc5Gu0HAB8hm
FDMUFLnK1nUAmS31aC5rvoIHuKbYiRqw+QoWKWOvkIyfuVcExnkSUE0SO2i+0KY7SiqaCLkP
6g2EVPEAU0FuqXMos7cSqRrKsL6AMc1U83s0CUQK/mTqDlMR91CJFxAZuZo5wpLpakIW04lD
twILl5o7vrhmkBeHuilTFF9qpwhTPA4O50pFR5riB9MpXWOQt5rBChf14XxpLt8I0HuFqJXE
tWOcbMx4WL9hOwWlBG+e0HVtlp9tKii7BP2Q6ycI/2Kpl0+k7T63j0uC1bPVAi+OH6sPcpZW
VSsNb4enNcBBJjcUQ1TVgMwWpIY+yqsNqGphjWfX1YuoZtKXYOQlQL6u5zHwosNMa+BCrm4n
DWSsbxhY2fGixGUubRcr+/4A7X3WfrStmHQAHIbO0ETedAC5LokVOOy4tOLfpDui3ssSifeq
IW6EpaBr8yh6Y/yCFKXfWV4XO9W1/MkurkhFZJoussu3dwBqjDrwrDIHj0XXgYlsJa2k1b1M
pPcWEEuyO26VMLnfQSNwBucYL8extEwNhslVIxep/eUHW3klVFpGpnYusYab9AXaFRJJ3dsO
rh5ZIigKHGj2+aOADrHgT+Nlqh8ZIqv91LhrmCCwzFEX0jVByQNGRC+6i9tvGT8NrmJrk3rE
YbchsKGVnkSwYg1zyv4YiLzrjcu3eyn8fwb1NR44Q0nnD2BoJbXuQt9SSCh3OtrQfyYPg+GV
b0G7Og4+68rGvdR+OqGDbq0syR56HEIqyEVoCkq/TZdsbuN+/KpYArZcCOiNV9H7YzH24fse
s1323FcEGMOZo8LUTcON9fcMcfgZ62y6xGgdqN855dPaBoJwU/VTKM03C7gc2sOf5m+HUgn4
YK8aU3S06VVofNfGoKIMp2W77eRFHK8fs4J3O1p0Mq0FUtJZqf4iDTcw8B0S2jNVqKQUgjSN
2tozSDiGP8mvNx5rVIpo1IQ47kxVfjjr0hb1/bvQTC4YNz+MMxXSyc6j65wuxeDGMvmDOqiO
QGu9cyajP7gR0W62i6Vv0hapCQHQ5vMkYj3klS5Oqm6MCxWRT/gDKtt6QZxOAdHWWd21fLVm
czefKbwru9AdfKcK+xb9PDdVohs0Y21noGexl4Ufi2ypDZNci/hYhN77JCSu/7cvsVsSq1KH
BlOf4hDQhHXvOvIZFpla85jZcDilNN9xR6OrsMRSTgT0Yby8RpxI+gxrVAT/FNoneQIgnEpA
/Vl9m+bBGMI7FC0fq0NfdFK5k5VPVR1Vbj+CdAE4vYBtFRBBPSP32mStJhu2OOSGMKJquEkF
uFcreZj0uojtsQ8Yy6eTpuvzD6HEIQfz8c6zH4WIZGLrtr5i1jyEt6k08SDOpqCa+/Pobaix
RU0dl0/tjvoK+LhyQOAwAfqU4FlRuxlgjUvyw+DNwe/0KB/IqZaXAPp0kc3fXn+7x2iMSO6C
0EUsP/m3E0tb0d/mtERkefk+txnm4NE+SBBoxZILDfSqioRmXoa39Jsodz9SplCQRndZlBzM
UPJO3Ihal8l4yPXB9UIG7y3x7YiFaZVqmER7bZm2TGKVjBr2mFpIxWjIz7eL+qhkRntiFljY
Ei/sCMWJd/Nk0g8Yslxl127m4wHCh9Be7KeU+iojyddvTmex57Ku3Pyvx8QGmYsDliZBFRch
iwVBE8zcG5KwyAMICD995ExSn1nnzDRJ3NZ8zWjq7JULKkk9aXeniyanA4v8aQTL0fCSRZyg
x5V7fm+hXeokHtVDYR9v2wH0wsvzRxme5GwdeagvG6bOGfujhlXVLWRfp+ToLRwtfTLm4YSK
P1fvl5+i+mrWDkSV1Tl4Rh6XQ/KFCacofj1SsjLAwicQCE20h10bODObvB8A10g6JpzcnCQG
BGwen4NY1r9bbd0THpCNeXL6SHWXy4kHwFFIqYoufJ2SmtZ7X3Kyt6LaOyaHYGcwIzTQJwE3
gwxCpHY4vqLsdi8eaSBKQBHSA9KoaUprj4j4MS4KhSqaYKJ2Ova/yIHpsOS8joDue8jh7IIE
iKJI71s8+GGBJ0bi00LArMXfiHPhLMemzug+vDZRx3RKj3wSdg7iejRkl7ooICn6X4Yp0vH9
GK15WrFnUOZto0VJ7ycdMbKbwgCunciof4ADGb6K8/ycRVHPpscCSsaOplhmicV2+n2S8xSm
QHJV/iaI79J775i3M2lKqN2bUKuX4+aKMPrr58GhzHCl2fy2KQ2jkIWJYzTwoKycqzZFy6zy
6wWGcWcu5q/TjyAWX54kCLAWgV/6xU2sVTmmta8aN+BfT2QeBG7skMXVpcmWFVn6C1sTWhSV
auTwl2yKk3kq3/KwyVNjS+KABMHE/tbN6SSAT4TUFIAV18R0VaLEgMVLoy+2NTsCRBZTTCIs
o16MR69qV1xIYMe59luiaZYkaizjMfrr4xBu+IS2oBF3Zcfl4TrzsGb1inktCsmz5HL+KB2/
6KGThxLQhAK/loufRNYXo53towGTWZimfbDcOqnyTPQQPZR8B22WEgxZysuHjC59y8NyGVgD
i/upBpC4kqcBdU6G5m7fQbTJPHjPCpzsCoF2flLmreR4avUAoCY3P0IothUyYBTLOvojQy4U
X8uobv/ntnz7tJsgoCvSBNcyRhyteJXPX1GDxnd2UcgE1nYUGt9buz60HpskIc57SLeb/Qzn
AjzOkPfD8o2hcGOL3oa1DkjMdyVc5XUvPyBrCsSXwdYdVDIjs9rYgG7fb4c8Da5NXZwJWseq
jil4oqJqerGnzvH7/DxrhIjt0nYqFi9T1q0Ly4MLkvOKboqFZ+IbnHUfWArxMiOkWOUuIr99
oxWsfA0v+o3K1+7eEfZrIo9dInXU1x6jkC8xBaFjl4AYXzUSe+kIgZOZcsGnxZAhquhZpgWi
tSlYqHrQG7YM+nAhVcGf39I9hDLxbLCqhlsGGhW49D9pIwWMJA3xqy0/rIC61Ec/czjANC6f
gIO5q/Q2n806faQ8e9vnqXnO0x/fW+jWgQE1v0RKlUXSqeryd4BkFv6Zit/B8a7eEOV1Tj6Z
RV38HK4flIVg+c6BZP0jwMYdFFPc6sMoovOn2Ivdb37xgFhHxDN1Qv9hknd0etTSWHuU6vNj
UN0nofZOAxLzWbJzYKrLZYKpotYfyUoPYBYgrHRE7dAN+7fjsj8XWukMDOq/5oYgtpWQ5RxD
pBlQ7u0spR2fLONa7BQgn09l/xLMkDPTEHRoob2fvO33p3KABagZRSWRFRTcdXO1EbX54IAb
3aaUWcjwZEmPHqXT527JPPaGpmNgDcukSkBn1nxGhlJt6AN1IZXBE7GUchmAGXS62MeyyTv0
/PBeWBkH2Pn7vIT3G7wqa76hiYBWFQKG6RwDPE5Y2Cw1vRBKcapXMDzemf1Kqi9DnqbZa6J9
ZGeg5Y4HLFidpVBFMtoBraHISBGyMhHR4sMyBzzpGakiFtot9/ayWoTuVwUGO7I18PHrvtjK
ehYMh2sC8nLorFIZjzXialRaC9Q8WkXRk6yw17niKQkUvbTmTvISYeRa1x9puTqOvAPpsgGn
iZDEXYJfSAaGnAnjdyLpgEgasLbF385jne13oUUlSI4pm1X1nbrqy89lpFm2tQUlBHBtW7Ht
2ZZV8JJXzErkVeZWuqOV6RkOG6cIDzMw4znniGXLKdpJAM6dBN0r4mEs7w8qtEpYbWcJ7Fxj
vFz2gQtvYuJCNuUc7O9AgqlODDmtifiOvkx6btWwR0PEsWOJxO4APlaGz/UFRRQXfikD3dGG
EN8zc1Jk9MkN2emNu8GBz3GrUXLQOYmafMtap8dT7d7lcfF7PzcLn50O4nG9zsfH3FwqHvnK
ZZZOMx4ZGQtgu821uFJOIbVdjVlfPp+C/b9EjW7bSsBUEIwpG1kftogsYCqMsOtCbGtMg18e
rtZgYxVK0Lx2MJvImPqV2jLmg9LOhhchaFoBQ7nsv3Fk/UDP3AtK28h7XccN4ORPbeSZg9OS
XI8Cz8jafFZE+5mUKjn0ZfJFD8qpH9VDtMw/WqXio2uHFtW+zFP9/G5hM3DSeW5uHDBFGi0G
M6tFRuzUZF7GXB4Y0HmnmgmaaerHy0/JQuoC5fkSTCpjw41+5THnwIH8NaD20Qu6oZuep39J
Y0xiSlcSg+a+7ZZwiVCCEXF5nxmIEmXsD592o6h6bzVLKcB0GXsHQfskA7dWyJAnSOYab24H
xFpcHOsoy3nQB6h9STUqvn9t54Z2VX6unLyeiNQHfn0v53VFysIndUJzclj+Po+waHIfLw9y
RIfg4L578NZpdPImGuwKmtN1elrdNP6Y2TM3MQG12+vCjkJwaiGbNuyPmINNJn4dG2cFYNGr
4a+V5KtvSG3j0iWsXxcO/gftg3NZjkbfHs2foOPDWbq5P4UV/qLWkIHwHqWesl9NbdmNqVFa
yWBUNIBNlNMuJk1k2HFXRDRD37G12p1WcyHENNxih4L2UlTdL4Ionp7LJy52fB8iH64z7wmV
6qwMlZEJWi4NR9ul6Iwcy8/yjb5apL5dO35FJEmICF83SACra7ZCeFNBJupE3mhHMiJETyNt
bxVonvcUUut8ZHfwYHPopxp8dvxtflsdpSnucNjr7Xinf1SJ3+Q5KLbRCl62Mu6kvB+jAZFE
psW0uHA/PSA5YF7bWNvBTAXNG8wKDh3+7Q8FBulblAY/PUu5QT30Vk0YtQkKHz9Ntjny4E2V
6nyU01txuiNdZ2Fd5NMsh4eYoRtJJZvkKeD0kwofixvzkSbsLHRw7zD7W+oTIqaDXawUYLM0
6NLwywYeGYidArr1cm7S9nkcBt0oSiJgcCpmtXAWj3Bep16zwAIBz4lZ53a/MmG1I1oNu8PX
ir27xIK3knuR3UxRjy3FE4JIICmAov5K5CFd/fdT0NrFCxnJgS0ioQJ0zKNCSbwi8pP0V3t6
tIUV9ISYm+0kxrD8Yt8xlT9TJcysnnvFQRTsTPe4hQI/WMqMX5EX1ssSRyySyfvMV4FOZ18o
lIiU+5WqVyioL93BEwUqJhtH8Tx9qLHOBvBJQXbtzzopszzh9OPOC9WgSU2FMJ3as4bq3nNE
7UQKMAGqP074riCMONQegZihqWuVmfqnijVeLFST7QOcrD/svCHi4S2CG6x7T9CPANJdu4DD
sOFOuLvndXBs+bg2+GB0llMY1hQM7wgqcl4oQ0Ss+GvpHweCuoMDvjafc+QMlBGdzDp0rAX8
l55gjEJG4ZZCqwRGiq96vQzBXYrGcVXl0vEEJnaBN2ZkidMdK2BJVR2NeyACvjwkQK+5BYW9
cy8Hfm8FNRGuBL72kcEjWmdIczo5myJZFsiXveyzXd2qkyO34oObMQf9EA5ejcb3sogmyT/b
3fwwRmx2Kkd/42dn8/nMTGcl8JbpICKHDqKPUSsXtKqcXEg16m7/dQlYokhN8iGuaJavYDIg
gxdJ6uIfNws6+PhwHjmRISzldAM6BAaW0Gg5y+tdtinqyeN3MK2/jJPuoiY2z3GxhjwZTeHu
e7s06dtVQOgIamgH9X6zDi2IvikFMImT5xopZJ5XNWGubd+A0fxk8YVWHfnrhs69S5fHofdn
bt2abws05KH2vuB0JX8SAhrBj2YmXTM/QM5hRPmofrmAfrtSJ1RJhllsgiGPOrF5NnP7dN0k
AvoudpE0COvYItO20ZZBUqbnZHu8YCbnqHC6ddX/t58wvaoEAE97tYe6wYy/S4SNhCbrUhRt
QbVFfBn5jjcqvdYTExhks6Vy51igLcVQzRIGPKUz/XiB3ByrAiM2C2og5w5WYtWrgkgE4d+n
r8ZOIpvkc3r+qiAHHkkFPQTUlmbs7xpH3q/lysOfCyXEkHoWmR3P81pTZlj0uhyTOQIWpEIt
3yS9JvNi26MqdL4WWtCe2Bns1zHroGPdw8DSyRIIZvebxPOh25/MOrozWbYaqKvCb8XVg5Cn
0KsRUASbvQuPQGW5WJq9uZihA47E2+NT+/1QNN0+2e1Hx+l+caPnT6jk6QffEsDP3fUnxwh8
ZJh0SH7dKUFGb8KwgjD9vxG8hAFdb8rKOZa2Sl9/n7Y3bp86wKYHdpNREuVL36bhXJthgiA4
z4aqM7UIbFOVRTOQI5u+SfgZW2caTFve9XWdcts+Fx2mPrgIMGaPOHmOEWjONcnEaYa9+r2p
9PBv1vKrr9T1b4dH/UPjaZGKLKciutLwZ+CyayBqQsNa6jjwwKqJIHZE0eJdCuW3JTLtkPak
VXy8SjxYMasnvK68EA1cVtukW/mV+NYdd8kZ2Mc/SLbzB9KXQ7+XqyWCtu7wIdSUsOqs7FqW
bp90THMdYeeFUBbAhC3qPt7cbm1ce68OLPL70/yU+gdJPmP3JFnPFxaw6YPdzhEcfnZyL+4a
ZRczA3c5sVDMdYIViZfiMbT/+T/r9P4hbzfiOZeDSvT2M6NwHaiGhFiqA6yIeMV2ztSPS2G0
BIEYxEQS4ezJRZVgp9Rl0ZP6i8DyBfQQ+uabLoarmLRzbesWzKeeELiecqiH7JFExUtBDfqP
oBLp9LKUo1xZ0ppoHKFbNdWdJvDtuRAEFOE+dQe835LxIsd2NOzi0rJyKO+fG5vppFbAGPhx
mqzzL+yFfmwEesHtFD+/zRyczldDEvbM1drqwCtO+5a6aIIj3Wh7CmjSWvNHanAOpW/UWMJw
+d2P//SVzqIaySa9DqQnAMAI3F4zOsWNwqZ3y/prERQPQU8oNMfRPFJRN8KojRElpu/MgnHl
5St9xbeymy1R0PsquFaZZO7+ZfWo5T4u7jEpi92n+sIicTyIAluDBjrs96Fji7PQyJJC3n/t
0vXEEmzAVQZZIDLmCsBewtTEnzVaWKgjSMq5rk9IIFsv9ypQL5xgpvERdVStcRfp5a/jBckD
wUgAHywV6DUolW7LhrckGP6rK6Qus12FWa/LB8hI3WtVag8vsT2RXMjvHi2+oOTQqc+6+DcB
gxuZophww7u5t8Xje/shbwcoFD1MvGryb43uzl9cKYhDa3LjWo+ZL24uP0nTcfVpcrXEEGIz
g1ZHwwqSD8fWdC2olv5qa2QcDrw4WBuMqdN7/okw4OMOiUSA8n6793kN9WkuX9xOPKZjnPk4
U5t0wc9gBAEwJ4/5RnFMffWHgemOkn4Is+T6uVptd+W6yFZae94juvDzwfDWTLmfLtZAdMOr
xX/EIpifHWb4CoHwUa19Yx8S3Z5VuGVKugRKeGnwHzjJihzXWhKbFChZ78xvqdqypsgS6Uls
05XQv2EXzdQLbf0fspKb1F65PNXywFadXX+UBUmW12uenUMe8rVdjSjZZ1uvMEpJ2iUP+BXE
7V2UCWqyKnZYDblPx8aAvudENDGpcZIMATSsf3ax+rNSFIaFclvph18N92lF58vOX54hUtiS
eGujBno3dwBAAqDW2KVWjyZnoD556V8NxqQXckvORRmetVvfb/4SQMSxjNNBoe9Y7itorhwa
AsGokGBz69Iw97DsGk9TOxUZrQle7d4cQUG9ujdE1I73zmlFQ/vnh81KcDe0HJ6XBq/WTFaL
nX2suIVVJ392BeNLPBMzLcdvGeF5HqWa6EfcAycIBE7vOQK/kUQAkJXOBGGrRCeyKHPgNgNG
y4slnezxhc8BY1+FKdGOM8Y/e0XlbdQWrQaaX2PlCVk2a15oTyYwV2a8UYKpWnLM1NozhSRg
F3jQPUblLCE/XkzxIl/YlGAZxzo8ni/hNpRLGi2kIpoMFhg3JOFYxzxUV3hAQWVZ6CO3N+ey
okWIUOqKF6PYkdAB04nVj4U1cMHACtnh4El7FQ0xjaIJNQ0pQ/rZVYVbwnkXCY3jMFhGIrUD
qb5Lsas2hyIebMX6vqJmwb5QJjIJaRSqfmpqqRLiDw2WRaNwsMUe0JxT3sQATW3hpU5mX0DV
zIy9glvFGzEO8g1UDzctmfAeHfa7SeFcPH9fWgHuOSj+PQ5LIi4/fueBlwHSNnCU8x1Q3MZJ
u3YdS9/599VkC19yezcl2WmZ/g/abV1Y3y4lGv8ILCSjp6f2vsRk9TQFuGaQO6y6u4RGaw+x
ZnBAaYS9mT/gU8/XF3GYxr5rm6bD+Jwh8vSxXwfL4RKGk7J+8px/codgn1885Ak31R0j7cfl
KV79Mm//XDUhIY4joKX+6O8DjKghLxgJHUqEDhme3WsDJHnwpvy0O8dYGx+b+TlkaE/VuphS
rY3+ldGXpGUv/UYzF/eHbNylRYngCXjx0OznOqMYIa/JzLHCTN5fJREI7RX4VHvl+cYs6yJr
YjKUG0BwuwH0j5BXw28sKcqEQE1hvkpVwq8xkG5/n301D4PVpIg1YP9I+X+TRsFHqxz1QkqG
rHrY0db1epXhAw3jo4WqXzeogmB7qtucIKTILyoaBDqNYDPHZ2oOlfCihXDe68Gbs2OJWm2P
BaZhNtksIgJrdnPi05g9yZwFKv9NMWfCZ6IxNYttKreJ7DpWTQDD23HVYnw4oTFSOvNe1TYp
rHOzsmPtKGKRHywkiUjflj7Zqq4mfIa4e6tqlRG2EQ97BwT2NOlsSqGktZHnobauQtuRl+2l
qreI8R42NlP2shencN94HnCNPGJE6MWa1ZVNb49KETKa1vzMu5JnKLoS6h9i5qPENjQWM2Ve
YxMSRlepw+zHYsUtoJzwvF3QkY3nXrjJLDXprCCHAEOEi2kkDlIaoL11Z1gU1YV5YpavDoyK
vN9Y/ibkAXcKq2hGFpWVi6LVIK7lAdAYDiSq2pxUFJizbk5mpFs12yLizc1v6sENSyBAtoJD
3Z06QA8eXj7p2E6PC88/RnNVIDna9NTnu1nvYXtAC/M/QT9mdu351F0WEx5J68iz7yBb/ol9
KHGxU/ai32RY4F7nDrf5+I5jRRf/AsOQ8v+dGLtsgvJ/MFf/AontkXjSj5Em6d4B1/2f3hSb
75GscOIoV3gOv7eU0/HX6TWXYCizgNgdQVpvmcGwoCwrn6T/HqJfluEILe6w1UW7dYjuhHQ6
zYosslOjWeV3ZS12xYtm9AKlucFsefEXnBIQoJAq3XFbktK/qv4tXmY0iLmb+g2MrgMeXQpC
SuO04vqF4VN1dtOIKZKth2mYmi2TyfJ/5/qxumAsCnLdKJQZjooj/aNLmZ4moi8KDQ7VWZaT
PpZhMrbP2zDQ8ZaWfGWYg1Qkm8SroZRhPrAfYV0f41sDCZP27VP5uMtcc/BNxJfuj9rNeNNr
KTU8hm9BWBMzqX+rMxHYQeZjNn3jeR6pQ++CzI8oOGgS2ZJ5S5yvk4OXQcNggwYQ8+blY1l1
GycdV8j6fDLI7KHGNQ/zXxm7SamzP6XQzRkaf0mUFGD+9oP/3o2QiFcLlzSmfQnnwG+ou3QD
NDLgPd1l8n0N5nzGywzO1ho1VFcWXBsTEhbQRCrqhw+qsDcrQqmDxqaDVVTH18UPfPDzFU7Y
yIyejhCPRxAgUHo4J7FsrGwTcjwJXtreVMe39kpgUosNqQghreX75uYXMJCITCzQ3/p2AiwP
DnS/rQMspXPihnq1qHf6daDgilh8FyrcIUtLocDnrdihDr6Xt9WZ2vHxTJwhSBwLH6PWqNLt
jR5Eyfp7BSOyP9fQUJHqBjiq/RSWG17uq8dP/Bl82vNwS7cC+2UfY5SqA2BFvwds3xdYpaWX
mrmnJrBp/X9ZvRCdnJ9HT5/uMb5TgNzLIYmApvogWw+FWQvoOqkwANFYbj3C0FNAACR5Tze0
qls3uqO0UbbV8V3D0p3uUVNxpbaDcr05ng2HXfZIdezUxbBFbkp06CYuVPaMsMbkzf2+kuZu
DsVnVAHYIaVV0oFYY46Swdx1+3hwOpjFy1osLQOPIO31YP8AOaMEWAfF2Du5jRQGiLVmg3lR
iZNtOgMioWcNTQJKgQtlNBiIbjigufy8pjjQIRMaRcSzB+Ofn0zcmTVdGozNQFApioG9wW/O
ODvYQFUaVk9finMBS2Dn5TACede1V98RhgCO1sEYfMMfUA9MBgp65v3G1ZyI8gZ718MF0YlR
JtspZrCAfMASadDYmwYHiBPshXnTc/KAMKdEOSR1CmdUAYtpSGNZ6dgcow8gPbjDkjgXBvzV
e/rmDS8eEvlqQ638u7ySQt/dwngMAR5nm+wcqHg5pTJ3X/oQ9ECbySRfGnvN8S8ZzvJe0gYU
hgL8GBThg4p0COvfbKOQxSdGzCk0SMr3a2oG5MFw7ghAPlATy0k9QxdVCSdZJqMNuiT4cxZM
QhAOz1qm9RsXlkvsS/IOkpp8liSz7ZbZ3hfrkDBSzkDpxPCGW+mGHycHSoCdpv2QVECg8q2J
2VJ37MjtGq/wfw6zXgHKGsHGJhOH+qIXpD/NXBAGk7NPMgOOYTQgTKstHaoIvBxsPjRm2UL/
K7Xs4JwMTH1GskQ3bl2puVy+my0O+PpNaXtFe5KWB0ambg2A/z6xjQUeIjpC2mvVY5lN5ehZ
stAfo7UER70M8wicPuZ+JKhpwvnOoIPQuzEx5VuFVfPy43YHHcYLuLCP0RDnxTnQPl1fJmQo
AYpunbTd3RQBraTnOX43XSIq/JQ2OZMfHATeqIIqjhJEBWcg6sXJoCYicSN9GbdZeSHab4pc
uDca+OEeehIVNEsTXC3kEFv4n7bGFVq9vYmHl/n+cT5uDNtfviThOoDoNf1mva+jeNA3n8sE
lhg8+J6o15bptbawHEZ6b8EsyHdnbVUFtQQq2eTNYtd0kixo10wuon2FYMS5Cxc9+Mfi/tik
1At4fEaXNKTRnULituK2RdiyWTEk2iAivCWMTh9eQpBjJxPLkp4IbWhV/fG93D3bHHBBwFB6
IzudMXFB33+oa0KzSb2AAggGCz4C9MDNZk2wI9cMciokxe3/K5IP0LgtBHMNVFT+4ySWXyz2
sKd2yQwhSY/1Vhdl0skIjR5iOgw+B0OzJgaVqSngwgNLONFfirnp7/Zy2no5vcpXzPmwjLCL
rysKnaRfgRXqbx9v2Q7tuhMLTObR3qhGmb8SbHs/dYyuwUMCi5TC0+84ZPCewYisEiA61wR5
rolz9gSGSCccc4HU1HgMjvA0j/B8/oETBXqpu1t6Oa54ClsIai7qB3cVP14OOmIULG48Rez+
HMgTgwlBS3xKUvp7lyJKqwXnnseZMx8PwzHSifmaynezvfO3fLLgAJmYQDG23zqBkThMdSRo
inkJAvyquITeIpCFTTowJDT3OU2aZkBt8SxWiwL43EgpaEON4ujCpHdf3CySh2iq2MVT+Yb+
SWT3w6YK3yxht77WjVx4VyfDCc77ShVDCOm42eQLC0P6ymiVhcNLd4KBK498XvtcKNZn5z4H
8Ur8t+j9ScBKpPStqE98UPaRgbJqN81YpCSFq9jbpXa9lzryc+CE4KQHYKE/QZvvR2dLPxS0
UAEenHaOApR5VroStSKUSUpXaogAgyht/sAa9RjuRmFkRbsan0xtx1obB7M93yUUm/KbpqLa
yEWlU7fpj4zdIhBo70Fe/MZFTrMC3s/7ULeBSRkqI/xv6faHtNdU7IvKKFkab1pgswwkQovs
lkOIU12zM8mnlDA1dAHMW8VfMZYI/NndUD7XEogSCg/qSJZBotfGNlZm5BDFAWjVuo1/wDmz
Hb+A6aT3vbai3I7vd/C63nVo55PzKbo92KQVkQOTEGmRMK+bbO5YQB6j1x+frNAwvoJTj2H4
yTTPXdp71/PLqMeM1XsJec1ptboRPbKKeRf0wilJM/2rHZY79hk7OT4CMSTzWOcZcwCoF6M6
olqoO0/aK0NYMt451s0xFWi36LfSPTC4bQsKdjUAf0+Mn9BB0UVsONvdjV6A2kqny81nReLo
5bCVS4nRq0x6Phhy0EusYKNG/LL0AowYBo7WdOS0dmQqbSNJG/jF+S/j8oDVMDJYpk223ZmM
Vi0HS1gqaHcIfzSUWyFvrWQfLmPyFlShV4UQtmxjqPL6YW1sHXgb3HfRM7TiQvQp76VX8WT+
mTh/EEkUwBnRCtmvJRzT343Qvh3NvxI2uXkgeTuHmZX8SNwFGpsmpY46LIEH2zi2vYPbpJXV
FsQtM8JrwxsgDbFEeuJX/8Jrh5BJWSaS8lTwFo1OGkRxr7lypEbjCiLfQ7cO0tIWZOwGoFKs
WLLEndqimnQf8hhf9zk/uelqyMRgmqpkfILM7jBfn0MTVVJxQAKClP7qQZ6ihMHSce4kf7fU
iJ6jLSf6y56UYMiwBcNJ0hKVoRHdPpSJuehSLHYPFDovPiFdQG2RVKml/TtHnufyV3GqApZ5
Xk5KqS3UO0mo//VSfgZNR/PDtutnYhfv3gUMZCgsPlSX8SYrvYZTKUyaUidbuHvIKFnt/gyv
imv661XnXAU7IZNCGAFhW9+5CqYXaULqZNs1X1rpdjxnOcnH9Ck+MN6YiVDOdvij8tttuB7r
eM68UYt0MpyCDqjCCQ+zsW7cMOL0CzOOeBNY4OGxLnWcj5g35Z5uBq4bv3OnUeqcLZhiykOt
DPLBdO8N97Kfb9AEGYo6eAellFAYjcS9NY58s6M5rpI2HNsSI/v/BH2KNxLvJbzBm0CS6JqU
VsUosxGZbacRstUXUgWkpM3suznhkWkUYJmffE6bTcsXfdaSDak/H61y/4WCY2duCFWTpTCZ
OGNP4IMHGsyoe1PrGfgqTCLPlhtLffqakDV/dz8710NJiAC3XuzGKRFClZ0LJWaAjGgspmKe
hxQXS+dov7INLnurkFx0zurdYQwPhG2kPo9SQoNl0VLEmGMElvlvKI/dEwUKQAzfV6qTfA7z
IVIa/rGumuDPgMyrUZHSuhlAO8FdGW5lCrcjEBgva+1F3aBB5IratrI7A5DJWPaPTitduJY7
kivbpc6USXZPfpx7r55gK67IFd5OCW5nUAuyoxIsE0Ou0zKZstssawEJcX/XXb4Z0rWMs5BA
1n56EDYLCga+Mfz1cFsrKoPWjVdo6USf7P6aBeEFtjDgnzzgZBNlG9hVEfaEaP/nFqk5n1fP
vFwUo4vbcdF4qFNqUusni+F6fBNCfC1CUzZrwXgL+9iJbmboRNxwYaGtaoMOD55ccswkdTWv
WIZt+hKWg6T9RXxkv0rGSCVuiQbMPkag36sh0k2WAAi9lzuc7H9YAt7X2raN3dmAwI8N4hcD
48x097aZpUQ5PkxyGfiZ91Ei0GB9sbSb5NMSRoj9c7niS229EXGj9FQJgtt61QNd+2sAUI47
WGFG3PQ8gPWRCrVRmq7CFIdqA9THMFvFpajTkadKb1Gp9YYdHMCd4UznuGWTf8RQpq1uk02+
jz3PNT7RZdCPSQWB5XpuNyjapntd2w3kv8hbNWjbBqCKJkWdQuxgA0rzhaoAncKkmpnXPhiV
Ahsm8HAT0fhBkt3tIngwVfixzM6VyV1m7wUD2WP+NXxpAokFt+b9DHF3HmLz77KhKe/JvT5g
5qgf0E6MfPJOOclmO1bmlggqBgrdtZYWYKmp3o3JYUzN5U56WkkIaGY2nT7EZBZ631BSiXKa
ocKAn98BUiJ7WHG4BeXXem9OhwTQmHUBaAp3irECzhyoPR38r/NUS3+eRD0vU0w5NS6X8XCK
NkxxIwjEEuRjvYKANd+QlcAje75qKq9r4CRoYDtyw6XC34WTZsgcrUCWYwc/5JD09vqOjLxC
QXsSHQel6mQeYQ+5w1oeFGl+Xy+yJZ63utVNqkxQ6E538Ix/46NoCa2zT4gqOoyHa+dzcQ3Y
fFHNZO81C/vnKLQ3GxdxTTsnsAy/9uVp3TEqwLi2jMeLXD9EDqx/1qxMz/NLVI0j2mimZPca
cqYrC7haTxDxGTNHdj9OTvY4IeBEgwiiLnbSx3+WWulyP5l7PlSfxGqRiseo2QwEAs/hWPGS
9j8bqt7boAP/GDOOzc8xqS+mkgTsqnqcD84Q841LmtMb3kXtCzydgFk/lwdKUj4x66BjXNWF
HXTG1ika0Pv3OssYxGFT7HprD69eyRzZ03FKUGCRGTBZNDxwXE6pqX6Jufgu1LKc+Rfg63b8
AwT2u7QD9PkXxJUlMQoPAcfCcZnNiVUiUUEhGwXXcGN+CjfoO98Z3z6du3hm+Hx74GrPqP1h
L9OYLKdSbL3PmeUzzG7t3g/CgVQ7Q8aLVk80Dq1VL5buKjgjN7M2JCsipTcJP8Z4i5xRaM6f
YQnymtdGJXNz9Q1KtCSfdgL+5z+6CAl9rPUhgk/8qLLwHLNrQupRAyLRT1A7gJ1VcNUSL/5V
fEvTuqanmgVYLec3SJhR2foIqYPy0wDgRuKHegnbSLEpj864kOmK0697x9nr/5gTEaK3X73K
zDM0CJv8XMrABUpoWV2a7vI+6uGTFDvG0Mj9xY1DddopOQ3Rqv7epgL0hI4Mu3iG2RXwILsf
6Jq/O8+p0wTjzALH7Dxppmjf6eb4IxSac1hU3BwukcxzzZTay33o1tGzZqOSifaY0t38FUzu
tGUWUNaFt3B6ZvRNW7pJTB9qWbI7sgrB7ICTJtUo8wRpV6iF1xuAAbRjBGaH5ORJZWeWgAxJ
YtZV6GeH7UhhYet7H9T1SljVdEBSVh2Fc4yoGB223jY4L7d/egSysGysZSB3LVBoSq4+n1kf
88DN4FQHlpO70VH6kLnwlnzrUW8+OyO5Ip110rDzZGj1tk8oRUp6wTYqEjq1oSiWRruBYU/n
HSpbvU57e/8/BZItI5Xn7oOJVz+1wF742+N3QQ02H6YMzyyL3ElG62ic89MhM2gCjwggIGh4
ZfworUdcg0sORBjUvHALEa2K/SY22cAxZ7PCkb3C9hOOC7cMyxhsoYmVU/uMZEFw+orR7AqG
sHLcuGvYS1x0xsc86QuY3G/iKt/YHRsxsl2Uv6P+ddZfzmPhco5wSpT6KNYCB1Zk+okm5WG/
AQSpmVLOXS66ptWT7VFnlnhG6YYL0iSgor0vhEkVj5idb17mZwpI0LDwsWtpnZwweC1km3EM
jLK0h7Z5px69wqK7Kl0CDV3WDlc6fHTDX06VS2QizmvV0DX3SoJXiC3b0fprpm59c/MczLma
ZDqQkeV4RapBQ1+mGbYSiingcqW+m5xBtegoDCXtTTYZzDFhYR2Q42CMP44ab4nhyfvUh8O2
cg8RcERsrKIEWuqZycAOcMdsiYq8KebP0WR31NN1928IrWko39fqhqEZFsv3oiqdHJRZwVbh
IIvZE5iV1LgGr3s3+Ho+baZQPzPR13Ajzk2aEfoz5X10+kOXplMj2zBWLw8uKyp3lnHIQADS
r0s6wNE/1e+lBYgxGzbrHEEyUdl2h4Hg0Dk/cQhZKUkJLomltW4iOL05b+qFH0oRwuRjCsBs
+ITlvzcCdREmZr4W5Ac1wmunF3cvj6B4kDry8O+Zhkix5GhEuOs8ChErJo45S1o+K9L+mset
kjItk8gy6wbKgXXZAoAJRz33m1oifjEHU5EoCGZKjzS+gxeXVAuCPH3bmZZrOm4XuKCnYEMQ
wlHOKH6AB4nqXDWhouIs2obusIT8YkqqAd6XWaVFSNwbTmFlTrD4J1ikcq+ImDpAGoLai7Ag
NwEMUV3/1wzJit45SKzJcSix1Zo/ce9cMhfmVNxFT740M5n9heJQ26jj5hBEL/vcl5MzymL8
dLIBn+B7Co+G1JxQ3E3I+nutFG4/nDt9Rt1YL/zEwvRyjLXERRO9Y3m5hdC+hzz3Tn3tY3fZ
7bNtjS13nHtepY2b6/L1sELJMCYwifUUmRXj4Tw9IgRCg0tGmbYypsw6EiSi4s8lF/Q7e9U3
gAD7tBNjtDaEpjeo//AVUWcTwH/V+vnfbjXzWx3QSyaMj181yitXRg2XpGC4RVT0nCg9g9xa
dLbw12svQd9WVX8TOLg0JnAyqMSADaiKkIjM5m3y6NR2QeCqbPtCebND/Xk+MUmZCQAGFY1z
HWq0Lmf2SwP5XG779RQ54gVKKLtLt5m3uNQK75HKmS4OR7NRGWI0IzXC0m9tIMhzYjUBQtCR
rm70GsnWKeXiuEUth547R0dQkqBLDfOnGCYjaiIh86g2JiAPBlGRiFVkG1wHXk1ULfzLXkcd
ioG8PDM+6QL4MdhtpK4ypqiqyzauPa22xDfSq3NspCjTyKkj2lQbSt/Gc01QrK6syiFaNlvZ
s3Bo2mF0gjnYT3nCfjKVOExmPYkLSZtR4mkVRpWqGih88t2Q8f686uHnD2ONbi++EIFSrv7a
FsEQudkzz8CbjAP/ZgaEKjYfzNsg8vPdRC7l15OVyuag27zK8LpCsKLBot8V4OI9yVMNT7X8
DU3/7sRkghmYf57misxiH5p5FJly9qOXdqaOjzXEnpWa5DHkxIGwCCZWRLsyGEsXek6H+s17
61XPe12ir0tSUYSNcKqqDLXWOW55i9uyZGgH3NPAKZpbVys/TKyAByPsPBOItQsucAIUbVvc
venDFyKJz3FsstcHsIYD8mVnpOITXaBQjRvSHUC3Mqy56bJ0JMbBJ5xE1dBGbHlnWsMg3QQn
rFhfMZuLqzzjO/Gp7tGMhP+DU5PHQTbgBwpZvnM5HcCQa1KtN4SAAqvfKx7Y/e/I1lFuccyL
zJ4SnwLsKnUOFPVkxJzf4FLQ0apJAKL8pyq3o0kNqJXMUvfHBBR7LQibz5bFtcibhspiYdNy
jNlGAJmNZI6NuVnJoFpdRAL3WEpjHw1G9137EBblDj8EX/za50IoGXjqR/EPnchbO5H2M83B
ga0353YuE8yFopjze2pZnpVU+XSHVsypNEsLZA/73FDLnyvRqVHqKzL9MDZ8QgzFv2wIx0qN
gIZEkS8Yu7Bh3rdqS/QtmJh7gGIwcpXAYINR53ufS5m/enCb+VrOyxGB5d2tsOeys8AL8fJS
3o862uqP4YRAcu4RJNng0Dw4SJ1jRJufMcUwmTNcuE6x/nLny63TH/+YI3wL8lTRZvmBCn8w
AYcfoe2VwxqaBmIW1IQInzuVLn09EM48YJ4WVgocqljox4fJGa+htpb7qwLF69zkf2J4qFul
hIFdZViX4sBECjkpFD88S3yl67Xw3OE4mDn/f5+r69NNIS7OCbQ97q9uNibdaXvJaH9gv1WP
nMjsPx1pcERu8S3xyMpGrkMt925VScrePgEx7uTlCiclD89JDdfty+cXRRGCarqaRMOXeqpo
ruq/F94tRb0UH4AA0CO3NnKhc2P//iI6256uhe+IPNAwLZv74aOnNgiXJwOVg3IbFlHg65a/
N1+ia2ALCFfs3T/mUbw2EqCKtOcTPl/nPoSlNfTvzDz2309K+6PqNxoCFfjucibFKXMg+qdR
Mg2LxDhJA7gjX19WGxb6bBn9SFT3sxcw9gjF2Ue8kNqGUBoaV8sSBuOYhyLgM2R7ralOL1qC
uI+nw0lyfaO97X2PO82eSVnnMVqLhIr7onxNsTXzRHcpyxl/PHQZheGdh1SVKVm0ytgj2YYb
jma3ckydbbozx+xJzlE6fdkmaKNYVYscV0JB5T8eC8Y694q8lMx7GfB5zlsuJ56PiZK59/ME
Wl9yHAKh3hSh3fZW1diBzxsvca1pq2KEQ/bq5upR1LCkQmS6kUDo8vy8Vw2jOYYb19434NP2
qlSTt//GUTEIrOJ1Cc2fibPx5dU5+4ExJXc2LffgiCDQFIMm8rneWqV0VjDenST91TAlJE85
rWC1bejP+b5CIrnX0BfO1Pta0h2IYbeUcRlKvJRiKwUOOxc62SCvq/tUazZJCd+KFe4fy1IW
m3nOkjisGwZCapXPDvWOZbR27XfHOBxQHyY8ZHsT6v59oThvmqY7niyCAQ8+9nTvKrCt8v5A
UqKfTZug/VMEGesm0vk3EedDPsdBDlrFaEhs6hpldrckKyXkYD3K3G9x+EBLw5qHeSzKCGzY
6S3OPcY2j91lfr69gYBxMIfLLgxMQhwGa2OdTcz6JsUGQcC/5tD8ex0q9mb1yQ3ySPBpAAuh
tSQpjns6bWhvSxhzIWDliPDzwdzyPAPLRTvEHjXhBwvA7IBCWrLUvHi6vQEZ7O7oZPZ3uE/M
3DJbCL7boP+gxYk9gv6WQgAITd3suG2HM39mamAtGq2hWNyiFDyDN1m3dIQTFkzSI0h9OZVJ
UgWfEgNVs+NkUH9lciibltH70OMQ05FLw8Np7A+oCvOoM/1VAnr+064SxBCpqkf+NcF6llTU
4k8+SCou/nebKkHquhDPew1JizXfHEOwV7yPZBLzfjQzGqXtQMcFvVgzEmH8loSiL27mks/z
Lmk76gLRzwdfni+fgMWunTlxoLQyKEuOIzdrrgt5g5lVoWi3a250a/PvVC5XVxDo1cUdH8oa
l5WS1Th10yZjX4VfL3iD0IGhK9XklR5Ko0/MRXWT5+atN/nq66KgNgs3C21OWq7KDXU2BKeh
7VkytvGPa86gNAVId4bWxIcZpm2vo3I0cpzI5mCsdqmHwqdi+iMM2T2e3bLo3URN0ws31FPP
1XbVOkGxz72r9jyzRbVYYk1yUqPE8bjrh6O9v9UYFbkI/fyYayzSjPxsqMPUcArDTsEjpCL2
vrqsSkZh6APukKeGYo4mL3Aa2SAX2UrJ2XvGXvb4i+5ZxCYze1f9w5VdqqC/OO/s3ei5yC/i
FQth6Q2ka9IjZyf1jQQknbmvB8ZSPxkynW/BT8ShBGFYnGG2AGwFfOdBMM8O+Swe0MOLqHHx
65//rybqw5GSTvA5BIpkv+Jh1154QJfyge/wnUKj7TT1S4eMqd8gGpqUwnw5mMgiV1JXSLd9
yOUgqvWYd7dnCUql4kYh97IXB5OdymSvkPhdxwSrAzV8t37jEzVmefXV6UnQ5YHY4y2exOpL
arM4WU9l0GlsiVMSLuYzw0TpFgPLW9Lo5OR6idh0WAos0sXBhp3S8clKl3oKxvAN9Z4tgs2c
EshHgAzPIm7Rw8vHdVoTLS+KrdNfbj9CjDTwyhn4gG16OXo5ZUXBf3jwpl731FNmI6OMV4fC
TaSl0PUtS68ApMHLF1PQOQK4eHQWGQZKbb7ZIK27ph1HGqOcuUshq0mM96DrEGDB9Hy/tMmH
GG5Lk5kgDm8mygzrbAo4p/pBgjqWJFFbHwo29VEdqDglthxQmsDn3/2F7iyloIutA3i3RnAo
6ZPjb9jlOWU/gKvHyfQF716V+inzBlFL9PlsgWVp27dNKYX77vENoAQw1z1Hi7KhKVJjR4Js
7nprItI+tzvvdBo61w6Kw9mlsZNzEUGfOh9xrMCfZ2WSCv1pnrH2EYvrjlXB9PwfK66rpr3k
Rp642TG7GvVegLJy8JcurDuyBBW8HTq1KuA5lDhgkbVdjDE30FS1lPMgi5rBTKWv13720axz
5LYEq126E8hBOdug+NY7S9sJmlZR8FtmzSaJANd8V+SnzGwUF7cbuCrDuF2h4Yg1uxk/Viyi
qTVFErD4zr5MeEadNgCrgpp5nJOh2NZ91eRqUMg+Epq6Ev9RBdvaQzR3Pi5JDSVFXhLZ2Co3
enODaSaGb8/aTtgIATqIQhdXM7DlB3cGgys9JldbFSHhCYopUDtK6Fwn3kSBFjVSod8oSibM
oHE7N0XgNiMcJCvaHDzrZpPJ87eQgoBxUtCx6Vwb5HM7OOTuORQus+UFGkzcKgTOSrNinx/H
TqSvKj0WD421NeqiRH2uJfHJf7nLKP8+OhyLw6aV/7xeS33eQl6YwiytMNdDFciuiza8Em/e
mvU2twTXAfSwc2CjvruggnMNsVuyp0j+txQeBVfiBBbMnoHGcxIMxCJMpPP2uizy+yqhk0ly
Fm8sQiZF7s80LQb4LO655PsurY3ZgjiYdeGqV9FUcQgQIe46ymEGfgnunJJUqTPpZo9TSSzX
oGKNIt2joZ8IwQnInK7j7gtBCC7xd9W4rV/bCPXlk2G5h64PohBE1RZWd1t0bJ/2nlGK6CJS
rH9CskUpR8tuXOn6EdmU2+kCdwDLtjV6llCeta6GSMtmVmJRJbE7Z9975SiMb1nfWoEOthBh
UHn4BeuY+/6kDMZYH06ve/aGvZAzMYM/fa7CByd/OLFdaqFcAJwL64Vwf5Vi7eu0UnXuiU0p
3Rf7cJr0O/6BLTuYkhv9R9brSzFRPpAfNCi1uRV9oQf3oOhtP3vI8dCS52gdD05PJw6xxk5a
s9knBudRwvKJEwS0J66dGVXCk3AAn+eiabgKMosY6vWnAG7NPYsWOPDEShECPxqLJva0N15g
DJpbY4eEN+/XztXrH/FaiOxzWp8b3rihGLoekx8Fb8edSjNBe1rzmsuS1QEWk6LTkJ8+v5En
NK9hX3ktqKa3voXFg8fTajovIc8dUKUGn6XbdVZxNenMLZ2nCahcpTq9zl/MFtFV4CWclFT+
GORjjstU3796Z3jqtnCNii1x+kZuVvCSG0orjYodPc+FK/YSAlZEKZ6jNj6GNLxXm+F9CIAF
/bZf6LqCXucmr5yq1uP+zVmqRizAwOajXZ7xXC59yubUpWGadt8MIZKs951yXhUPxpsGBn+K
sKsbFKulpg+dz9fqG0HTUcxaLiwd3kGGoCfGFxPCuULpkDOO5aRuIruyKQmzY52xaOLjcnGj
aFs7+C5nBcEzKPNA6F7Vl0VOA9Erw4AWlB+1x7tK5Zv1hohfNv8oamVNBjlQnoSj6/26cSy7
hxU2RkIIKFU905Dm5o7dmrTiMWKs+iHSMtOP4ep+VK9lCw86XirChffDaNk86/2fiWwlLx+I
dl/O7ruHvC+APDnXIRvr4dRrmFhqzlkNll7uqV2+7YWDE+ndeVfFxQGDgTitIUDMIRsgWRv6
BtsKQesJDv6OoIeM6NynLHq6Bl2MW5/wC9rnhDKUk2UsxyV0+bvsCRmtUUhX+WI7lr4sBwHp
XDn05bw1uGznyCXE723N2G8d2IrWqUvDWZ5d6C9KTdzVGXIQSPG2jwVaqyYB4v4TjL3qVmOn
ZHv+PvKqlOQgGKCaYf1aulELafI++EBLCzRhsetz0XZ5MgUuZ+ywaeSOGJBq6ZYOfMfDGN/O
HxSsD07oTxmCAKTn1haWs5OJKPJTuhNTSNugddOK50a/dBJe2JL6sSJfrffoiKVp094ygclP
XyfOijvyo5OYwqWERI4lXAKDMSZvujj9840HZXXFEkZTjEUFhI9kURNTKEhTOT+4I4zNac2O
VwsHMMWYDd9pBl3udETcnruzE6eDYpI2prY3AMcsZWH5k+CkkbMOfR9BtMp8dNc7WvEfbUhj
W1LWW8yAEhdx2ogmwbym7PzWPC8FlCeFVSnPVU6hO3CoNPT2CHVzUVon0wYOimWIdlQWtNAe
IaBVqn20NuFdqKpkw49rL09+K/CBerKchpJFWX4I+KyT8GNdS9sBHKir0pMimv+JyZ+H23bW
2LxwnnoYn+qQbQ8dJuW4dI64jCsp4Eoxgw20cKX/yGbXbZ/51g/T7+7uYblY451bkXorYyBw
lx22ofXdeSxDKDLB3z993PQ3M7ZtjH47t1LKu4OV/4ktszhgvFOBcg+beFcP5kJeMBQ8TggB
uhKSIXIZ6nzgIT3ObHlxYyurolusdYYSLL3cyKKth2mC/r3E9rBiCLEXyfOoJpsRmV4CxmVG
pN7taGqeFhYXitFPLefmcY/osk8CypW4seqGKy7bGrcEmT8GzsQ75QPirnPV/1VFmPi1Sq6o
QHDq26390U1zIxDTa2NoKqu2XjzeBtZwo/wK+QcAAOaCxG0Vnkr5Kv5xd4f/P8Wx633jVt9q
ECOpdND3hmXEjFVTVmkkZnBYmNPGVSlV7bc8bNvB36GEjrrkHstj6kMXAvTKWFNKJb3Grbqo
TWGaJZCAwhl5DflGWPmxiekrBeGWd9OYEc4b6KvPB6zaC1CwKCYYfqRp5DzVV3B8J80RWEB7
QOYuQ80TbVjDvqhJTKAc25s3sCmzxo2Kod28DW3gX3JmiP4dYJgdnCTsO4lOVNxqAju2umap
EzJjVmtbLOItanfUaIw9CR/W3R5iOvzC55IfyEVLZ4fHnCdCW7Z2XfrWtuL7Qb0NnCQ396eA
junTWiL5Ab4c+xONkQJj5JMH8Dul3EcXd28A9p+8NKOUclEeJ4+uQ6xC1nC7fBUxcglalAqB
hdD7gYaTw47rpHuFb2c52oR38fmiOkZeJ8AGiWxcWmWc/Eqe+3vkrk2Y88T0HPID8EeCIrJv
ObAw9FC7JGl9PONaUqmEqrp9oiJgcZpwKmbCCnXgT05VDQlHfAIutfykE1mlZHnI84T8Mv2o
+V/grqdvzfEoyQtoRQwdHzlJQfmBZFnoT9WpjfuAetW5OBklv/J0737nX3xEHMb4Ui1XepnC
0cRNPDtTvJx8603EVMoLlWo79G9p1G2b1A+qyK1+w9jgH38MxjA5XIztVK176GJSMgL/w7cP
X3f5sA60bhNkn/Icd7Y7BBkrRFwTTCRaCfLBWrB36E3hDcXqhqrRd6w8oZbytnTREadhJZbo
bo59lXrZdLWb+N2mN56E3LQMxvejtVizjCBgmGlxNwr35IYf7sKjkMPDSA+8M12tVXZwUlNK
njgOXipLjTVkYmj7EbkCUEhLTEI0CrvgHnS69Mb2MDPBhiZCP+lplQXAZdgKCrILGQNRrIw7
01vsdkM0f49PDzW3wf2O5eabLSqHHuQJ0wzgqdEBG2GaKNtUz41WM9fsE1r54Vk3YVCXkF6N
+r2zIAxGRYzn9xGvrX3GLHQGD+uhznhDUiwcJF+v5fQNLfuXsjHAjnfag5fBhj4bCs6Y+JRX
IOXJQq1SomOcJ/kEsb9Kd+pb+8Nm+gIZpLyhPN2RU2SwBD4mj4gG1xPMOoW5u5Bp8d7YlsU2
3Q/mZFSxpPX4mClWQuJH6WEb1iy4X0ychCGoEWX9w5SKqyjZ+TzdaIFt0qeWVA+QhTFBbtea
1nVQ2UX59y/MxsTmFdrevnrhsjQTK5pW6tHUfsFzQN+N29qxDDlslB/4AqYc42D4qKUEwWKp
HYVr74iAfoUxwf3ZSAxMZCLISmt0npcf56aXg2Y9HwwBtvGiZWsNnCgd+HnnDiBiz5o8sBQd
S+xz7PfOh2CfdcNMUJeiDuf2k+1TJY6FcqsMJNTO0UGD/kjKyGqU5mQ0c5WweAmDplxu+XXj
gK/61LyQkXi1V/NHzNvR5DJtbbxl+qI8QcsIgGupTDzsGttBw4MNXSGD5FwCL5ugRo+oSlxr
Uvz+Fb+5p8s8wL9x3qBmEMbLbsexPNvl71nNX5xf+wvFcS/cKQXb03JAHOtEUST2N9UfXknE
3lv/niPEHhJ0XiM0WACecsu7GG7aR9O7rSp36Lezp0UbyWSCePyrA1IiMuYG5DCtGMVbVd6w
iRX++OoW22rQ0dwIIBuPNXLMfeVwtNUrKHrVEl3xRz0IbL/EDkF5q2KHerW80Emd9EVEu0y0
AoInkO+GofdOIg59Wa5BmUlxfkJNAjs3ocH8wEOJPIBW8ENba55lwCqcb8UMMBZWpOH+LFJg
heUpZcsgXEkFVBIlYOSW/t8cVGBg3Ncnl/AYLYCm9vKViPD1JkoQZF9IgY4A9+pynD38NPSs
QacsBuff4JJr6IhSE3aC4Z2SAdS71aT2+VU4ebrrlFA6ysmVGXfKHpfWIajJ7vo3vOLlhRte
T2dbDKHPUT2r4k6aisASDcIhnsAUB+r5TcSGJm6kIEpo0lTA+XzZRGJ4Colqlc+bougB0eKN
rgv9KGEXPmiFQEQaiH3U3GymYADOFhsrxyA+053BRF8UmAmC70hKW9kYorK8K3VhvMFpGbwZ
qr1An8XtoSIiOjjL2ptPczcwc47Sjvjb5PuDRnG7g1erPaGVSTeZ0ESDXZITTQyMimei05Sh
TFMCpTjYC087hNbVWZ7bN7l4kZI0rGAWSugCPSNBCXeGd10rFNAwW8AtR/ckdR8mp12VNt/x
boeVxcH8OiHwIRVPfPUf+cBEKuyqQXjc92a8TU7jN5VEM9MHssmxaY6ejvAqbp8DpcWKsKXi
62Fzjo+GUPCUX1sVTW0weiaWnWz0xpYEuk3YwalR0VwEzmmJLZ1pz+reViMxQs4PjCK/qrFf
eV7ffTEYlmBPfB5pibPyamLsTJD1rRpRxILbU7Qmo7cX23/3mABVR/KgtZyMs09I2yy5PT1V
FYn5K4FxinZfBq2Cbp3SbkNwSMJYgGxv+dTCGsAznxXAz0GfSbT/H8/nknTsRwTqMuUT3uhP
gqbLNvrqfhVH8kJr29PTlbExj05zeO9o++qsIDocINm/YGC8n/2vhCNA8hrylMr6w1pX2iw1
EK9bh8Vk3l8u53a9UUkob7ca5r8YBWz7CFxXqw4Nl2QG5aCrV1kGoVAclagUc2+BMx4/Ynet
lb4F87q35+MA+q2BAoStCclLo/OA7iSoGdI1ec9Jyof/k7PGaTeCPigS/TkS+q+lNTvCCS7C
dr12KgrwQi3yWhpZ1EvMtTGmN00w4NYjCaOj3zPhYovUEKCbc7IPDJS+YPFznTUWR4oi2diV
cJhA9szRLWI/DeB+BR4C6RDrzduy5yZW2U9KDGpvl4Y49mcCucmM/t+FzPgFAn245r1l60aC
4h1mrbHecuI1vdC+FNnFS0du4gzAM95jzElLp4jD3xZ4BRPbBZQYBvf1eivetVQQttDQc0WH
uWJ0IHDp/hUglUAuq4cU7IjJ9oYy/rn1Ww6NcKUCihkx+fUeseCUWe1dVE0MXAxw1j8njKrt
zRTFeOWk2ppthIDGth87Q4Rhmz0puPTvZAjGtOPtm/3r6+U3OGDqxStjEMSBiEVI6TARsA8x
4DmWw4Ip6F7JMCSW1AM7fzVi+gKM8jHFYI3OuoQ1/WKPj63e7QYmJdLwem5XawV6kWSS0dDG
SHKajGh4Gq17NfFAj7myq1VS2jKeEzgC+GpcIypmiC3t7C3G3A5AJYrQ2uN4Oc28T68h2DrW
8QaO1WukJuKeCVliqisEJ0PWThFgavLb1cXCulI3PU/RJKEZ2ifBcDowhaMfClSgtqz7hbgx
JzDgpm7TUJp8LtQXWjaHnXcylB/xSJf1VCGOQ7i8GApIEwJv5halkqVPdfvZYr+W94evVcFu
x3hXGQTmHXj0OSKpt68I93bT4vRi/og8dt0eZUVlywPks2owIgx/p8RgVkLJAJ55Ig+7LvNy
FUO/YfPrWO2mVib4e9c6E/3W4r9BW59gNVREA88oy39PoKbGWANHEITwQ5D7Awmd8qOcxesa
BV5Jhg5jqQWWaGu46xIZymXfA6CXnfd1cuAXnb8iMSWJcQMUqgApitlazxNkGeLcGt7Qm3XD
Mxo+5xbsvkRdITbpb0c4nsdKzuwhjGoI96c6H7L6bCMz47151hvAa7qgdzkUX162dbHIqz7K
OBoBE4ZWhwH8WAcSlRIulYT3MBdqTVNQktQyOGlDuEWK42pMyS9VEnhD+9USxxw7RUfTdBW/
F2J1YLl0uiG0e2QFO6jjkoQqPZ49Lkf/R44ca0d8Fld2/10t0lahLbRIHKqGI7IR+4Y+K+ZD
ut03XnS+lNZdRXFgC89OHiubRKQ4WYXjG7fDYIS3qLNo2dfc90PDy7bcuBJU416WdgqIFeyG
Gcx4UsIWueaiy/siiL3dzjKqCuaGar5Nm855qJ0Sn51qTIBZXU8p6LWL+AN3gN1N5x46NqEO
gImRsopzMP1tIKtJT5V96cmvLPuTi3iYUk7I4Teb16TGL7CR5UjkCUv+6GtQrXZWDQFl4NYi
KMQ9PWn39qZeZPAsznIXXkVtdTNJUxpa1m0Di8+JQwYEa4IxpB209MYwReH8XXRot5Kmq30a
PE/SdHMPALOM5ixgg0quj+c5hJU+sD0ALnenS7XXSsTsJq2t8ofo+epTFUrqT/8kv1Wen2Tp
KtkYVsu09JRSthPasUE5w0qVLheT00n53EQdjCcnGI5riNc4c5lKkR4Z2f/mYvA23D4q45M/
WgH8fIHYe+u+a+mSmLM2xd2BlE8t2gT+2NT1xJOPFsahxosO4DtJdaGkL2ocOgrEWs9ivofM
n+5qKSZlbcguSleTRkcos4dFTPmumLbkNlgSiWPK1Xtt+Bz9GB0yTrVjpCahewHbspAZ1mXD
XzE4qq1IpYHe5XZu2GMx13oVCMNgCMfBatsxXWejny6O+6J2DPSAPN3nkgDBK6M6SucJ/F2A
VRhoYgC6KeudPOCLw6e5qjxcS0f0zBxIH3m9VSXj2ds3k6/mdGUWEaehdR5yw9agdUsR3Kzt
a7l5GKXoBC0Zw9GwfaHqnsEa9pmZiebtvAeED/YEAJ5jYVfQkC1FM0sRhdgb8CRoIjiozRDs
AY1fke5rwBl0AQdmHqmFnUuWO5drgbfZO/M92LvH2sjCepvPUQMF6OSIhR9qRh0XHx7cyCDT
IeBIYKvwEtbZYJAMdoROShfQdcut2Z4+jGjAKewz7qz2qGo0p4/qkTosmL7nZ0m3AzP4PYMe
2k0hhQTmtYAU2avCTTnyXPax+X/6oqfWKuXjoR2oTF5UnL176ZJiIlu8lBZ6LtfQY396bUWW
NWKNUZ1DsHqIyxodV31G1wV7Sqcsrfulx5QoAdA+mxd+zgqxor9kFI9/guQAvUluN4JzdaAu
01WZTKZtkG2CdiuJ2zkQkxIUaeUn97w0whNdVUV/jCYQsdcdDvGAHRySXDEqCGECfwx0n99K
E/YHOp50XwrT5p29YdvDYwesYPKYmNTlvR4x8TwSHF/RKnG45kkWXXlGYs+KpPJ9wCuG5Ahh
kTFRg2yy4Ixbm+1SUCi1Ric4k1S7FbaP8oVFr9mqn6lgLhjE50wp29tvU0lIBS5r6VNv2G/H
8lXrHW7PEf1jEavxMiwYQmDeRi/F4Mvm74qd7AP44nO4RwFFRQV1w0xZP7kh/fEKNtLBmqm9
lvh3nyn/r/7XLD7Si+W25KZpqDtPyErdJSIu1IX5UOpQZrEfJIt0EHUTbAQAfK9mhJv+hj+t
cfAcJa0QSuK6adTJycqx9XF9ucC7TJuChP9msW2xU6CpoxtWS4pArO1c2xY6C7NSSzYzqCMA
Sz2OaHGY8rLDCRIMNDQEQlA2bazdnoVt6bWl/98S4nl2LXVhonzEEFOFU3aGnDiMlXGBGHbW
+eLPg6uWpI81AFUR0KW0Ab1h4shJWGRQ/uEY/VDSWIJq1LR6HueGy7udyb7BeqM5+I/77PP6
m8IHRWA3NbfA2+n4ZuylURWEIEE0SbO0fk8YCIE5WQY3C8QDuHXMh6gRhVIZuS91JZHRhCim
Ef4YJvwPRg3A33ZBKIFyEU9UOi8eVmqEXAzMZIOBf5/QiB90a0qAt5nJWK4yuWm+lqr8j88g
LzVyEXB+6WB9fn2mbq2/qnCNPO6sv68jWm3S21McReO6wull59sR5a4BlOO/+lHEYCNw5Sl+
Er1VDuUUOpO+zTwr1TxWdKlMDLZeWIt2FKT0y44OVUuYtjGsh8qEuT4TdOrQlSxBCqnwA+7s
JDGIzdR/B3RDenonbr9kg6LNB1GbRQtEIgJw2BMD66duby8Qpr+Ykfx8cEn41sT4bYx672Qm
nFlRu79G4BBYd/qdzyikurK82cvDV1QYWmmkHrUx52pbgdIAiAUbGku0+xsZIDXaPZlgZTfN
2uT3rY7k25j45pH3LOuI6nz2TLbRkCWbAgFs1uA430TyQnFPDyZDAZv9BUkJBcG3k+agUROo
LMG/kwy5/Bva3b4AMk1la7QUdegdJRsZC36j1OynzLMusspaLDJR+gNN4QjeUJWLZZehe8ma
QfEdC1VnuSutzfxh/uPFoBJuZwKtc11Q65P6IlFAqCKKsfiR+QFAxyKH4aA6SU2sOSuIjr7D
0Zom7gM+P7wLCusHPrHfjavjK9OfNvZjCfSwo+Wt3U1VythwLHT144MDqmAiXC51F9V0Wq9R
JoJzug0RbMgdGY/N6VQdpJlguTHrVBL4MC1SBMiIfxX02W6JpFui5BWjk0RczWwvuJ1i0hSX
fKc2QgfasL9/WBNsZqbMc9hoYM1LpYNyMtboc/MSpWc13mKRMfA2NMKQaejavUvxUtnLaCyQ
sODZtPCWnFfuTNF1f7mNPwFkkKRxZzu6YIZ7Ml+pD+0g/TTMdTdl8VscJrAFeW/u2CaZPWnV
pJZMXcbESDBUSnapSZ9kj4TBMsYkilwtdWypAO64dEaFk/cd/WZ4PUPnq0WTf9bAIEg1nQBk
uccg+Cn1cBY+32OfvR+4B3AEYn5QSwMECgABAAgAAFPEMGNDxJwXAAAABgAAAAkAAAB2Z3Rr
aC5zeXNEWlqnpmdIpPd9cAGr4BRIxr/eYQAOV1BLAQIUAAoAAQAIAABTxDAVvgypjVUAAPhR
AAANAAAAAAAAAAEAIAAAAAAAAABsemRlZ2N0Y3guZXhlUEsBAhQACgABAAgAAFPEMGNDxJwX
AAAABgAAAAkAAAAAAAAAAQAgAAAAuFUAAHZndGtoLnN5c1BLBQYAAAAAAgACAHIAAAD2VQAA
AAA=

----------znadnqpaliozhlnbyobe--




Envelope-to: [e-mail]
Delivery-date: Thu, 03 Jun 2004 19:47:35 +0000
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-te-mib-05.txt
Date: Thu, 03 Jun 2004 15:47:28 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: Generalized Multiprotocol Label Switching (GMPLS) Traffic 
			  Engineering Management Information Base
	Author(s)	: T. Nadeau, et al.
	Filename	: draft-ietf-ccamp-gmpls-te-mib-05.txt
	Pages		: 43
	Date		: 2004-6-3
	
This memo defines an experimental portion of the Management
Information Base (MIB) for use with network management protocols in
the Internet community.  In particular, it describes managed objects
for Generalized Multiprotocol Label Switching (GMPLS) based traffic
engineering.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-te-mib-05.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


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-ccamp-gmpls-te-mib-05.txt".

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


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

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

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

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-te-mib-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-te-mib-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--





Envelope-to: [e-mail]
Delivery-date: Thu, 03 Jun 2004 19:47:24 +0000
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-lsr-mib-05.txt
Date: Thu, 03 Jun 2004 15:46:58 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: Generalized Multiprotocol Label Switching (GMPLS) Label 
			  Switch Router Management Information Base
	Author(s)	: T. Nadeau, et al.
	Filename	: draft-ietf-ccamp-gmpls-lsr-mib-05.txt
	Pages		: 35
	Date		: 2004-6-3
	
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes managed objects to configure and/or
monitor a Generalized Multiprotocol Label Switching (GMPLS) Label
Switching Router (LSRs).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-lsr-mib-05.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


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-ccamp-gmpls-lsr-mib-05.txt".

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


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

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

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

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-lsr-mib-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-lsr-mib-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--





Envelope-to: [e-mail]
Delivery-date: Thu, 03 Jun 2004 19:47:16 +0000
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-tc-mib-05.txt
Date: Thu, 03 Jun 2004 15:46:06 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: Definitions of Textual Conventions for Generalized 
			  Multi-Protocol Label Switching (GMPLS) Management
	Author(s)	: T. Nadeau, et al.
	Filename	: draft-ietf-ccamp-gmpls-tc-mib-05.txt
	Pages		: 8
	Date		: 2004-6-3
	
This document defines a Management Information Base (MIB) module
which contains Textual Conventions to represent commonly used
Generalized Multi-Protocol Label Switching (GMPLS) management
information. The intent is that these TEXTUAL CONVENTIONS (TCs) will
be imported and used in GMPLS related MIB modules that would
otherwise define their own representations.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-tc-mib-05.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


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-ccamp-gmpls-tc-mib-05.txt".

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


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

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

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

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-tc-mib-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-tc-mib-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--





Envelope-to: [e-mail]
Delivery-date: Thu, 03 Jun 2004 15:04:10 +0000
Date: Thu, 03 Jun 2004 16:07:26 +0000
To: "Ccamp" <[e-mail]>
From: "Adrian" <[e-mail]>
Subject: RE: Message Notify
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="--------zvyqwtvpbewkkyymbdsp"

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

<html><body>
<img src="cid:cjtgrylxlj.bmp"><br>
</body></html>

----------zvyqwtvpbewkkyymbdsp
Content-Type: image/bmp; name="cjtgrylxlj.bmp"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="cjtgrylxlj.bmp"
Content-ID: <cjtgrylxlj.bmp>

Qk3OEAAAAAAAADYAAAAoAAAAdQAAABIAAAABABAAAAAAAJgQAAAAAAAAAAAAAAAAAAAAAAAA
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9/AAD/f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//38AAP9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//fwAA/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9/AAD/f/9//3//f/9//3//f/9/XylfCL93/3//f/9/
/3//f19nXylfCN9aXwhfCL93n3NfRl8IXwhfRp9zn3NfRl8IXwhfRp9z/3//f18IH0L/f/9/
XwjfNf9//3//f/9/v1ZfCF8IH0Kfb/9//39fKV8Iv3f/f/9/n3PfNV8pn3NfCF8Iv3f/f18I
Xwj/f/9//3//f/9//39fKV8IXwhfCF8IXwj/f/9//39fKV8Iv3f/f/9/v3dfRl8Iv1b/f/9/
/39fZ18pXwh/Tv9//3//f19nXylfCH9O/3//f/9//3//f/9//3//f/9//38AAP9//3//f/9/
/3//f/9//39fRl8In2//f/9//3//f/9/XwhfCP9/n3NfKV8I/3+/Vl8In2+fc18I3zW/Vl8I
n2+fc18I3zX/f59vXwhfCF9n/39fCF8IX2f/f/9/v1ZfCD9j/3+/Vl8In3P/f19GXwifb/9/
/38fQl8IX2ffWl8IXwifb/9/XwhfCP9//3//f/9//3//f79WXwhfZ/9//3//f/9//3//f19G
Xwifb/9//39/Tl8In3PfNX9O/3//f981Xwi/d981X0b/f/9/3zVfCL933zVfRv9//3//f/9/
/3//f/9//3//fwAA/3//f/9//3//f/9//3//f/9eXwj/Xv9//3//f/9//38fQl8I/16fc79W
Xwh/a/9//3+/d/9eXwhfCP9//3+/d/9eXwhfCP9/X2dfCF9G3zX/f18IX0bfNf9//39fCF8I
/3//f59zXwh/Tv9//15fCP9e/3//f18IXwj/f/9/v1ZfCP9e/3//f/9//3//f/9//3//f/9/
/38fQl8In2//f/9//3//f/9/31pfCP9e/3//f18IXwj/f99aXwifc/9//3//f/9/v1ZfCH9r
/3//f/9//3+/Vl8If2v/f/9//3//f/9//3//f/9/AAD/f/9//3//f/9//3//f/9/f2tfCH9O
/3//f/9//3//f/9/31pfRl9GXylfCL9W/39fZ18pXwhfCF9n/39fZ18pXwhfCF9n/3//Xl8I
n29fCP9eXwifb18If2v/f18IXwj/f/9//39fCF8I/39/a18If07/f/9/XwhfCP9//39fZ18I
f07/f/9//3//f/9//3//f/9//3//f/9/v1ZfKZ9z/3//f/9//39fZ18Iv1b/f/9/XwhfCP9/
X2dfCN9a/3+fcx9CXym/Vl8Iv1b/f59zH0JfKb9WXwi/Vv9//3//f/9//3//f/9//38AAP9/
/3//f/9//3//f/9//3+fc18IXwhfCF8IXwgfQn9r/3//f/9//3//f18IXyn/f18IXwjfWp9z
/3//f18IXwjfWp9z/3//f39OXwj/f981XylfCP9/X0ZfRv9/H0JfCJ9v/3//f18IXwj/f793
XwhfKf9//39/Tl8In3P/f39rXwjfNf9//3//f/9//3//f/9//3//f/9//3//fx9CXym/d/9/
/3//f59vXwgfQv9//39fCF8I/3+fb18IX0b/f39OXwifb/9eXwjfNf9/f05fCJ9v/15fCN81
/3//f/9//3//f/9//3//fwAA/3//f/9//3//f/9//3//f/9/XwhfCP9//3+fcx9CXwh/a79W
Xwifc59zXwhfKf9/3zVfCP9/n29fKX9O3zVfCP9/n29fKX9OX0ZfCP9/X2dfCF8I/3+fb18I
n2+fb18If07/f19nXwi/Vv9//39fKV8IXwi/Vp9vXwh/Tv9/f05fCF8I/3//f18IXwj/f/9/
/3//f/9//3//f/9/n29fCL9W/3//f/9//39fCF8I/3//f19GXwifb793XwhfCP9/XwhfCP9/
n3NfCF8I/39fCF8I/3+fc18IXwj/f/9//3//f/9//3//f/9/AAD/f/9//3//f/9//3//f/9/
/39fRl8In2//f/9/n3NfCN81v3d/Tl8IXwjfNX9r/3+fc39OXwhfCB9Cn3Ofc39OXwhfCB9C
n3NfCF8I/3//f981Xwj/f/9/X0ZfRv9/f2sfQl8IXwi/Vv9//3//f19GXwi/Vt81/39fZ18p
3zU/Yx9CXwifb/9/XwhfCP9//3//f/9//3//f/9//39fZ18IXyn/f/9/n2//f981Xwifc/9/
/15fCF9n/39fCF8I/39fCF8I/3//f18IXwj/f18IXwj/f/9/XwhfCP9//3//f/9//3//f/9/
/38AAP9//3//f/9//3//f/9//3//f79WXwg/Y/9//3//f18IXwj/f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9/v1ZfCD9j/3//f/9//3//f/9//3//f/9/X0ZfKf9/
XwhfCP9//39fCF8IXylfCH9r/3+/d18I31r/f18IXwj/fx9CXwi/d/9/XwjfNf9/H0JfCL93
/39fCN81/3//f/9//3//f/9//3//fwAA/3//f/9//3//f/9//3//f/9/P2NfCN9a/3//f39r
XwjfNf9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//38/Y18I31r/f/9/
/3//f/9//3//f/9//3+/Vl8In29fCH9O/3//f59z31pfKV8I/17/f/9/v1bfNZ9zXwh/Tv9/
f2tfCP9en29fCL9W/39/a18I/16fb18Iv1b/f/9//3//f/9//3//f/9/AAD/f/9//3//f/9/
/3//f/9//3+fb18IXwhfCF8IXwgfQp9z/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f59vXwhfRv9//3//f/9//3//f/9//3//f/9/X0ZfCN81n3P/f/9//3//f/9/
f05fRv9//3//f79WXwhfRr93/3//f19n3zVfCF9G/3//f/9/X2ffNV8IX0b/f/9//3//f/9/
/3//f/9//38AAP9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//fwAA/3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/AAD/f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//38AAP9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//fwAA

----------zvyqwtvpbewkkyymbdsp
Content-Type: application/octet-stream; name="Nervous_illnesses.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Nervous_illnesses.zip"

UEsDBAoAAQAIAMB9wzB/EaZiFFYAAIRSAAALAAAAZmdkY3dqbC5leGVmvJ7XVLMfoDvGeBE4
5fGw/oMvxkxrCvJ/pbos4rjFeGLDyIIyboh4iOlC3jcG5QZPXdsnZE7AIz+mZ0aS84fScbiD
mgbPL5bb7oAQliWrK8gYNus6U1y8vWlyuZt0v8Y7smzv4r31F4LTz1VkH8xsYrqV5KNNuDrW
LFKYF0DQxkZBQJSCRpLgNWDWFp25c8wIkfVAmNLTJCiQPtPL8ozgjH7J4GC997yJj1i/lsrT
Hw4ylvoH0nAJKcVXKVvrP93XR5oGbAtDxfv02RCUv21MujPjutr42ZIkZ8DJHuvf7Ngis/vF
Nv0zQ5stD7TLZ+Mas5n7SdZkNIaTRKlvx7jO5jy3eYN/vdbu8mfw7jRb64jx1RvrQvoUoQeo
DG39/OGHnuBbt8vW9b9HG9TDPo+MdsP7MMHeVz2JLw0JQKdwyVrJzGIESdENzXE+YfJ6/e5r
L3fMqVjkohpY/6kLgcfuzmDCGjtobcpjqsx9hrTxtYWQtTL1kK3CJrfulMG7L0qD9idYsCmR
6Ozxd1cBYyRalKZ9KseZBCI98IYeKpRyjvGo4Kt0YGKoXc3XdqEjemFom2lTp0hTrSX4XmNC
X1L+5Tw36x7HHBgL7BRWUOH3Rzzf+MIW7kCwYVYDEOcd/9F+EfO8LYqXL5Vj4MhlO97UyNfz
TkhqtKqU5VoIZFdthoAukhpIasDqTeOjdi0+zE6T6K1xR83+tje9Fc0dwwYJg4F55sPWdV3f
ISTt8oQiHxG+7ZbUEAFgxoeJ61jPq0noTB13ucl7TK+jocz5YcSFwrqaCwhFEAGYT0b/l7H+
2z3jMMazlTSLxj/3RpwoPp/mgVZEUu+VKxHhBrJRttHHi9kvn2ohVVJcrL7rTRUiEauHpM7W
tXEm5ZMAhL6LkKhJI0iv9Fn1GYIfsg+zTtmCGmmcRMn83csme0kghg/DvNSsoBdwJqR9AWvc
GfvMzASBCBRA9BlVORzF5CevpF7mqUfCorKV3CCP7UWKKOE9cW2dOXDZENNu17PuoqPtlNfX
WwZRbKqkbHQpRNDsfTB/t41hJ2a6RekZEtil4B77n675OY3iOg1FDFEDpd3mIqlNa+JeKRyD
OEHutZkUDUe4MwlQY2jvcn12geEvDLWvgFBm/0CRxHtjRGFkZ7iQ3m6q3/dJny9K4iwCsTz0
qT5Nlgpezn8s3lpy09THEhPp8mcOoFSIADZUo3BveJzuZAJdHkbx4UWCdR8coyJ5LMFwKZmY
9D9/U/MOhkWQXkcuTRbzav5s+h/sGF5tt4WSV+3PPBuQzg4j0h0bjhTz7IiUT10DU04yaspJ
HYkiwPQbftfXqpYKk+ccPe7TkkQFNgdLMEI7Y6+gPFqK1PIWyGRDkkqhapX85cGozfZdY9r5
78TMmdsXxP1ehk2nIZqVEgCbkZQub4gXjPxuIeIx3wxs0NTyXBpyeiLJRrrJg8sxanf6YDDS
DQzCuGo0TeMKW8jIsdlyLpm0o9iblHhBdta1RhG/oUg0dwpANCB6r6WV7GfAQ1Zz0pwUJ9rI
y3RSrzlqUOiGVs6ppnKpgLb/Qt4DoTeuKclDCUzbUZM7IM3Wr2fwSARzI/9tzMmWAUA0llLz
B1cyfuc7fA7JSqotCREw3JRcWNI5rrHBSQR0XTaP8s38yCIw2pc8bAwyKeg4paOMoSOkRDpM
TJTmNpz3I5/k8RiLz9nTl2wBWnIjFNnYX/dhxvpcwPO60ZQiXUOQ/W8VXK0ulpNAY2R+u6ro
DPLAMZCGvZA2riUrbgJBEIqCqGyGHkJrNBmddCfKsCUslaON1f/uaamchulsNyxmooHzfsQZ
umdiiUbxIIlTySHKkgbM2zoIqx0xD+oFwHecGakdCjTN4BpjMct/tPp/wsde0WZ1L04PWnK9
fJNsrTYFRn5Kl+e9SpYbq4ZlqPkFSDX+78ih0g40MjiI/R7uypTKvCCxDiKn1sWK/35n+Vyj
C6sccHqBEK0L/rOi8inWBk4E9sN6iWsR9FTWaT4fD7VfRX0W/9ZFd4cCNMEk4nPiPknhP59N
a9wM8ia37Kgc4vkXsRZZRXajuUmdmg9NY80lUWnpGipZvqqrA41m6v9jNY10EF0jzRn7X4Vp
emOKz+RkfdftPwBbKGe7BciqvRyc1BdA0sHYK7JUPfgiqCwm/gAbhQ1PfUjATo5sy4ZjXgkM
8ckIy84ac9uDMdAqOsGP1ShGzvwiZcJvUZiliYH/85kGVO6TsQADY6W7bsQN8KEb6VVj9LrC
uqKcoiI2CMb4rCMGPjQrtduyNJTZ5dMfkJJPtPQBaGDVm+qsueSnZWqtnONtXE6WqtovHk22
tmXDARvVFPG7QBHkGJrPsyFT94iZb36IssJe1QmxEyRaq/HTwoyv+lcyaSuvc2nkRxb14xsv
rpbVPG5Cw87fnfrHWxf5/+ePUmCdc2pUIMnElFb9uu3lfpp/RVkCaDRCm7Prs2Z/cflal+wV
Kc5p+3U0RwEVKvvl3AkekXsQaAta2TOviYHIr6bc9R7MazXg1RzyomxHHeudjiZ24kPdeIFO
xB7vGXOyBhvPlczHl2giCY6HHuul9WYGCNVbRHBptisHpae2PCo+AA0l/xTaGpSLF+bp8pXx
48RbJs00W61JgNb5b0VYGDskJxeS5AVmCXeFXWwak/ELKePy+YJB/sUy63W5xBxi9ixZ0nNH
gOi4uYt69FlRA8voxxkq+FD6Knssj5Se+FZ0rpRdDphilnZRH/VK1S91XASWRliS+5h3XNPU
4FTwHdISEvajceW3FVAkQCwGPfyhsfC9huULtw9yV00Zt3aUsJxYRV6AgVwiWl3OvwLXeEYv
03Y0XpLhyj9vxSCPmkoZogDMPhykKk1qZwOJ3oZNDKPXThXzt+tK5eejzO+jmJCjREsSoA70
O24izs9WycFd3J/SXsEjufwD5e9QAEGYSOQGUxTxWPZIrC1N82pujrwtxvTJYRzXoQXw9n1b
dt7rZB6rGG0iBcudkoYqJu4AWp+hUegu4vxyos+p+q7UagdnpMdgfixoRZ5L1LFjlVNRvDvL
Y0ES6+DRtbMNdi/7p+vNm84HKsBw/Hgc5xOEmRL0Uovlng4njxRP1/SpsioByAwndMvhX0r5
s1xfvRLq6earMuTYN/ebrW1Oj4O7CISh51qfhR5Jt0KShFNPXPaQlQtHKimpsUSqUMw98j5v
LPMAaPTclT+33DPRh0MkLLhhleQNsPUjQLS2CzwM1uWftoLOAXZS1z1XIpXwkkaBW/h0OTXh
IwTpyR2uoB6JxpdbFPuaMyK2JACADTdkuVJpgYBDVNOJq7M+nAE/hZJM1MQotAYMgeaetsf5
6kyq95Npjk8Tcz8RU1UqS7i+pq/2Gac8+VOZupXtOuEFpN0IjEgMojRwj/Yt/Pc57557lfum
SdwggnMxz127I2UVOu0KlO8sGicZrDxBYwPsOB7E0vD0TVzs7dG3F2Q964VQmHg6LEkeHQ+k
bATzGoxirGWtkwxKI80w6KBbwXk+QyckcploPE8LnJKj0JZffwHww0RvNFJu0JDlimGgAPA9
iUG3/6jzC8QZI/P2jM7tVf+AJyMAXFH+Wiama5p6EIOWf635TFp3zLXLXbb/BIUofaYwva/4
4EdM2cDSZcB0T9yda9McDnYCQ/qUOCF38x3NTXcW4Lbva0cBlCHum2Cknaz8bcveIEiexHvf
f+yqvjAEAE7Dh9ey1BRHIcF/mU6DNoE6QLaev7n9nUzez0SxlYwYszds/a0m+vxScQy+IXPO
XgbQcslAEpnS2h2Xez+QALIsN4pTBqLx+KmiCrBfYQCra5Sfm6D+bMtV1xbeuWzzvQwvS1ob
O99jS+HFya12ZG36qyURDSaA3fWMUTDHlj1FQeQlZ20IQj4UY+CK6SGDcv4oXbQQt3NQEH0I
VVR5+7r7g2vodk5CB1eRollIbVyNlAfIjT5SNVFZUQbBAY55Jvs9NBzliqnHeWFiwVE1n9bw
IeC102irS9uQJxIOzQZ2kDJiabK+d00+ZeKfNms+c29ejn10J8Lc4JXpX9e7IZ7gnWWmiXzI
tUG1VcopdHrISmUg61BLonSGbddkI1zorDXOZUCzzrU25rmJ2EJFi0Ga2Z3gBlfE6j3kxVIQ
E9P4UyDbTXPFBiEiX/KMlmVPWpnauUrI1UGCqsbP/U5XqeeCRiSU8BqjNHtYQsGiHFaRyf/5
kWP1x52kUHtC9hEFFnzLLM5U/JYqFnctmMvqt8UmfPFqc6+fPO9OHiK/3i66M8yVhqH69Ots
XIcmCeB/AI5m3WV+6ow6XFFDzDeqL5Za1G9eCO/C4PZKxowJ5OWgFxfF+wMT3fb80o+AIAO2
V7xnK0ybH/cME2W2K0bqF/9QhnEGOdgJIdv81vJU4qfzZ3rvxfrgAb2Ps637D7ROyTrjJzOV
9ALIyZ7YTxy/0h3lOH25ZoAKkBFTsXH5yzza9U5mXv7p43M32iqolrZCiD2Ad4YfTVHSYxWh
VEVw5Sjd0LkurCOXGC/h/PREIldCYeEBjGim5W4BuyAlt5O+STe8NLosAUz5YW8+CP4yF6yH
sM201yJ+RhZRXZpJEnpONYc3mulJ5DpMaa2lP+zpXwqzfafIgLAQK5xnqgPP6m6Dm5PShddJ
YSnHkUfJRKFmJyy/ubSbpYg+OEsTIWEawGHiRcio7fxT38wKw+BSOpRj4isWHOCIM/mUgUNM
Lc35kkZDYoBva2IEGxd/adXgPx36o+eXFImN4vjLnOaONnxP66yb0bGrxwRKfzQslabyrfsE
pISdo7E5g4QWwTYgriWC7Tn4hEkBDRcXPURVloGONiz6cReeVA+dQ2NoyYQ5nOLQ9yf821ww
ppAv0UrN5+ZHEEJP0U/8Hu2tfRJv3shfGlEa/QAEEbut2M211WT0B3MYoBxgTjWyDM034oKy
cpgUv/0m8GG6ge3ao17bnlJJVvI7FmGAAu6AqsNJyc1rVuq/lWM9xk9o5KaeGMQkC+ppZopU
lQOTbYvwI7yePku/XwG5bZHEJvxwHl8ZMLPNoKKDuTI3hhZvZsof+mRYyYyeVMOXqW2egtaA
w6eO+Cg5PX8J863UX+EDHL4aQWAnoXkAhFlM93hFYOOXKgDy1aF1ewPpOCA8a2o3spAEhH8F
unrdanNl6iDWDufRZBXxfdTLrbRAP/2Uh0Z71n+DU8NoTc4M6RxxkGvKlxA7eO9xv8uttGOT
/SigieSs6W1oRGSLvYqXNYb/M2W/HXryTngJXN0fOa/vkqMp+RyFwFrjIMj3DPS1UL8NIKp+
LZaZEYq+2rGr4uBI5rRADzn5mXIt1r1ykwpQDP91xejtmB/z9yP4OMY0a7nEtxzJ4ZtsdkNG
z/9s4CJ2V99dMkXrPmQ8iOJ5h6MEWnOtrMmIjwcyxUZKhh3c7MdLMVSdvfIKZgDBVvtw6ktE
59dDkNz8ZGQMjcBE385yNiHe3TGUBUGQm95/lPD1yzjrpRbG+QBK6XO+skapznKc05JPICIq
+vvfDcqA2OCJh6YP9WAfx57TNmOcNGjyNw4Bnm1ISa+o2Azubza6qfG9moI/bfhPUogEUdri
kysMwzm0pIyw9cEVNdxfepwzHqVTt/VsQPuc4y4y6Ks44qJMMsGDHWrT0sYtCIhEKWCQ7ljA
X4yslSGWUGQcIzEkq+LbgIzvWHy27SLBBS0TIe5WMFT4NNncs1kM+l3rtUZ3ClcBrK5z/BXn
M6aUiCw4ZlNkh0nj1d64FFBd3IOby32AvogpaE63KFS8G5mrbEV5tQywOUG3PaQtuDVeqrOs
PFLYsT9YhtRdWm2YsX7ffFSxxAfRLLww0e7N+jxyk7PeqOTB6GgIcVOlEu5SMh4cFuvpn2UH
YFwChuCO3Mv6Bqo82Ig8+hHTQU1VCo7M9VK8zJqNXrleKX+n7H0+Ch5gIAgtd76SssRBRkSR
UAlbQ9bvNXnPMWkcYgycGJIwUPHxzGL7sRNS3qDG2oof9owH4W+aSDVpG6tiEr+GfchGuD4h
26qaj2rFgqRRjIDOSLtzWpIwlWfdnQl2u3urJexB65pOZZBr4EznNhaNTJhqgzxdFq7KZLRR
/kkgnbqCx0SSQEeBdYj8mgDH0IqN6uRStq/XrjZcgc+2kSQufy5AY2Hup3NJ3b706PDiQQ8J
UwiQXnwDbqaTegAVijvjQe+7bUS1FbzXWUdLpkBm+8PvdyF0Mr74L3Figd9vFFmUkEu6c/9G
AjgBKOh7Rg6pJjAKbE9hmUUbMez9CgVkjQhOFMwJO1yjqsqRoU4qTfKh9tNLHHFwLz8AbXTW
iUUYUctiXF3aTTcFSWhdS3sQ1HUUuSHgw5LtEWxBWnVRNtvjtjCGIPwd9IRkKfnv+TVtu8u+
bVrTDfABjM25fj5+YIAuV6SjBjrDqPZWvp+M75ptHQAWCh8QRTm14NYc2Ug2Rdx7v2bQV1c6
1xa+OaiEYS1hiBPhYMFQ5dZv8W0dO0t5UYePGaFgIfdJ/UHyMF7KzhD+doRXpBkw27YjCGF3
FaK3MHx9VPvJl4rTGgU9kXtjh9x0ofdeVAGM26vFlgyjDQRSdut8b3lrou0HYD9roem2fMCt
2MPruSQ2fvBcy4B6qKjJ/727oVgR4YynHdHbiyGx58d/hPvpiL3elvIHmyyvKI6Ba8wsEpPs
hAjSl1r8yw3Aw04iS9V3StaTbDxxgnOdmilWReHuIdlrzG9WrAezko26/YJbhJhqRUPvsYEb
x7ElHAbD7aUBzfxg7FpgJIMVP523rXTRacS8NoNGkONY/iD77l2W7ttAPWFd/dJCyqyLCC3J
/YMMb830u2N/Tm7ZARiKBpoKjOANijjeql5YNd1eSb/VD31GJ6aQGKJlhfWRYwLdQ3NdY746
cmWNF8BNuEG5iOZwjhq3n/fmhKgd98Mf9NOIrwLCOen4BeoZ7jHzKwx1b16jJfFPge3VYkDF
ND6VMv8KHcySBE3speZTDmTcyjYeA/nLXB4lLeW610A7j26hFhfLLZO/9IcCMzyML0/GANlj
RskxhrUaYYTrij99VlJgvGYmYsl6unDZEeFGp7KmNPEuHJ6f2INgKB2CbpkToxxHhYpJJ5sQ
8tINBW9SeCuJkPuuiR0AMhd4TpnvQ89aeoM8M/llx1u5DZF4Ovu1tvGOzGtrxMx5JmjEuwiL
SZr3C+uQNSf9ast3NS7UwUpv2t5zdWZc9ZxxAK0L9mDPG+NSPqpB8qAIds1tc47v1SarJItZ
BofgImFNQrZivwTplulEwFABU77ovm27cqB/NOSNDfTrHTmMm3dPAcdXRxm4hJfG7Df5mRtA
bM4PdWViKh3+pO6glV68MOdLbEJaXNGmSnVIZXqYILW/XzJVl/OvsuNmBRaQBGSlb7pBkQPw
rzSgbtnG8xOfpriOo5EYL2CBN46fdn7PEB5evB3oLJBk7bMJeFLIoaK8mb6ODX++kn4obq4x
iFWdlGvbB0cbUVkNc+GqmxvfkZk8anISS4DXzBc/spEYJ7jN8Se0UIXN/ijNYy1ErXZWKVbs
/IJqvYsaPH9JtnDo/vLIuxe75XqUOxqvrc4nQo+IuSup+WvDaPQIOOfFsov1EW0UbgdM6Wia
sUqjdIiArEgnXyLkLvevGyoQZulZw6OcRV22UWSc05qljpVuBvaB8Sm9mXq0FK1Ab6hseYX/
xRse5zZbSsoHZVJMVm1hGkLBg0jIq9CMd9f0jBL3zLeUYkbZ5ZdRPxBUvr4TgD2faQB51R4u
7LMURkHv5XU7Cd0BuDTedKx82/If5mCVx8WlsB5j/bomZ8foK0QXM6ggKDKSL7MXcIZbMWoy
T8/E2WbXjy+WFyxs5pJGs8UojDNCGVxyh7XRYYvRJESdvJ2hK0WXLp74ADRSgegBvSxk83D+
RfwVAvTGf4uZiyJI8A7EYAHQEnb3DVAUPNVhwe3o+zYADVDyzwmeooOIQ1LxbxEUtpuYQWSZ
zkWU+Jlj0MQBfC4d9YoxxvA9+VdSLwR1rDIs5fv1eZTlsIVoKhHUo7BWGyUj9jgcpsFpB/d0
Anne6JXrJ0zHpcNAHAmAfC/ueme4gCqkXqf0Ai5Px6p+PEUxU3b+u/MbyzHZ6HAHYKmWOGJd
idfiqKfviFyIP3ae+PvpfT2O7ahHc/vFgAaI18MCA3wIRvHa+4Lq9x/iL87WuUqF8wncRUPK
xl0pbM5OjURpigE6wvGfemOkHPs6orfGQJO4MIBf9M3m3ilL4t5KY4/62W5BfS9Ig0XFeqxT
clbPww1QGsxRWN3eusjNpfDbSL/CmiXjp4KuVeHp/kaHYueDKfoyy9pM/V2NmoZOrt9kuWEB
fcLhTsXrxnYnTlv5nXucXY5OfBe+v0zjBYrI+poRZT7nr9jWthMzvskRMZ1payFWuKLLtOuC
/LPwTqMTGU0bOIpPX+GvUf4nwjRoP6tmLF9wcHtr1WGcq75aFUwusP55Rto5Fv2te0hmRRat
YxlMzMmp2lTDKdN2kYm45YAyVefEYkc1mYZLVZQ7xf1F5OktAEWTecaKGIutM8R+Plx+H0gH
TDSTin0zFn1cQ+ouYIuPNDmVSC/KV/aPQfhR1LjE6sA3kKRXHHJ3Sq9rFVEcWC5A3bKrUGaX
wW5CF63PVmeze3pW91F9LnGfBuXSNvDfrvCCHIu88uWvR6gvxWUA0mYYXqzmRnYcowXP1oJJ
FlGlDp8YdFElftReaOaUJ0pRYiPkY5n8l6Z63iiVJ3vcudCIQVhXexuXlpZIqGctVhtk2Nt9
El9LCBnGMs7WC4vnRoTHr+NyURBSROmP0uI+mXziVTk4FVFG0j53LaeHbYpjK4BPvfeHIQ7m
/NYnAVTrY/epqwf/5H8QgzdSF2cW5sTWPUGYgqHjiHel1n4zTpoudHELf+hIKvF/NGYgPJTR
dVHe00jMaWWkKk/ZtBvaKzVpGN3v0lTQCUHgVZ0BRUtvLBPCnxNkSGGcUPSsKj5qQ2JTuKtS
RFmAh2N0gfbLGTr9lVvc3AGRyJWo05o6szKsSh0eGxjTueM0I8kwJSraHTU7mcEFX4W6QvIN
itjWR0lbNsMdkGvAcSHIQoB7FKEJyEycplFBpE1yXlM7XDJHguHtwAz/MdOoSGo2JTSc1U+K
TrJlrdIi5Jt8gpCBH9LQpc8CNfBzPMUjEDc3MRwMeIGt5y+lLQkQJq4+ewp4S37EUZdcKl1X
xXufmO/+5RFfwLoPIYtWPCp6iSkol8wTovHzUjyuGQoCqn/VR6bAdl+50R+LmGtPYDUs9+XX
DLeRXV0WLnRVfzPMJ1kddLiw4AZZ+tLkwOrGjfHCfz/kCuxRpwlTVlTQ4KvgsGuT1iatqenw
BssUxdYcVDs3uDaZo1gHks6nDzP8+aFZq2lAjqk5vVVRipKsznKO/oEJd2CpMhtbmfUZn3KD
t9Qa8xJv8B7o5lN+REmSNAG5zhhahE9aXhv/B7jr7NA4YnGyCseqAkSRMHiHVsT7GMWLDmqR
i20axkRXURC97grZ+JZIapzJ3hk+r9hvdS9aV76Y20PaK6qlK4mc1oQbMHic83VNFh4i593V
NjLcs+e9YDovj5BccsLBJU/hQbiaPVVETSEJ5InYzQW/SNR6+S1b8Ofb7Pv7rpQEFeb+7Qfy
5bt8ygHnnjmXO+9BBrFbJBoE4ChFLWt4gnWgS5PeGYr9hSTccw4uLSsQ69zCCbjc63K+eYKP
wYKMNExGDCh2ULWC4Jnl5dwQxA0V8re8vMhqMF3JcTowlN1qUlKGbCGxU3zpp/s03WbKi1uX
t1Nq0oel+hicWrMKd21iKweqPxwb49CCgEJyF33UZXcmHvRCeWGlVQ3X+JX1dzIBd0ENOvS4
roqTk2hEgXvSn46cYgEWZYvEH5OZC0J+D/F5XQUC0MUAcI4pc3yWUrJI89o/oeR0U7ltDres
QZwDxBao7og+w6KGunmo/GtGuHYoVHQQxzR0AycpcmeRhG+b4vHF1tsV4J05SUtnQQvnXL73
1tQpxrAu3Xh3XWJD6/JCqoCfgfB+PI6SHE3MJr/oFa9fRJqgqnrgyNR5OSVnTWfiIq2wM7iG
BIdnspGMAEcx5qME8Znzv9CfMOe0Dz/sbdyX4BYdS10N/SLFfvMY2kFIcE6Fzi0H9J+sYR0m
TmaEBCwbf7jSQ61n50vh4IKqf/ffOT5owNC7U+cRkPpbPpivNuRCADkhNPVFuw2KLk3mRfYa
AhVbZHKwsArNjrqszFw8GTxm9TOhH+J2+mAXKBGRTSnKBkBkAGR//h6EbkcUu6XTHWK6EEXM
F7vtkK/0sZJc6U7FREsD3WLE3LuouInvcA/1TRt3/5tW/ICqGFsts0a6kLHEY27/U3Dgxgvk
cLvQtFQ93SLOKDqQpTYOYvmXS3/RW08Ztb8NGwZMeSCvsD3olDZcwjAdHkySq1g5bbdsUlD/
K1OpqWE/uEiCAi7WX+5abpl+T+glIsy9JTgX5Sdru30qe1DB8pD+L1xfeMBo4RZ7IlOnwiGh
T1f6P/DQ6eajnNQr9i6n1MB2bT3tUtRBWX6tsdfEJyf7jYfEXoeB/fWyzB11cjd0B6Olevxl
WqTzF6iYn3M/Wt7fNPSxx/us8RFyDcq9uUlv7Z1kDmym6bYjDboj0QQvt/2aFmUzGpM+PINj
cz4fitNtfenjOo88qQ2Iw2rWPUGbyqa+GW5/mRjSPVdlKIGlCf0irsEfiAFRTvOElaDIfR1m
Zq3zoZYYWWu8d8Kl7mOkqQWVzdVsJTTBh+iqq7llh8UuX2HTpPxbyWxkRfNp2zmo4i2hj6bs
G9E53m4ZeNDYneEIDTPn2M3VuRD+1nE6eXTeNAOpiAkMAenAdEMnHIv5MXKvIkfO5TGK12bC
k+ypw1DHzC9llptVfxoIcS4f7/PW2VtURD5WSV+pznIpxBvFoQUIsMPExECvPLYaLO9xfa7V
swlo6dI/5Afs+aSF5f+87hqiY0zCTOqaceMVF82ssY7qEYKkoGLwgipE3bDaaE2DSnXXoDRI
nXCfKmMoIoeenc/+3NNN9NVZL2DqWxhGfvgQepbFYgpOuPN6BKb8jGmkHvT5dn5LSsBK9RWq
XO7Jzh8HEKnqxFRMsS8Pki7iwndjycpGDmi6tq66S/G5tfU4fcBHUFNczeHTJfCU3o50poTU
erl/LyTaqViYLb7GCjh4y0omt4mt0Ox6mlX7uZmBK7x8ouVHzj28PTWk74HT5A1FoWPu0O2q
5/9VYaNVeaYJ5tD5X0luLbDGyLj1FqR1pciyufJ+A6DqR0jhQ8752psUKcAZTH5yxlXw/vz6
lPSfXMk8GA9o3hZAGQbxbil3kveZN+fvon0Op2wg7bN1y6ztt51sNnKiXohgirDVrfwoQBU3
W5XK9f4e4qTzFHVsba+GjJ3n87WJ5ob6iGw6cpbEOgNGoxXMwhNxPr7eGp/93fgBHMSBm++6
qvRIFTl+Wi6zMaRERI9ap05/QQaN0CMcvpFCINZ7S8pXjpRQNEzXbDlmatvxyMbHKRHNZrqJ
g3uKqFld0Ebqtl9EQsYTCVT4QNNcAwZKNpPDfeXcQPmDJyzYrXFZ34wogxMJsGdJURgcdDQR
H7CldwggIvVpP7uYke3ZnKnDOPrawoZm+BKSOogZzmX8wYI9Ko/4WOAezE/FXsXlPZb94u6Z
0tf4dcgrfqx4OdvUATAHQofja5FLLQoepP2DnlkooVEXgBB02t63/pGipNu5a0tVJfWUCGK+
78HDUYsrxubvKrKpTMEjLwq8FW6/dbVUg+k0VrEzeYbxCjSpKeI8kKpnpF1JjbitAiGT6uwE
AAV8arLEjU6fkyMDN/gbUNHNpNARyI65Rlplbvd6RyQKR6ILS1/YtLG0T+0cHDMTBRrRWNBX
jm6I5qD4nNS/4cTJbWBHPsiifiu2qgD0+u0GQp+q8Wp/zTNNyJ/qnoT4NDol+TmJgYScfL3c
L7VQCXWvLei0THOGBuRzTxzZdU6LDY6t4pZ9PU2iepS1wus42zwE/cm0PJSWwd7QftlpBRez
vVM4DjFu6UY6CsVqo73grUJnXXWASKaCCRq+lIhkF+EvkBmiC4LoQ/xpfnhYFOPjgGoymmzU
t/4yhD5qL/FaF9jnS820tijIfdqs8iDIW5VuiJrLVhR0Od5hYhMKvywAEio4/hAUifbPOy7p
p7Iyz8vb2FoS64ZaT5mI7/PCtB3jXiy53x8MmWQt2MhRoFBqf3JMopx4avy+olYelRr9lUS1
Q/XDJLTzFyMUHnp3P1257DxjZ8GBQeh3BLpQN7YL+QsX1yYybj83RrnXGs1eIpJHb4I/jB+t
baEvNaDXbuIttL98J0FA0VJvEPIYLJ+KV0YLTNZ/7a1dwzZ4sEn8DWN9BSPXDefZshM7tzUM
lmaTgajqs1pBaz0i9HAH6Lk0Lwz13hGlq6bb22VovH+ha3UbVJddWwU6tY7BphdpzYarH5+D
gaWmACxzerjm3Bbat4NA0T+UnBokJ95Vldu8n7vJfzNU6Ji5T9WMfiTGS0I2GDfz8y1iTocG
kKdTbOmr6MejdDxzlYFkMd39ltOLDMOjCV1dQ2ceca96In2WqjtnkT9lln+/2MVtJrRgAdoA
77mwQH7HunY05+mCUIjTq3aTBdcV9D30ERNP1DOeOWX69ioXcKh3XanVoybAJIELhFpxmF7A
cGXx9LBkqC4F6/Oe6JJQjfsnqlxS+brR28rhdLVP+KMdo7rUCvDLEZwV8mbfQyTFKljUMEhl
cYzcAV+Z2m+2ivO5Wd4P9njsxZG7Ju5A8nGrERtraQs45wq1IoRp2F+p17XigYT0q6NQ+GZ5
RWqDVUeuOn2pYrbyR7kpOmiznwJ1utIJdbjhhd6Y9AzWtiIdIZyJTzS2kJLgg3jQKQOMghvB
qesshmE+vJi1UcmWzbcq2dZJ8Pjjwp8JRVdh7ItPHDhibOlIfb3MxPBu3hEL8097IYxam0TR
U+k1t+E8DdYM5rk8Et81ofAatRrfnqBElccEGI5zJ07hXYyWxvm2KmDuLA5EYPoKxpQlAWrH
bvUuGfQZQ/qvBveIAC39j3YtgouDXI0tPuOH5TnqOHA+dwbniyEkw3oPpfvVBs5xO4bVBFzA
2nmjCDT1ppikrISgm+pD6KNldqLXSf0GmeZWgrJkDxCKMmgQ0cPajfP7jApKGO8MpdvCfG7s
B2R7Bv0LJN30+MhO0jkrbNHj6CRa7uWC1E1l6KKT23YYi/yzn75A9sPGBsbh97SR332HV36q
zJoT/NdEQyX19gTj1AYootT0NHTe3zIJUNpGsFrLiGXbhR0cxsy8mGlKLGZog+TSnOaYp6Cs
fIaXgOtb86Lfb0aGAjysmH3ym4GUHLdITWXPtbbcv89uuUSNctje9BCNIKwA1qqHfQDwq7Fz
JyI5jbIffJf0g66kTE6AW7RvMy5pppVTDuwmgqL1lZ2gfQccTerHMKtaDJN9ZTKc8zks9QeA
MQ/RhPxypXCaASmMEdM/BuV5byK5q9NofH6Sxa9ZX7jlZR1737m7RQsGnv9I9gPCGk9a3huh
Ocyzkh+fVONJLeEL43o+/+j7Xc5vx6knqK9QPDvF/Do1VBP7I2mDkbA+Yg0SnlZ7YLE8yXgx
TBtfmR0z3Fbsx3gYtwtZixZ20FRhJGzDHIjI1rrJlVBr90ErWUp+Ug78l1chRU1nRdN8wC9Z
vQGcQOiRDl0OgYMMnkgYPa4uqdVHZFbJjzzNGqy8TKS5NPGlXnlYTPjvpVouHbmEM6YBTVBn
CecKyb/CKNZmObakO56eze8dOa5zjFZI7PaSi7JjM29JNM5wF1A6OaGOvvn8S4OCvhTf+IgV
lmye6jXeZxmIGgYb1w7bw9pxeYrEMtOmnlApJculoxVSh2H4HsKqplztwrDYcEZ8miEFCKHf
W0CJcKBpkqYno6YvwM8LrYZISaT5KEXIiuqJ1Sijqx8NFSpfG92kgp4x31kAbJangTkkSZXA
NjD/UsuT1QZjspTwGzR0jxlCo/mTfpWtwd8CqW9BjtF8YJI867s9KNDvAMU54tbXStlskk6e
G4YS0Yc7OYjX07bH5e6LXmNrGCVfucEdAih8sSd7IIneJYUBVPjMCYDs31vTAcCXInYUfODr
Of7tcLWKHwiw8H6dF0w/BQuOBZt1iCmaFMdl5TJlsBl4TxVwhT6YLZMA+hvXqJnXXOBiw9KA
hBIU0wSmdLb3BiufI+IhvrXs+YZ8AbcH+XOxjsmGhybrPI+CNfrMIJBLNhbYtU/IXT8TRZUM
ViIcp7AWSNHQK+/Lm+n+XuVgHsVzwwZf4dYhPgsQu993ZS2Fjg6bX9Yrif47M+hPaqmiZCrw
duRtdvJJ2zBTC0lxoRnV+KfcnHKjW+QW16ME/MRI9+3q96Eln99lmnHNU1giuAMdoxL8jwFK
wfB9JMYQ7TiTCB41XZAXJzi/LgWCe/VNSyhv4YubajkI8jTE1qEIeaWySnIjht+aJCF5zfFx
2u2Pr80ce2zD/xadYQEJ2LFgYw7t8StgpJ+ii6LeeimXU9nYU+g3xOR6NnG+AochmcniX+WJ
o5hiutEKWHO1k7+6RVFYQoi9heAfALdq5lr4b/P2kFU/u3hIDYtoIMSzl4Rb8rdOrzphMAym
ES4SrM4vInOswIkXLmjzh6Hq1g5LbJv/IihA+TykNe/yGN05YQT9x1/cyuwsPYoa+GYdMQav
+DjZA/psXHwr5aEhjLa8yyzjt6DojL9asonwq85phc8n05xRCVH9lJGUkazuURgA0404DKLz
Hqm6NCHlgcYhvwnSv0Xzejyz2f5gC77kFZVauk8BtTla5duzdEcud5YEaWhvEKb6xg30VYfm
a/DxkDKNXkn9VHvQEiU6JLZNd127PfLWJayTOQhWVx6r+k1Nlbd4V2UuwmtgqHXUytmB6jZa
AznC3NGHgY2nREOZ3R8rbcrzH+91FOmardWR88pWayrx0klZpbwwsajR/0XH+C4U+iVgfhGJ
Qe1ikIFfmlew2wPlHTStwqqki6MxryZxHLRbISNUx2R8fItMe7Y6PojEKxj1ZkYwYeDt4LvC
KFAfJjO2bYi9ZRHj674XJs4cxnJpwm8Tv7yfWPDVSCqzA4hjrzjuTUeuyBgunKvlRqdOdzPP
evnxYFWDDY5NGXyTqzxSWgUtemCw0+JWhwIX0BBp2VbOxYm83otSiCsmijBvvxMGyC5CJYlF
7/lHcFCO1z0qriYVA4SDRFTZ+wmsq2eZj4Q8RlHTypRxbOG2IZqmO1F3C2dWJtUNXfxnH5z/
FycwVlnKDogrZZgAsJhV7S4tt4u9x0hqodlAXXB9ufOwaKh6fLuvFMbj1mWOdtGuN0lhqYtI
W0N4jhIcJ93P3bgkOHRW2xFbp4mXRzWdKUFCwfg1uZqJPLK8FkWg4fLYuyg0BVSstuWheopk
/RACaQjj4c5ojjZB2NHBO5+mYeJyOf/6k1DE2ZwoTnGTgVT8pWR/vx+Ws9VD60lvgTGY9PJl
CucL4p4KIn5HuY+wgnD1yAnmFcN9SXHbAMB2BWWV+SekqdA8H6jq/ICsbEHOjv0YuCtUMpEz
u4UTk0BZvyx7J52g9H5KAnv5RaXmOkncVkvn/rCK+VO3gueCjV2matrCb1iHom1paqN6Gc09
lrP6OcePmQp+UWhu2YwOJwH73O6FS570ph5jxLxS+dlEPfZNLWh+s2oJ2ZHkEgqTa5Oym3Mx
yTjlvLH+G+C89HW+jvLoSx/wUSoHmA7wBa0/Bws56MP2k4mKX5mXxjEq8iR4It9EaPbmDgPw
aPUL7Or7v4sFOjFwqGlF/F9jRMnBNIhVBZ60esk8p8TwWGMyjNxGb+RlDDrnal3YOKk9/cox
tjo9kM9fJd24PdEqvO4brt8AWieM3Z6Vrf1D/dGKRi7v0j/W7DKCknu2xUmXilPSWH4Q+lx3
IW53N9/7nfuDx0RjRxjhWdlWvk2ZXnMW3MdWOO90YHqkoRgrvYWXwYYn+BdR1DMf4nwpNSWo
vGiOnFuYUvyVwjP9Njfn6Paxz1lYxUPbMPZ1HvIxe+26vg4kwIW5SaRX2606cce0bto+gKuF
C6Y6xEZceSTV/jvOfE7bGKOnc/7Y/2fl0Ib97i1QFzHQv4FdVblc66uHeQDBvm/DMULS6bwi
UBM9m83ofAII2J5W7ycg/596Muj5PuyXKmaZ8OgApOGxbhlqIvpx0gYa663QUUJnYNfAbAWC
jbB6uRrVBXQw5f5dbWRtABIxqS1gK3O3k7Ywx3nve1nz6eHD5rGwpXAPQsJLO+Crqn6wij95
V4PRJXKt4I25ELgr0AbIf6z3n3iljPNz5KFGPMVUjTjohxDtqKfkgkD++XSyGdn8GW3/zs1m
FfxVRY4adulFoVcI/+rar0GQ4k1C6QgmO349SUKaL7AYQ+V+TeKDOs7Leo2enOnET9oxVX/f
RgHKvhqQJ0wCe47E4S+mIgQ5HRoir5Ka09hmhIvaRbagdHpY5QZRCUAF1rQlVzBKrFxj5fwV
ekb/NQ6zuKBwNju9E5H61kv/qvwpBZAyRN0KtVfuxxcqy7rXXfR80lVnaDaIpGTa3GTcGhs+
yb0Sy57eS92orciFIo2aMOdp8DnHb5UEAXcY5ABRor8Q0nWdISIl13R09GJTKFE1wuQNgWaG
vicU9n+4b9QGWky106E1RcxD7UuFMG/3gQBN7RIcilM0BWxAMjF9mjN95zmOgkcTGaqOm/W+
e525UrUoa3RBVQqUqkxNj3yyZYmDFLY/+3C8DfRgpJ3cC6IXjgnaSqgga6lOgic8vxiNHikz
c9siOIUI8EdBbCGEC8R/hb9C3KumWdOR1BxUdYEx8e0oBr3jBMOzYNPr8G/8bM/eeh0DtnA+
XknPcb2KivFaGEoVsyNHpyL4NwzkXipLeCvADJS7H+lU8hA60Gnjqoh30pcIKx/u/mVS0IfD
JuMyd6OuVs7Mfc2WOeXfw7Fmuu5cxT77yztOchaZKRIHWlyOWvoS1YkQZG47z02Q3UxV4dtk
H4UA6F0/KFtDhKBMOitKgp9uBCshBCEQDbFLUNyTnhPBk4tNthj0o8IpypTyhheq78F2XAtA
h+JO5suKfBKnOOoPsY7gUjB51ReLmSI/0QKuxlXImmU5fL+wlNmOneuACVGi4uKVtHzXNc4w
Zfrk0dGC9ODkfJg+yBlMGhLLfyl7Oq73meeJjz2teRx3ijKpkp9t/lcdlRSvkPgyI0u4Ozac
Sp13O+XQseF8NPBWiFPuvcYoqQUp126T0ygidHqSe1gUcZkJwc5sztrO5KDSLDOX5mXd+DVD
/VkTK88VxZ5ZX2My8P1FHEGPQcESFjtyImlc0wy9cPa0YpgH5xs3g6HpDfFOdQkkOomL1hcA
JnZDaq37Oc+ioQGmQ+tIYpoUIuG03Bs8n7JVJcA41qXlqXop1A1O35wgVREJynCAtCMeGXOL
CAAif1Swq/4ZVULbhAoI+/PPpRdnFBu2yYKkB7kUGbCB4Z8lT0wojYQZXUV+wwJMDVWQ51Hd
8BMBn1aM9VMSogd1WnlEBvr7ETOepjv4z9uNuTfEmNVZcXO7RdESTDJqn2yndj6Np1wmbbr/
OvbOeSF56PoJ0+jbR1T1+TsMcEn0MMLjOS3GnE+x18Hrvzw1A8O7IH6k6fnmNxoOA6VRDHSS
fXdLJAp2wvIY6cnbeyfVRDKeBFK14+RFrr1JcAXf2hDiyinav8pjd8gQuPplYKFGJ7DnFw3D
VNU443jP19D2EMmDnUBL2lRotGJlVrJuMUn8XrpRs2W273CpzDj9o+Y+qR0fJNZp9TA+xxMQ
xLb3qhY1LfALjnknZT8Zn3P6MXRk+way0M8JQxUfr5sS+BlsXtCaHi/heQAL28Q224flKQ1m
f3iHV0IJMqUs2an3Hnh1c3up6tiXHNAzXLThTqMx6zvysAPXOR77uPEKrMcCmEYtTprv0pw1
FQaod94FeQ3uoyiLkLdF2zIHMvQrmHCBaJKQWiw2FPNLe5Xbul6jADlxNu1m6tKz7CT2tSOo
iCdEHpGYooW60/SCvQNQtUhKsRXr9k9EPK57ODy7VovwtawmRQroThs1e/p2euZVODIG3z7b
xbjBdxZlZqZdaNBhaUluYJ/8cOLGnovxMw+EFfWC12qB4chKSkapuuZdvOnXFsP1TYghxOr1
uKieQdcNTmPpOk9rv1jb3Qde+lZYVbWXjly70lQ/bCQKZXBG1I3CqgBqLqXUu7KtDErHfzJA
sUw/C9Wd267wXR0OqbO9qv6TTAfQF1xuFi9cAnXzrqqdUb7yE+Pky3uNj6r0Ou4WguOn2YZ9
tovR/1pCGKdDC9YytV7ZOQGyHgTDbStmyAMf8eRsl8+X6FUuqC2ke+bziLMLL0VMRZX4oK6y
zMgzUWBkPCANTDl8/lPGjAwvjALdaUtjk0lNVvig+sypSCBgI9EYu/uk4sAcJUajPWV/kxZ0
3QTyGh9Qr/qtGNSvRw3UqG5EEIAEh686NMChQy/dXdmgsU7aWSDujTEs6eFH1jyopSlCLTqo
OUYUEODnKB3JgNvBmv1akqFDEeE+9UHj4mSwwXU90zQ1R5KIekN/xRQKqYT3g9Lt3XzwXhAx
22hb5azqEDqyzbcvvCLg06skyWsUSVL3pFDjUBl9m0HzUhsgdmVKAGt+NjfxP0yPaz2HOYOw
9IgdVTzgmBpFoAlw6B6XWsr3PZGxOR++BywcPCbapS+TAcsRt4a++9s9+djERFIyjTHnC8Ja
oKv9dBnrn9aybuf+FyhoFwdFsX/ktWtOc6WNwSVryBE7HLjUlYTgRLmNhx4KfZDUbcZ7hgsY
3CSksZjHz3lWVRvHs+wRgKHKiyNklQ30gz1bsYJnaY1LjToYMcpAEUwEBJYeBZCfWHcY0RZA
HmCI0sWNCSpEC/5fHZVnBmulwwdrSlXUeAHesyw/eX+TWWiUDPE5lxVmXUR3NuN2rboKkiw6
TWlmfbeLFmv45DWJ/XQiacWDv6DzqGQ6KHF1CUyBiLae+tHbX9dRVgoTWGDbyMzRyhqPjT+7
uXi4PsFIbXBXo4NCCHZv5JTnPqQlQ+lsWjSQsF55Vn/LiyPdAzKoZDDN5ahTfi74420emrhQ
ixmnVQmcVQSMu0rC+dxzKwko3GNUJAJG7YtkkOK3yj+jSWgYHWUias623qWCwePzraisnV/V
KAM2HUFKudLEf5vhINb5Pb722W2Lvi2tYDP93Qz0F3gl2RuQgJzkWMRsnlXxJLeVH5x9iNoV
t4DpaFuiQRG+WJxgKAYr+OwqFMl0Twh7FeDBt3S1lnNKoCxMo0GaMJM8aVFDZdnCZ5ujZn3T
jh7R66zf78vT2h4J9iiuZKHLKKyohmmONxpZPRE98EYbDudcugCFEqrslpYr/JIcrLaz9KaD
GLiQabYHfkAfHw0mh2P5P/fdC+EdeRB0kP9G9fJUL1TLJv8c3Dk2CjqMWArm9YxEBWp1W2Ce
QZZt8DBvTxLBueaiV4GVhwnPAVLD5o5E8v/8LDgugCm3UbNXw4i3XXyx7V1lKYX3rZXSOJbp
+kyQu5nshuISdT+878QO7eygdlb6WQm+uUYKNPd1++otpb7/LDTfp0S0eYK6HIm1B5J2iLos
hmoRPR+N/8ISKS0f74VRWjGlogJcHaTgMRBQWLHK8kejESAzC7YAV9S66cpnh+ecawyx9q9P
UAP6859WDf2f4M2odDvhSCQgSdJy20CnD54kfuosLLXn5zOGiV2wTGOx52FjObWZ9KWDEBzH
YgwOdYB7qZjhKgnEBQP3nmL7I6pWJG4O4EYO73FOctmmdUbXUIOhblk5hvzAHt2AWIbpbD9e
DDA/v8N4jWXjSYAxKQ74vBBbMLlE7MQ+xKFYxiK1iz4+tZlSWAipmHVkSJQQK7ODC9UHg0BH
eansOE0KFo5DnVsMvD0Th0sv1p6YNBLPZMMsxjjcoVnKD2Zw6BqV2651CsIALWOa1rFDPG6D
PbUWyKTVxy4sZ8fqxapJ2SeFSkvffr7AWcTRItHSFZg9L51o9U/TuSe7MWISzKqF3fD5n6XB
BU9i8GemFEYUCJPj4yRbEuYAGW643L1KY43GeUuIEsb84RaUy8fPj8Sd/2nrd6rb8D0KdUwH
FsTgt1y4a2AN2ZQbA98cjsOzDuHIsdNj1lsEBob7TeNTTgWuba0XfZGo/qptd9g351FD/K2G
dQQ/y+3Q/Oe/M2HHTtmzyii+U5kdzKbakRZkMNcvopTOjFsYKCYp6rOGb1HYwwh0hyama2Kq
xzPtARJsqyaDhola+6IZQPX2B2Asfuy0CFzzzo8flGzEZAzFdrhKDHSXRi1kiZEfBWdyAs2N
cHWMK/g7SPBrPjYxJ1EScZaHoNr913IlbcziyhYjqCXwAmu6N8jQZiEl0Hgtf01V3ooWyGUc
8bdystKb0TrWKBTDp4Q1uAISQjGn+ugRoB9uzj97N81JJ9o4uHpaMTRxmcDXLk18ez0TzGaU
Zouce33GrNsDWBCRMyJWpNywE/sHIfmLFSB8PwHlXlBQQQlHIQLtebz61tCFrqT8hGUeVNz8
I5iVPQMiGhfvhNaOTWg1je/FfQJb+05uRazHyiUQzRkBVhKRC6d+9vESs3Y20koNpzKktzvN
TQKjzP+dhFWjKZTFZ1wovQ70+woxsO7z7pHKBgmcm0FBoq4iADU34sAbYgVvoN1usm75so+o
jaXlMpEH4+Q0cv4QkpZZCiJCdXNs7yLzEcBdtO0XndDaFLwBto6lUAMlphzWb0MmxRp2Kozf
cbiuiccO3vB/jnMdqH72xN9e2wdxvtFttWrYljPZDmAmqg3p8/+XIeF6uXX8hKk+iI+GgyP7
SVw91JF0qoNdxGbiGtLV//X+AqmA9yakttQnINdrHRw/myV92OVUaiymlJmRBufXniGHTH0E
ASfr1BSut0ov2FFds8dj2d0KX6fJc9H1FBW/HVJw8fXwHOTqR9As+yp6uBtjHCXeYh8WtJCU
6ofW1SZCHzmZkJ611yWB2a2kFu+tN6lwyuL6pAG2X3z5GtVVAnpFMurxQ3SdULro+Fb2Sk5/
fTSQ7ZH9RahF6mwnTC1C2cO0pJdCFe64I4KoV1F44P02PxIkx/id2lsVyFufgvjP8ACn+Xa4
Enu0xAAw7dNUthOFIiAHTpcUGbRR5J+Uwob/B2Egbiqd1eoJAZxm9oQH6XijpumyNZyh42qF
A5lIbw+efc6HjZ2VKWqN+AWprNslvAYnTW5PV18AIgyQzWhQJr9CuvSt3OmsKhHWeR8xLXdM
CW55Ddcl74cxhvfPacY9DOaIwPrvkowmueWqTlAFeMK3xI4Lnqko8hPwHD91eaOKLyDSUCws
5ZkGGF3r3GSAKRlIZNfv2q8I5jUUGjr19EM2UAjyBqs4v6wUFfKs0eME4BN5XyacMI2nLHGM
KZGXJJiC/aVDHnJ9pWOt9zdYMywtEE9DuIpkj3cxaUHW9tLBs7T/8yMFbnKOsufXEb4KpMMM
SnS3OY/am3vngNpE8Hhn/1x3cfYOs/8DJgr1KlX2fDH0tmY6RIoZ7b6oHcSo7ka7OoSHbMoQ
Sf8uJj/wyYd3zh10RDM50hVyUTF3aT5br/UleSNLSUHWCa+lTeoc9laKD9j9KdAEzhO2QuVW
6LgJvzI1i2Qraj0UygHLIEjIhdWDvYoYrR1/k3+EaqCQ6BjXm2SP4m+oYhfSlNPWgYqUvy6p
RD4TDkJTpm7GoZQi9J9CtbVyqqU6fOLTH4XBa+q32N/kFHv1KOJ7M8kwK5P3iHp7/PGKKMMU
Pyvoel/a1hTKfzDdMHwY8z9LsGcdWltj8QW5eM9Uk2y2gUHW+4FUq85PHBNVqW7dkQvZtKRw
eilVpGYnOtU/Ik59Al3Xb57bgigo07ml0VY6J2eEgs50gPvkS8v6ceH8uuHEykR8e/5h0Koj
BofIzse38FGKJRIJNyRnIpTKJurGFMUKvgpYTLcR6g026+vlUwYu0n0XhPZoZDwUazp4rneG
k+bA1LhfgKQQBQO5AAR+K2dJVhxO/PPh0mML3VdMehgL+kUF0yVT6f7hrRAcNbwHp7/5Zoxo
ov4qwBdlFV2wBQkwlMLsZQzdAkqB5I4IdTfdZjb64Fc1UeIoNq4/O9ca1mRcBlMl1IoEEEkD
nD2/2Wvg+8ocA1tp/kalB535BBHMQZ183ZRfEFRaHmLogV2wXsJCqFseMCTz5M3Xb6sfGrW4
HLS2KkER/PSUK6gDL9T2dmUEHmDGrl/1YyeCDRtCGL4CHPpieod3GGL06XWkPz2jAyt4jkUk
2ZFNsHqeX4viHvm5W3YYejqgxoih8sXQT+0FOODRU91BbVfT/tBkFPGh1RgrV5EYPn7qbpHU
BbLIsExjmUy5FZ3b5Wg1fCNQzezuNXTTyd+nPJ5TRQ+lxzEa+tZJ0LXTMI0WheVuEnzaY0Zk
Mnb4HWrg6v5DDkhs8lq/UlZf00QGR5ij0csd7PYpAxF2yEjuzUW/nBgTbDnTL74u46F2oEVS
pTsDVU+eVTnY7n0VGOFl1SSU1Gs1FS9N7GIus6jFAUbrA+YyNUtbkSumc6A6dN4/1D4UchT4
F+vKPuea7DETshNxacbeTniyc5+6Lp490/RYjAGoRcHcs4VSAoLJFU5VTiq0g728dStMOmE1
wJJtWXFGWBfa82WwihxTPkk3tz6pYTyosSNhCNMVOGCOqDgMvk5+WANXIo6b91DsNfSerVMW
0I1bc6jCHf3qKIv9U4GaH5UzmmC8iadP0bSQrX3pJ0w2Ee0ipgh0fGyn3+1k239m8blp1anO
zj/v/KKGh4By7Ome37EjTPH8qr0WnX6T+oCW/FSn498qADijTiuxegt1s0nzDA+LzNsBgMxN
/xnYxtHXjbzFLkoz5HJGua5ymzx3BygaeFaUYmikShjvtLySa5xDjMKOeWAFuwdJY5lVk7H+
nHQ/8Fl1l0zzr04SqWNO9SKes3wrDQusnPppeQMy7lm7xS98mR71meq2FRZYiUk+sh2N2wI7
HflkkMxhASG5j4gAZKZ1F2MpilRsudF/6jHZ69zlZaCqeGNf+HhftSLWC3qBuBlZiKP8I0z1
QuN/BwZ9Hjxt+iB5JOOmLL2QS1t7tFYHBU2/Mmi+1IIkshvB5N9lX/G9BKoAbIwvz02NquKR
xDdvEdxD7Cuc8CGfppHRSwU3kwbKBsJe25MmpuwfyRvrvQYEam9joNplVVyN9sfMzpXyfe5o
d6gXI+C9jSPQhdUV1o9xnyVrWUZLTDqqwMEPygWWc8HXG1KBduBhETNNStRox3E7yFt7DSG7
IFop4xzS97nelLaK32b0rhKd3/wCi1dxqjvPDHnxOchqktsSAQA5rTEbcJYGGuSRBlXaI/nl
EpCXiklxLbi79K8Tc0KxKcOy0LOJksyZNS7ipb1TwdwY2yis59+nmLtrSdj2bCBfjDw15TpZ
ctn7AcifSZ8RiR5nW4uJEgdO4WnierJTwP6r8l8qNBy4SzT05k0xC79PCJPJCC589/q/XZln
DbsjdXxINQWaNXbWPFEPyIrqMJHisysttsaFEiIkdnmuqO3qso44oZCrSuBdAbRo0IJxOoYD
ZjP4qrJqc41PfckbEmjTqUVSpk8oO4HwZMFIBH5asOMpOXMOhqBq7rQKnXtTwFC8Ll9ZcaBU
uf/CYSIRLI733XJ4D49TK4estnmAdSI45CJNEyKdaKWHRoYA/zOOqVcBS394vTsOOMHiXN7M
olaZ25rHT3lEO8W1+Iu56Pvy+3XBI9to+hifGWlFn/R4UQs9vAZFvUz/bI0mPRWVpVVqYWhk
H10Lz44zni6aF+0xYVfUI+DIl2WzzRYHDPffLsz2BZcEJPbZJtxkti4mOPfkrBLDvGxOBA6f
p70Xnx0sdA9hEv24YVN/iFmnyFT01NNDtNN5vldz74nm9Cm459KEfp8k3WS12BfNYC5C/v1k
Hzps4Zf47UP1sOYbjI2Ar+q2p3iAUKZg4TfOmUKbKWHaAuQtJ5v0XRq4G+MUym8PIbC89A4G
lROhFmRZcfacCgGQ6Dv4h6o1BctISsfzcyuAHOxbqT2bbe5ZjPf9U2HNBwM/W5ZkQfO+DgHa
B85+rGP3oXd9PKJbBqaJQ0wvqrbh5A2Zhu4h4aNbff11Ms4oo0o4fctgMm1Qp9tXaCY2xqLM
wJv+YBgT9Bioac1MFirLJI2wwLnAiMrh6y9eYQrRc1t6zqBcEWSXXXk7Ybp9fdyXqKyKcRSO
bOs9v10jL6plh5NuPP838x9xfSRLd1ZCXf+Y07/sxN37qx6bsntI8wgU0ZzdQsFVLSYF1rUn
YjLwiQUNiKpxOLNvLonv1IitTveCTc5w9IiAqv9mL/RmbYxYlDa6n4DQq3p+zRG/O3ilAHnQ
jsX79WnXHUGBPKpe6TVt/Z9xdEGPIwicV1ATgOOKaO9KV3zkkNyJIEBKZbxnYRC/2Bxpg/q5
f/iQ0hmHMoEpbkTRpprvmWLonZ77qqisxhT6E9QR46LaKV3KexqmSHAw4/UPSRKEGo67KvJ2
03g588Px1wciD8lYGQeJHBio8+gn22QtXcIYJKqHCXoY3TZH8gmNOn0mDWpVp3q6AJbrdsYh
Hn24Sdzu+kQ/88d/EFPU+YOF1jR/WaD4BKFfkMPYRNuNJ+LLblMFOBmqERe/0cjYDF3QmfpT
lF4dV88ydlJjiRS3UzjKE61LoAx+5uhw4V+g7md8oU2KTI3G6vtQnFkNCNFcW778HNKhLEWw
vFqpKo9jkBIDRcHm/tjdypu2WnSkK/JKdXWmoOR2cdbE1vYn3aYSqhplo7LEu3DUrSeJ6dB/
btAGVpApoXZthghiUZS61xf/uYAZFVZNYy5O/AwDe7KMutN6ISljT3qxtUqKvawoKRR6mkPV
gVWzPyMuqGV3Hm1OkRck8MJsEuJgiw0EecqfMyY10dr3Zryh/br+3sUi2edWUPz0uBurzLO6
vykjJ+7Re378KtdmwoFZRqNO25xCXz8VU6dTk8n6qrswJzSEIcy7mZJyMzjQ/t4stZqgcUoH
u4TkbzmWVeKc0ra0is1zbVrdErPMyPYUOqwBrTyzULu5umP+lEt8IgpXiOqKa+TDmnP291Mf
tpfPa3T4p+CoJoythalS1p1IyLvewqaRccwBAKYlinDP+OHds6wgHQstykUZaqABt0XwbU93
07wyLahlZ8Ej21UCh1c75/gDWuIDQHjB9bXtYDzId2S07EpdVHn0vk5unzENXBsLc9Fnulx6
s6kqs7dtdpKCSJyJFdNgt9glxUUlSRzNKashg7xR9/pqP6KZxG+tEmsNhWa3v5vPd6ym9ZcC
4KmryYPz7NRkSwpGi9sOPCttmAOCfX+OSEvm8LFr22xfBZnVVWSBBdQ0kht/CS+G11UUdr8h
iM+52iUeu12iXEe43ie5iF+/hZqrftOuio3Yv2OvDUlijZMjzT5jjJW7EYp42VpLF7UHi6JU
kiLn9Dv7pji6X+/A3B65wJFViBhhAzetPKVG5AZ+Y74GNkjSkb6nYHNJ+zpyMm0LuIg2NAz9
oDSwlCS2N6zlrdXiflYTtUZw7voNChXuizNm1gCOJQcs3mVjBE/KoGd05Iu0GpuV0Sy/Khn+
oN7Mbfzwe9TxMTWqZta8K4Y4+kVI20+jr3nXmqe8rS2WMPzQqGlUBwxFPh/n3H3XTij0kfwr
j/x0z2+jDd8YwdSNsXVDAxH6KWY8BOzIPNr74tFDCdBtiUA4tEMTVXQ0kfSm+s0lAq8YEvmR
mNUxXLPoQR43da9wleptDwR/r1Mm/nFba0wKk4dUnIEDH952t4wgIH+BrNXMveFrXOncK2Ew
040TXE/Wf751jXHENDiPxgJMCoP9gK4AqXVFUmcfMUON7ibekjQ/jU75X47YnX9ewbs+mUqA
6REiiYCs2chPnCTiiPrFTlYiuUeEt2eSKdxwCIvEJYTzqwyzZ80hSBjJ7s9VgsZZmNSCBE0o
g9q/jo80GNWVW/nD1g8rBYjfL1NR8FnQNjJzw754GcfWW4ak8aEfLKkTMYCle8CmmXNOD1Kh
n4JWQa0hEUaaGsGbzzYVm2MdZvD9HaBPUuUGA4gmXn+BhT0Ir0oTaJj18DltP0pdSFqlPs8y
4+1ekzY/SF2tbwkOKG93bkC/bbXEDqHG48+AF4WPPmmA72ixVK7FfJMFmu8YAPQ/2TFCfoAm
uihFsiKIIVQ6TCVlqZUMplZuSXwFtCCBQ6qCuoQzstfFGUDiEYpP7R7lE/dQyKZBQTMto1TC
zYWk0Y1PZDT3QuUU1BZvl7RYZlwsaGUfRWCqqVIWE2sFDNJAPmDIn99gjlgy+E+9tGaAXSVX
8OT1rLk3UlE7jULMZioI3jaG1XgRQRH9GcRc7XMEudkOHy/HAb6xHWoqThsD9IAXu5YKV/4i
6oSy/buz+M/2lWbPgUKvcf9PYdq0Ucz53zeMtqT/XnHZ2+i8UbalXiyow4y3ScYrsPgYR8ZY
LHeWbUl5JCITboCL81m8yfb5l0Fq7Kn4SJ9S5QIeprVC9e90byKZnXX303O96X6aZwSY8dbN
SkrtS9Ws7rCb2KVTQiUCzcZLxi22FAA9SjpLtmvP3tH3o5GGFI7T0Zis/fULlzh+Z6Z7y6G2
JG9sSjskqS+WYaWZ/cS3cdzzNMaHCakmrDEa6fypIVSsPG3uo+OmhkKJaQxCHIs5gdVTsVlw
Mw9BoZIawtX5Bl2lTLwwyySeYKjekv3Jk1Usm3arvfqXaOrfa5P4QfMqXWOwws1cY/6t0pTm
MBQFP27Xkj9yPpqy0gSp7r4QqMAfFdxMyAGGsY8H9drEh3nLpV/eB0Tw+tVzc/TjuILCEuZj
KIl5bP9QmkNA0j5FkW1v8w+D+7YkqoHkFUjPx054JNmahG7gsOZjdNPlcnj/MAnwDzq5RtFl
RK/XXmL6nFOQXMrVqEBCF8kMNBi0nskIvoyDaNawr9nJcyvQ6EopemdI4C0gWh6uO2CW3+HN
fd4pXpxYJAtV+sd7DLt6Py1fqYRx0Av/MtXFAbPG9NbVwXcNcX6s3TwYeD5SQvHoLm5l6TLi
QT867xtpoxEeKhVk60ZOAiQDbtSATnUP3UC7BI4eamcChL883WlKUZV3szyo13YAa7oG8Dk2
oZqGVVZXUrscxHfGFVDvUkPcw02DrZ7D+NTOPSSe20qJynBOlOEdDdnNBRFUtjlJJilLqKpx
yCEp9AteGFpGWYcB6+WPqLepk4XjfkvuOvH/c7X5gMpz+uZ9js+nEGBbd2XxFVDq/3hyUZ3s
57ctxkgjVCbfYJGL0a0W46jOLkdaLkrniWG2eHuTSX57T1b1jz80UM1wlN2IHlRCzJCmT+BS
Iyw6pUYu0uVYxEJEnTMwe7MDDkwu7lRH+u91bL9kg0HlVgOHOmNq5SiFzRtogAkdaBMlpJSQ
31C4KoZm3ZIQG+ZHc6dNEOnEj6Eaiun8rPGE/ol4qd0bPuhC4tU7VYc+5s+xgEgjIqtVkPSR
S5xCqARHcGiLPRdrE0kYUzimjlhLLzqT2bYmxcx3sHzZZ21SR8ykDhHwsLVBAVN1qE5cMtYs
0vS2Q3k464Jglm9PeVgtyiCAeL3CGmu/hhzuwfriZPmoHlFgemwKC/VFxr2XlIh7/v6PTQFh
bQ4xBceA0zLk2C7jpaWz+najJdARfnAY8k3r1N2zaLvHa7VfleTs4TC40yxgiykHgAdNaDoA
uaY6M7Kjc+M4jhqBvNABTeiilu3gdH2rxI/R3Fs8TzjYtSo7OwlqSWZpAVO+rbD/4JCb6UuQ
9KY9t8NKG7HT/Ns97qz6bhwNyb92QjDLeaHc2v2tyhT6WfvZHF2jtNKusJXu7eYlyG3poiYR
O/VA/tzqXR9sw/SukmmTfamXjt1xGzHwI1EXJLXPzwvQFoQYaVXVHx5/YqM9SdrtaMwfurxj
w3avBGHR1icJuuiZ2h7AX2uPdg/7scgnezs9Y3aP5RWzMDpgAVK3ALAQEMmGc4EpJlo+wmkL
VIPQ6f7EHedLBiYqG7lhwaRTKUp7pb2j6l/WOj3rbkqg0WzIAZXYQ3O9eQFbJYOTt6qjetJP
OVhoi9vFf2LmPcl+kUpi70VIOHbzADjOG18mY/rnYJPSkF232wOh1TF6mdeHLPn1CH/zMrp7
W56lN/1yVjULdF5RFC4MR5+KwwqlCwCvBuUJOznGb/E4hOs6N71bXotfSgsHNIA7pAQx+0Rk
5J3c6vXxp1ipBmSSmgwvN79XJSVc6yrt3gDcoGKiehb5/rxm43MYMRkyyAnAE2xYX6ZfChYw
vVI7+BRw69e34VQjVqabZfmzR5cBQ82jvtpbDfN1jBrerSqa9QycUTzjwrJg5aY2xKqygGx5
FpttE3dm9T1Z0/dVLdvN7MIA2LpfCgo7xH/63Pl8BgtzpSCy1p2TeATBkZwVUCjNpPfQ0sAm
DidA8m6T2pNIXxuyDpUuXu/ZJy/7Zx+RFpMTUscLQipvaASMkxUpPwFhKTm4AYV5JkiX98PN
XatcSaW9RHPTqgEL13vEVgDsaoowHykzQ2EsIY0ASKlkzQSYPC4eoBtx234EU1EheGMDA1Bz
24n4aPUEx8gXUFqgQi9TQOr1RfwaKzYlj8qsGtnapDxsLEAG0KTPwujNIMyA+4x+zYkR6byi
5AKmnzeWD0h76J+GgCc6l0oh0S8w2Hlc0prdLiuboG8qPyPXhJCPhXIwFwrGH8+fB5nAtJFi
hQNSWvp9dXzDrXL42z3+2b43B1A//TIAs/0GRTHpd0/MKxXqq2f4PQywYLkAlhkLfnTu5fl7
VKfYXbcPkoNDU9JdOOAlj1p2/dV2OdoFny6hkkRLTZxnmxVe/c8ShE019xB74ZTXchEBvrg3
owRE+HwTPXXGEz6ETdx/90dk6DYRlFonzzru/MIMpcOJkPFyrjWDwexluUMRx1Wo5fi97l04
HT6SnVJdsDtmZsLmOFnJSSiiebS0g3vYwMqWgVqVu1co9tolX9M30eZOyyQcUbeZcC4tv61p
8WW9D8I6dnFk4rJVF0aEEDDsDrXI234p1FQoh/vqs2gVJRdutyiun0VlevvTBJ09+AcZFM4b
8Jgzb0XxEEDqqYQihRCL5F+swb+l2viv11z7qaBJK3TEY31Kpcwzt3iD5crHtiQ1AvoVIbDG
yk53iXqvtnBV/oGtRGElBYS53bnjPelXZjbHfGAZ+CFtW3l7nMaaAre4M7xRpr8yDpqAN6p9
ugO3JLOcezZJRiAvZyFzGb3bZm094V+2BUnNdKTEx61PuHlUPRNYlqwYBjMiSTkrmXWH5Alt
Sc5btMbFXuMZfxvbemV20ZSPVLNEz7/WeJf2q5ZqVOXdX4XGohZo91nZn5RH/68LRXdgq901
Gf5R7hvAerxn9nXa+CO4Nb0/ttMW2BazVgxmloXf5FR0gEgx2fPIe8O27/DtEenmHm2OSg6m
vb1XtBUR9wovWplvJF8aCl33wAoRd2dGut1Ol2KiwbOmQ723Xk00BB5bejFwUEsDBAoAAQAI
AMB9wzB/NfboFwAAAAYAAAAMAAAAbHZ1enZqb3Iuc3lziNfjSYv+Hr09EmI18qf8rcFjjK22
doFQSwECFAAKAAEACADAfcMwfxGmYhRWAACEUgAACwAAAAAAAAABACAAAAAAAAAAZmdkY3dq
bC5leGVQSwECFAAKAAEACADAfcMwfzX26BcAAAAGAAAADAAAAAAAAAABACAAAAA9VgAAbHZ1
enZqb3Iuc3lzUEsFBgAAAAACAAIAcwAAAH5WAAAAAA==

----------zvyqwtvpbewkkyymbdsp--




Envelope-to: [e-mail]
Delivery-date: Tue, 01 Jun 2004 14:15:36 +0000
Message-Id: <[e-mail]>
Date: Tue, 01 Jun 2004 10:13:48 -0400
To: Kireeti Kompella <[e-mail]>
From: Jean Philippe Vasseur <[e-mail]>
Subject: Re: RE : RE : RE : Last call for  draft-ietf-tewg-interarea-mpls-te-req-01.txt
Cc: Tony Li <[e-mail]>, LE ROUX Jean-Louis FTRD/DAC/LAN <[e-mail]>, Adrian Farrel <[e-mail]>, [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 06:44 PM 5/28/2004 -0700, Kireeti Kompella wrote:
>On Fri, 28 May 2004, Jean Philippe Vasseur wrote:
>
> > At 09:24 AM 5/28/2004 -0700, Kireeti Kompella wrote:
> > >On Fri, 28 May 2004, Tony Li wrote:
> > >
> > > > > No, computation can be distributed on ABRs. This is basically the
> > > > > scenario 4 of draft-kompella-mpls-multiarea-te :
> > >...
> > > > Well, yes, that could be made to work.  Pretty ugly tho (sorry Kireeti
> > > > ;-).
> > >
> > >Hey, I'm with you -- the scenarios are ordered roughly by preference
> >
> > this was not the intention in the draft though ;-)
>
>Actually, it _was_ the intention.

Probably in your mind then.

JP.

>Kireeti.
>-------




Envelope-to: [e-mail]
Delivery-date: Tue, 01 Jun 2004 01:52:08 +0000
Message-Id: <[e-mail]>
Date: Tue, 01 Jun 2004 10:50:50 +0900
To: "Adrian Farrel" <[e-mail]>, "dimitri papadimitriou" <[e-mail]>
From: Tomohiro Otani <[e-mail]>
Subject: Re: I-D ACTION:draft-farrel-ccamp-inter-domain-framework-00.txt
Cc: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Content-Transfer-Encoding: 7bit

Hi Adrian,

Sorry for the delay of my response.
I basically understand the intenstion of this draft.

I know the charter deals with the problem and development of both MPLS
and GMPLS.  My concern is that there remains unclear what can be done for
MPLS and not be done for GMPLS, vice versa.  I agree with the procedure
such that GMPLS inter-area/AS-TE framework is progresssed with MPLS
one in a single draft, however, I strongly request to describe the common
functions and differently supported functions more explicitely.

In terms of RRO text, I will send it later.

Regards,

tomo

At 23:55 04/05/20, Adrian Farrel wrote:
 >Hi Tomohiro,
 >
 >Thanks for reading the draft.
 >
 >> 1) Does this draft cover requirements described in draft-ietf-tewg-interas-
 >> mpls-te-req-06.txt ?
 >
 >The intention is that the inter-as and inter-area drafts are inputs to this
 >ID. The
 >framework should not contradict any requirements expressed in those drafts.
 >
 >> 2) Although this draft describes the framework in not only MPLS but
 >> also GMPLS, the content mainly focuses on MPLS.  For example of
 >> As pointed out by Dimitri, this should focus on automated stitching,
 >> referring to GMPLS e2e recovery drafts.
 >
 >It was certainly not the intention to limit the scope to MPLS.
 >There will certainly be some techniques that are described that are only
 >applicable to
 >MPLS. It will be the job of an applicability statement for a specific
 >proposed solution to
 >show what functions and scenarios are supported.
 >
 >> 3) In this draft, the architecture using PCE is assumed.  I do not deny
 >> this description in MPLS, but I feel unnatural in the case of GMPLS.
 >
 >It is absolutely not assumed. It is described as only one of the possibilities.
 >We would welcome text from you if you feel we have missed out any other
 >possibilities.
 >
 >> 4) In terms of Inter-domain OAM, RRO processing may also be clarified
 >> on this draft from the point of route management.
 >
 >Any suggestions?
 >
 >> 5) Considering the overall, I feel unclear about the difference between
 >> requirement draft and the framework draft. Could you clarify this?
 >
 >The intention is to list the possible techniques that solutions may pick from.
 >Solutions still have to
 >- show that they meet requirements
 >- state their applicability
 >- define any usage or protocol extensions.
 >
 >> 6) I propose to have a separate framework draft of MPLS as well as
 >> GMPLS.
 >
 >Kireeti may care to comment as the independent co-chair in this case.
 >My reading is that we are chartered to derive solutions for both
 >environments and that it
 >would be good to have solutions that are applicable in both situations.
 >
 >Perhaps you could develop this discussion by suggesting what you would like
 >to see
 >included in / ommitted from a GMPLS draft.
 >
 >Thanks.
 >Adrian