RE: New charter

["Don Fedyk" <[e-mail]>]

Hi Kireeti

My top 4 (after improving the moral values of the Internet of course :)

1) MPLS-GMPLS migration 
2) GMPLS interoperability issues
3) L1VPNS
4) Decoder ring for addresses


Don 





Envelope-to: [e-mail]
Delivery-date: Tue, 30 Nov 2004 14:46:54 +0000
From: "Adrian Farrel" <[e-mail]>
To: [e-mail]
Reply-To: [e-mail]
Subject: Draft minutes from Tove
Date: Tue, 30 Nov 2004 14:44:49 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>

Hi ccamp! 

Thanks to Lyndon Ong, Deborah Brungard, and Dimitri Papadimitriou we
can now read about the ccamp meeting, IETF61. 

Please provide your comments no later than 3rd December if you miss any
important wording (or you like to change the complete meeting;-)
/ Tove 

Tove Madsen
Acreo AB
[e-mail]
=== 

61st IETF CCAMP Minutes
11/11/2004
Minutes taken by
Lyndon Ong, Deborah Brungard, Dimitri Papadimitriou 


1. Admin and agenda bash - Chairs (5 min)
Agenda bashing - no changes 

2. Status of WG drafts - Adrian (10 min) 

Drafts - now unblocked, however the removal of the MPLS bundling draft has
caused another snag. We have got two new RFCs, Architecture (3945) and
SONET/SDH Extensions (3946).  Six drafts are in the queue.  Five are in IETF
Last Call, two are in IESG review.  15 active drafts - if you want a draft
adopted as WG draft, let's finish these first!  Tunnel trace in particular
seems to have very little interest - will be discussed wrt to rechartering. 

Overall status: almost all milestones completed, should recharter or close
in March '04! 

Lou - slide does not list all 15 drafts - others are still active? In
particular Alarm_Spec 

Adrian said no intention to exclude, asked if implementation on alarm draft,
Lou said at least one, possibly two, Kireeti said only need one, so Ok to go
forward.
Adrian - Note: Node_Id based Hello has not been updated before deadline
Adrian - Milestones and re-chartering will be covered at the end of the
meeting. 

3. Link Bundling - Zafar Ali
 -- Issues with current RFCs and drafts
 -- Draft removed from the RFC editor's queue
 -- Issues with scooping type 4/5 TLVs for IF_ID_RSVP_HOP and
IF_ID_ERROR_SPEC, also recording of route
 -- Plan to address first two issues in an updated draft but component link
recording will remain outside the scope of the bundling draft.  Will allow
but recommend against use of types 4/5.
 -- Work on recording/explicit control will be done in a separate ID.  Home
in MPLS or CCAMP? 

 -> see slides 

 -- Plans
Pulled from queue (reviewed slides) 

 -- Adrian: procedure -> MPLS WG own document. Do review on what happens in
this WG
Note: speed is really important as we have multiple blocking documents in
the CCAMP WG queue. 

 -- Kireeti - this is not free for all on the bundling draft - change to be
proposed and to be sent on the list (delta only) 

George: as MPLS chair, MPLS group plans to do updates quickly - considered
as last call comments 


4. ASON Signaling Solutions - Dimitri P (5min)
<http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-ason-02.
txt> 

<http://www.olddog.co.uk/draft-dimitri-ccamp-gmpls-ason-routing-eval-00.txt> 

 -- Mention OIF response is on the way 

 -- ASON signaling - no updates but lots of thinking esp. call setup message
naming (Notify vs. specialized message), desire not to "piggyback" call
information in the connection message.  Expect finalized draft around
Christmas time.
 -- ASON routing solutions design team 

 - Evaluation of common "pattern" has taken time, evaluation document should
be issued by end- November.
 - Model shown - use of terminology - what is TE Router ID, what is OSPF
Router ID?
 - Further considerations - control plane does not transport the actual
transport plane ids, but its view of the transport plane, using an
associated IP addressing space.
 - No internal structure is associated with an abstract node.
 - Hierarchy focus is on exchange of information between peers.
 - Representation of bandwidth needs further thought.
 -- Adrian - it seems the DT has been making good progress, CCAMP WG has
unfortunately not been aware of the progress, progress must be shown to the
group by either sending status or updating the draft.
 -- Dimitri - will mail to the list.
 -- Zafar - how does this work relate to the OSPF and ISIS groups?
 -- DP - we are evaluating what may be missing, after this evaluation we can
address protocol-specific issues.
 -- Zafar - Are you looking at existing mechanisms?
 -- Dimitri - global applicability is next step, currently looking at what
info is exchanged 


5. ITU Liaison - Lyndon Ong 

 -- ITU continues to be interested in converging the work on signaling and
routing
 -- ITU thanks CCAMP for its liaisons, and esp. Adrian for attending the last
Q14 meeting
 -- ITU is currently working on ASON management specifications and thanks
CCAMP for its liaison of the GMPLS MIB work for its review
 -- Zafar - can we also have a report of OIF status?  Chairs and LO; there is
nothing formal to report at this time that's why it was not scheduled on the
agenda.  However, liaisons will be sent to the mailing list for everyone's
review, and if something formal is made available, it will be scheduled.
 -- Lyndon - there is ongoing discussion and communication just sent back to
IETF
 -- Adrian - but not there yet (not available)
 -- Lyndon - is there a need for a permanent liaison from the OIF at the
CCAMP meeting?
 -- Adrian - if there is something to be discussed it will be considered on a
per-request/per-case basis 

6. Graceful Shutdown - Zafar Ali (10 min)
http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutdown-0
0.txt 

 -- Intention is to support a planned shutdown, e.g., for maintenance
purposes
 -- IGP based solution does not cover Inter-AS/Area scenarios
 -- RSVP-based solution does not convey information to all nodes in the
network.
 -- Both mechanisms must complement each other
 -- Use existing sub-code of the Path Error message, then perform
make-before-break for the LSP. Proposed changes are minor and based on
existing framework.
 -- Would like to propose this ID as a WG document
Rahul- is this intra or inter?  inter-domain can use hierarchy of LSPs
(nesting/stitching) to achieve this isolation.
 -- Zafar - though recognize two mechanisms
 -- Rahul- we should clarify these aspects, as well as inter-domain TE
aspects.
 -- Zafar - can add these aspects in the document
 -- Richard Rabbat - why is this GMPLS rather than MPLS?
Zafar - could be shutting down any type of link.
 -- Adrian - in terms of problem space it is needed in both cases
 -- Igor Bryskin - this is a data plane problem followed by rerouting - why
don't we use existing mechanisms such as propagating alarms?
Zafar - distinguish this from alarms as this is not something that requires
an immediate reroute. This is not intended to tackle data plane alarms
 -- Kireeti - maintenance of the link/node - out-of-service issue is to get
traffic out of the link
Igor- alarms do not only mean "failure". Could it use alarm severity?
 -- Kireeti - not an alarm situation.
 -- Adrian - this is maintenance alarm => requires to scope the work
 -- Igor - Tools already exist to trigger the same thing, the existing tools
are more powerful than this proposed one
 -- Zafar - point to the capability of the mechanism having the indication to
perform make-before-break - also suggest put on the list what you think are
alternative mechanisms
 -- Lou Berger - says if we do this, we should use existing mechanisms such
as admin status or alarm (Arthi's suggested one, Igor's alarm admin status).
 -- Zafar - this mechanism is already in the spec - JP's re-optimization
draft
 -- Lou - other mechanisms are in RFCs. We should decide on mechanisms before
we accept as a WG draft.
 -- Kireeti - step back from the solution, so the point is to write down what
is to be achieved (take things out gracefully) -> need first to look at
requirements for what want to do.
 -- Zafar - agreement 

7. Interdomain Framework - Adrian (5min)
<http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-framework
 -00.txt>
 -- Minor changes since last time, but published as WG draft
 -- Applies to both MPLS and GMPLS, but currently limited to simpler
functions for initial work
 -- Realize need more discussion on definition of "domain" e.g. Nested
domains, ensure GMPLS included. Will take to list for discussion.
 -- This covers "simple" functions, what about "advanced" functions such as
diverse paths, mapping domain-specific constraints such as DiffServ,
pt-to-mpt, etc.?
 -- Adrian's suggestion is to keep this separate for convenience.
 -- Rahul - MPLS OAM - building blocks are in place, so it can go in this
document; P2MP is considerably less well understood.
 -- Kireeti - what about GMPLS OAM?
 -- Dimitri - need to understand what we mean by GMPLS OAM. Suggest phased
approach. 

8. Interdomain TE Requirements - Tomohiro Otani (5min)
<http://www.ietf.org/internet-drafts/draft-otani-ccamp-interas-gmpls-te-01.t
xt> 

 -- Joint proposal from NTT/KDDI, can be used for L1VPN, MPLS-TE
 -- Changes:  added section identifying the following general requirements
 - EGP extensions for GMPLS
 - GMPLS Inter-AS signaling, path calculation and recovery
 - GMPLS interdomain TE management
 -- Remaining issues:
 - Investigate added load created by EGP extensions
 - Investigate L1VPN, use of SRLG for consistency, rechartering impacts
 - Propose WG document
 - Zafar - recommended would be a good basis for inter-domain TE framework
 -- Arthi- support effort, but has too many solutions-related aspects in it.
Also suggest separating requirements into signaling, routing and path
computation. Need to clarify what is meant by domain - refer to framework
document.
 -- Dimitri - what about reachability information exchange?  Not addressed,
but will be an important aspect.
 -- Adrian- this is solution, not requirements. Suggest to separate
requirements and solutions. General approval of the work, but need to remove
solutions. Should consider reachability as well as TE aspects.  Restructure
as Arthi suggests.
 -- Otani- agree, will separate
 -- Kireeti summarizing: separate requirements from solution and structure:
signaling from routing (in part. reachability) 

9. Summarize Status and plans of PCE BOF (JP Vasseur) (5 minutes)
 -- Scope issues
 - No intent to come up with new interdomain routing paradigm
 - Scoped applicability to a limited number of TE LSPs
 - Scoped to a "simple" topology of ASes or areas
 -- Previous BOF - clear requirements from many SPs and common theme of
problem - MPLS TE LSP path computation
 -- Architecture - comments noted global picture needed, but no
standardization of architecture.  New revision to be submitted soon in the
meantime please comments!
 -- Note agreed no intention to extend LDP, but possibly other protocols.
 -- Agreed on proposed charter and milestones, proposal to be sent out early
next week.
 -- Many in favor of new WG, none against - need IESG review and work on
charter
 -- Bijan Jabbari - what scale of LSPs?
 -- JP - no specific number, not full mesh - does this mean no scalability
concerns?
 -- Adrian - need to make the problem manageable, at least initially.
 -- Bijan - will WG be open to new architectures?
 -- Kireeti - take this to the list.
 -- Peter Toms - support this, lots of requests for this. 

10. Inter-Domain RSVP-TE extensions - Arthi Ayyangar (5min)
<http://www.ietf.org/internet-drafts/draft-ayyangar-ccamp-inter-domain-rsvp-
te-00.txt>
 -- Changes - include separate section on stitching and required extensions,
clarifications for non-packet LSPs.
 -- Request to make it a WG document - none against, but limited number
agreeing (note: not many read the draft)- list.
 -- Adrian - stitching has wider applicability - should we pull it out into a
separate draft? 

11. Diverse Inter-region Setup - D'Achille - presented by Adrian (5 min)
<http://www.ietf.org/internet-drafts/draft-dachille-inter-region-path-setup-
04.txt> 

 -- Adrian not that familiar with this draft. Flags one slide on message
exchange where the head end is in the center rather than at the end. Notes
several claim, explicitly claim of no new protocol seems questionable as new
objects are defined. Need further feedback.
Can't take questions as no authors present to discuss - take to list 

12. Related to 11.  Protection for Inter-AS tunnels - Decnodder - Cristel
Pelsser
<http://www.ietf.org/internet-drafts/draft-decnodder-ccamp-interas-protectio
n-00.txt>
 -- Differs from 11, addresses requirements from TEWG draft
 -- Uses RSVP-TE and FRR
 -- Adds clarifications on SRLG scope, assumed to correspond to a single AS
 -- Looking for feedback, how to generalize to GMPLS
 -- Adrian - need to apply to GMPLS if you want the draft to be in this
group.
 -- Zafar - SRLG issue - need to solve the scooping issue, applies in a
number of places.
 -- Adrian - WG should look at a framework for diverse paths, including PCE.
 -- Zafar - needs more discussion to understand, and already work in MPLS WG
on ABR protection.
 -- Adrian - authors can continue draft, would also like for CCAMP to
evaluate if PCE is appropriate, or something else
 -- JP - should include the PCE mailing list on this.
 -- Adrian - need discussion on the ccamp list. 

13. Requirements for multi-region - Kohei Shiomoto
<http://www.ietf.org/internet-drafts/draft-shiomoto-ccamp-gmpls-mrn-requirem
ents-00.txt> 

 -- Region defined based on switching capability - note region is control
plane, layer is data plane
 -- Addresses pre-provisioned FA, triggered FA and no FA cases.  Plain and
hybrid type nodes.
 -- Architecture has generated requirements and solutions drafts
 -- Virtual network topology, application example
 -- Propose as WG document.
 -- Adrian - handling regions are in scope of CCAMP.
 -- Adrian - asks Dimitri to immediately present the extensions then we will
take questions
<http://www.ietf.org/internet-drafts/draft-shiomoto-ccamp-gmpls-mrn-extensio
ns-00.txt> 

 -- TE metric inheritance - how to inherit or map metrics
 -- How is recovery abstracted for an FA - e.g., end2end vs. span protected?
 -- Reconvergence of VNT
 -- Handling multiple switching and adaptation capabilities
 -- Zafar - is this a good idea from TE point of view - dynamic FA creation -
need applicability statement - potential bandwidth segmentation issues - may
lose aggregation that you would normally get at the boundary - could add
oscillation.  If still considered a good idea, should it be triggered by
signaling or some other mechanism?  Document needs to list concerns.
 -- Arthi - some parts of requirements still not clear - what is needed
outside of the LSP hierarchy draft?  Need to clarify what is missing from
the existing, and reference where it's covered by existing documents.  Don't
want to reinvent terminology.  Regarding virtual FA setup can be
pre-provisioned or on demand - hierarchy draft already says this, should not
be in the requirements document but only in the solutions document.
Regarding protection - more work needs to be done in the requirements.
 -- Igor - region, layer, hierarchy level are treated interchangeably in the
draft, confusing.  Regarding stitching, this is a very general capability
and should be in LSP hierarchy instead. Kireeti - thinks this should have a
separate document.
 -- Adrian - more clarification would be good on layer/region
 -- Jonathan Sadler - good stuff in general, agree with the goal.  Concern is
that IETF framework is not well aligned to ITU concept of layered network
(G.805).  It would be good to take into account the ITU framework.  Work on
extensions is premature at this time.
 -- Deborah Brungard - authors intended to handle multiple layers as in ITU
(e.g. G.805) - limited to single domain for now, should be addressed to
GMPLS RFCs. Not intended to discuss data plane concepts. Request for more
specific comments. 


14. MPLS-to-GMPLS Migration - Kohei Shiomoto
<http://www.ietf.org/internet-drafts/draft-oki-ccamp-gmpls-ip-interworking-0
4.txt> 

 -- Evolution from legacy MPLS to GMPLS -
 -- Differences: architecture (C/D separation, bidirectionality, P&R);
routing (opaque LSA); signaling (new objects, messages)
 -- Propose WG document
 -- Kireeti - question on whether this is in scope - address on charter
 -- Zafar - multi-layer comments also apply here.
 -- Richard Rabbat - supports the work, suggests looking at odd numbers
rather than even.
 -- Ping Pan - how does this differ from the overlay model?
 -- Kireeti - different, take this to the list. 

15. L1 VPN - Tomonori Takeda (10 Min)
<http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework-02.txt>
<http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-applicability-01.txt
>
<http://www.ietf.org/internet-drafts/draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-05
.txt>
<http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-overlay-05.txt> 

 -- Mailing list - www1.ietf.org/mailman/listinfo/l1vpn
 -- Two drafts applicable, ouldbrahim and overlay - guidelines for
enhancement, deployment scenaros - added terminology refinement, security
considerations, service models
 -- Further comments solicited, planning further liaison to SG13.
 -- Applicability draft examines existing GMPLS protocols for L1 VPN
services. Has added Deborah as co-author.
 -- Concept - set up FA LSP between PEs, use stitching to connect this to
CEs.
 -- Propose to adopt as CCAMP charter item.
 -- Kireeti - supports applicability draft.  Liaison with ITU is very
important - we need to be responsive.  We will discuss this item as part of
the extension of the CCAMP charter 

16. Signaling for L2 LSPs - Dimitri Papadimitriou (10 minutes)
<http://www.ietf.org/internet-drafts/draft-papadimitriou-ccamp-gmpls-l2sc-ls
p-03.txt> 

 -- ATM, FR, ETH, etc.  Defines label request processing, label semantics,
added security section.
 -- Security - threats analysis, attacks on the data plane, L2 LSP signaling,
attacks on control plane
 -- Ask for WG draft, no plan to respin
 -- Dave Allan - Question on Ethernet VLAN tag swapping - not defined in
IEEE.
 -- Dimitri- intended to cover GMPLS scope, not data plane.  Should not
assume tag is per port unique.
 -- Don Fedyk - is this P2P?
 -- Dimitri - Yes (as starting point).
 -- Kireeti - ok, we have a fair consensus, so I would say it's a rough
consensus point. We will take this to the list, Dave and Dimitri to work out
VLAN issue.
 -- Note that an MPLS group draft on L2 has come up 

17. Mesh Carrier Survey - Richard Rabbat (5 min)
<http://www.ietf.org/internet-drafts/draft-rabbat-ccamp-carrier-survey-01.tx
t> 

 -- Initially 7 carriers polled, open to others
 -- Also surveys GMPLS control plane deployment
 -- 1 has deployed, 3 within 2-3 years, 3 with no current plans
 -- Concerns with stability, signaling storms
 -- Asking for feedback, new carrier input
 -- Richard - review slides, recommend for CCAMP WG to begin work on shared
mesh restoration performance 

18. Milestone and Charter discussion - Kireeti 

 -- Current activities winding down, esp. P&R, ASON
 -- Others underway, esp. multi-domain
 -- New: migration, VPNs, control plane resilience, addressing,
implementation experience, GTTP (?)
 -- Migration
 - GMPLS supersets MPLS, but some objects are different - label request,
label, upstream label
 - Need BCP on smooth migration, what issues may occur
 -- L1 VPN
 - Should IETF do this?  Should it be in CCAMP?  Tied to UNI and Interdomain
signaling
 -- Control plane resilience - includes graceful restart but also more
 -- Addressing - transport networks use different kinds of addresses - need
decoder ring for mapping transport network address types to IP addresses -
Kireeti considers this useful
 -- Interop results - note that addressing pops up there as well.  BCPs would
be helpful.
 -- Send out request for new work items, replies due Friday 11/19.
 -- Send out checks for consensus on each item, replies due Friday 12/3
 -- Send resulting list to A-Ds, trimmed if necessary, add appropriate
milestones
 -- Consensus is a requirement but not a guarantee.
 -- Lou - how about dropping something from the existing charter -
 -- Kireeti - maybe GTTP - Lou - should note on the list also things that may
be dropped if no support.
 -- Alex - about L1 VPNs - is this research work, or practical?  Need at
least one implementation - is anyone implementing this within a year or two?
 -- Dimitri - Solutions exist provided by vendors today, but no common
framework.  Timeframe for implementation is 18-24 months.
 -- Alex reminds the group of the need for running code.
 -- Adrian - what about informational draft on how to use existing functions
to do the service?  Is there any interest from the research groups or the
real carrier deployment groups?
 -- Tomonori Takeda - NTT has interest, but not sure of protocols.  Timeframe
 - cannot say.  Testing is done.
 -- Yakov Rekhter- vendors cannot disclose future product plans...
 -- Deborah Brungard - carriers also cannot disclose plans, will see interest
by number of co-authors.
 -- Kireeti - have had carriers ask for this technology.  We don't have all
the pieces, but have implemented many of them, and as a vendor would like to
see a solution on how to do. Answer to Alex is yes.
 -- Richard Rabbat - could add this to his survey.
 -- Kireeti supports this. 

MEETING IS ADJOURNED.



Envelope-to: [e-mail]
Delivery-date: Tue, 30 Nov 2004 12:54:53 +0000
Content-Transfer-Encoding: 7bit
Thread-Topic: New charter
thread-index: AcTW22uCZHoW8Kv5TNGJu3EA1BLg6w==
Reply-To: <[e-mail]>
From: <[e-mail]>
To: "Kireeti Kompella" <[e-mail]>
Cc: <[e-mail]>
Bcc: 
Subject: RE: New charter
Date: Tue, 30 Nov 2004 21:52:24 +0900
Comment: =?ISO-8859-1?B?x9GxucD8wNrF673Fv6yxuL/4LCCxpMD8tN64wcGmvu7GwCwgtOO05w==?=
Message-ID: <12cfc01c4d6db$7089fdd0$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_12CFD_01C4D726.E071A5D0"
Content-Class: urn:content-classes:message

This is a multi-part message in MIME format.

------=_NextPart_000_12CFD_01C4D726.E071A5D0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: base64


------=_NextPart_000_12CFD_01C4D726.E071A5D0
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<DIV id=3Dmsgbody style=3D"FONT-SIZE: 10pt; FONT-FAMILY: System">
<DIV>&nbsp;</DIV>
<DIV>Kireeti,</DIV>
<DIV>&nbsp;</DIV>
<DIV>1) MPLS-GMPLS migration --- Yes<BR>2) GMPLS interoperability issues =
--- Yes<BR>3a) should the IETF take on L1VPNs? --- Yes<BR>3b) if yes to =
3a, should this be done in CCAMP? --- Yes<BR>4) Waveband switching --- =
Yes<BR>5) Control plane work --- Yes<BR>6) Decoder ring for addresses =
--- included in 1) or 2)<BR>7) Deployment considerations for GMPLS --- =
included in 2)<BR>8) PCE requirements ---&nbsp;job of PCE WG (I'm not =
sure)<BR>9) QoS control --- Yes<BR></DIV>
<DIV><FONT size=3D2>Thanks,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>Young</DIV></DIV><img style=3D"display:none" width=3D0 height=3D0 =
src=3D"http://umail.etri.re.kr/External_ReadCheck.aspx?email=3Dccamp@ops.=
ietf.org&name=3Dccamp%40ops.ietf.org&fromemail=[e-mail]&messag=
eid=3D%3C12cfc01c4d6db$7089fdd0$[e-mail]%3E">
------=_NextPart_000_12CFD_01C4D726.E071A5D0--



Envelope-to: [e-mail]
Delivery-date: Mon, 29 Nov 2004 18:00:09 +0000
Date: Mon, 29 Nov 2004 09:58:22 -0800 (PST)
From: Arthi Ayyangar <[e-mail]>
To: Kireeti Kompella <[e-mail]>
cc: [e-mail]
Subject: Re: New charter
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Kireeti,

My pick for the four most important items are:-

o 7) and in order for 7) to work out, we would need to address 1) and 2)
o 3)
o 8)
o 5)

thanks,
-arthi

> Thanks all for your input.  I have the following items; for each,
> please say "Yes" (should be added to CCAMP charter), "No" (should not
> be added) or "-" (don't care).  I'll remind you once again that not
> all items will make it onto the new charter.
>
> Please keep this subject line (simply reply to this mail).  The
> deadline is Friday Dec 3, 17:00 PST.
>
> 1) MPLS-GMPLS migration
> 2) GMPLS interoperability issues
> 3a) should the IETF take on L1VPNs?
> 3b) if yes to 3a, should this be done in CCAMP?
> 4) Waveband switching
> 5) Control plane work
> 6) Decoder ring for addresses
> 7) Deployment considerations for GMPLS
> 8) PCE requirements
> 9) QoS control
>
> A rough idea of what each of the above entails follows.
>
> 1) MPLS-GMPLS migration
> 	implementation shift from "MPLS" objects to "GMPLS" objects
> 	BCP on deployment migration for the same
>
> 2) GMPLS interoperability issues
> 	what addresses to use where
> 	nits/clarifications of the specs
> 	guidelines for path computation & constraints
> 	survay
>
> 3) L1VPN work items
> 	identify protocol extensions needed
> 	state what can already be done with what we have
> 	do the actual protocol work for requirements that are not met
> 	liaisons to SG13 as needed
>
> 5) Control plane work
> 	resiliency
> 	graceful shutdown
>
> 6) Decoder ring for addresses
> 	for each address field, identify its nature and ITU equivalent
> 	(may overlap with part of (2))
>
>
> 4, 7-9 are obvious or have been elaborated on the mailing list.
>
> Kireeti.
> -------
>
> PS: The topic of GTTP has carefully been avoided.  More later.
>



Envelope-to: [e-mail]
Delivery-date: Mon, 29 Nov 2004 13:21:57 +0000
Message-ID: <[e-mail]>
Date: Mon, 29 Nov 2004 14:20:04 +0100
From: [e-mail]
Reply-To: [e-mail]
Organization: Alcatel CTO/R&I
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
MIME-Version: 1.0
To: Kireeti Kompella <[e-mail]>
CC: [e-mail]
Subject: Re: New charter
Content-Type: multipart/alternative; boundary="------------010103010001030401060008"

This is a multi-part message in MIME format.
--------------010103010001030401060008
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed

Hi,

Kireeti Kompella wrote:

>On Mon, 15 Nov 2004, Kireeti Kompella wrote:
>
>  
>
>>If you have suggested charter updates, please send them to Adrian
>>and me.
>>    
>>
>
>Thanks all for your input.  I have the following items; for each,
>please say "Yes" (should be added to CCAMP charter), "No" (should not
>be added) or "-" (don't care).  I'll remind you once again that not
>all items will make it onto the new charter.
>
>Please keep this subject line (simply reply to this mail).  The
>deadline is Friday Dec 3, 17:00 PST.
>
>1) MPLS-GMPLS migration			YES
>2) GMPLS interoperability issues	YES
>3a) should the IETF take on L1VPNs?	YES
>3b) if yes to 3a, should this be done in CCAMP?	YES
>4) Waveband switching			YES
>5) Control plane work			YES
>6) Decoder ring for addresses		cf 2)
>7) Deployment considerations for GMPLS	YES
>8) PCE requirements			YES
>9) QoS control				YES
>  
>

top 4:
1: 1) + 2) + 7)
2: 5)
3: 3) a+b
4: 8)

then

4) and 9)



Emmanuel

>A rough idea of what each of the above entails follows.
>
>1) MPLS-GMPLS migration
>	implementation shift from "MPLS" objects to "GMPLS" objects
>	BCP on deployment migration for the same
>
>2) GMPLS interoperability issues
>	what addresses to use where
>	nits/clarifications of the specs
>	guidelines for path computation & constraints
>	survay
>
>3) L1VPN work items
>	identify protocol extensions needed
>	state what can already be done with what we have
>	do the actual protocol work for requirements that are not met
>	liaisons to SG13 as needed
>
>5) Control plane work
>	resiliency
>	graceful shutdown
>
>6) Decoder ring for addresses
>	for each address field, identify its nature and ITU equivalent
>	(may overlap with part of (2))
>
>
>4, 7-9 are obvious or have been elaborated on the mailing list.
>
>Kireeti.
>-------
>
>PS: The topic of GTTP has carefully been avoided.  More later.
>
>
>  
>


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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi,<br>
<br>
Kireeti Kompella wrote:<br>
<blockquote cite="[e-mail]"
 type="cite">
  <pre wrap="">On Mon, 15 Nov 2004, Kireeti Kompella wrote:

  </pre>
  <blockquote type="cite">
    <pre wrap="">If you have suggested charter updates, please send them to Adrian
and me.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Thanks all for your input.  I have the following items; for each,
please say "Yes" (should be added to CCAMP charter), "No" (should not
be added) or "-" (don't care).  I'll remind you once again that not
all items will make it onto the new charter.

Please keep this subject line (simply reply to this mail).  The
deadline is Friday Dec 3, 17:00 PST.

1) MPLS-GMPLS migration			YES
2) GMPLS interoperability issues	YES
3a) should the IETF take on L1VPNs?	YES
3b) if yes to 3a, should this be done in CCAMP?	YES
4) Waveband switching			YES
5) Control plane work			YES
6) Decoder ring for addresses		cf 2)
7) Deployment considerations for GMPLS	YES
8) PCE requirements			YES
9) QoS control				YES
  </pre>
</blockquote>
<br>
top 4:<br>
1: 1) + 2) + 7)<br>
2: 5)<br>
3: 3) a+b<br>
4: 8)<br>
<br>
then<br>
<br>
4) and 9)<br>
<br>
<br>
<br>
Emmanuel<br>
<br>
<blockquote cite="[e-mail]"
 type="cite">
  <pre wrap="">
A rough idea of what each of the above entails follows.

1) MPLS-GMPLS migration
	implementation shift from "MPLS" objects to "GMPLS" objects
	BCP on deployment migration for the same

2) GMPLS interoperability issues
	what addresses to use where
	nits/clarifications of the specs
	guidelines for path computation &amp; constraints
	survay

3) L1VPN work items
	identify protocol extensions needed
	state what can already be done with what we have
	do the actual protocol work for requirements that are not met
	liaisons to SG13 as needed

5) Control plane work
	resiliency
	graceful shutdown

6) Decoder ring for addresses
	for each address field, identify its nature and ITU equivalent
	(may overlap with part of (2))


4, 7-9 are obvious or have been elaborated on the mailing list.

Kireeti.
-------

PS: The topic of GTTP has carefully been avoided.  More later.


  </pre>
</blockquote>
<br>
</body>
</html>

--------------010103010001030401060008--



Envelope-to: [e-mail]
Delivery-date: Mon, 29 Nov 2004 06:03:04 +0000
Reply-To: <[e-mail]>
From: "Vishal Sharma" <[e-mail]>
To: "Kireeti Kompella" <[e-mail]>, <[e-mail]>
Subject: RE: New charter
Date: Sun, 28 Nov 2004 22:00:20 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Kireeti,

Responses in-line...

-Vishal

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On
> Behalf Of Kireeti Kompella
> Sent: Tuesday, November 23, 2004 10:22 PM
> To: [e-mail]
> Subject: New charter

<snip>

> Please keep this subject line (simply reply to this mail).  The
> deadline is Friday Dec 3, 17:00 PST.
>
> 1) MPLS-GMPLS migration                       Yes
> 2) GMPLS interoperability issues              Yes
> 3a) should the IETF take on L1VPNs?           Yes
> 3b) if yes to 3a, should this be done in CCAMP?   Yes
> 4) Waveband switching                          --
> 5) Control plane work                          Yes
> 6) Decoder ring for addresses                  --
> 7) Deployment considerations for GMPLS         Yes
> 8) PCE requirements                           Shouldn't this be done in
PCE itself??
> 9) QoS control                                Tentative yes, depends on
what is
                                                involved.
>
> A rough idea of what each of the above entails follows.
>
> 1) MPLS-GMPLS migration
> 	implementation shift from "MPLS" objects to "GMPLS" objects
> 	BCP on deployment migration for the same
>
> 2) GMPLS interoperability issues
> 	what addresses to use where
> 	nits/clarifications of the specs
> 	guidelines for path computation & constraints
> 	survay
>
> 3) L1VPN work items
> 	identify protocol extensions needed
> 	state what can already be done with what we have
> 	do the actual protocol work for requirements that are not met
> 	liaisons to SG13 as needed
>
> 5) Control plane work
> 	resiliency
> 	graceful shutdown
>
> 6) Decoder ring for addresses
> 	for each address field, identify its nature and ITU equivalent
> 	(may overlap with part of (2))
>
>
> 4, 7-9 are obvious or have been elaborated on the mailing list.
>
> Kireeti.
> -------
>
> PS: The topic of GTTP has carefully been avoided.  More later.
>




Envelope-to: [e-mail]
Delivery-date: Sun, 28 Nov 2004 07:52:53 +0000
Message-ID: <[e-mail]>
Date: Sun, 28 Nov 2004 08:48:16 +0100
From: Loa Andersson <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803
MIME-Version: 1.0
To: Kireeti Kompella <[e-mail]>
CC: [e-mail], Thomas Narten <[e-mail]>
Subject: Re: New charter
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

  Kireeti,

definitely agree with c :). And I think that a,b and d summarizes
why I've called L1VPNs not Virtual Private Networks but Virutal
PUBLIC Networks (no I'm not suggesting a name change, just want
to point at a crtical difference in service model).

I support doing L1VP(ublic)N in ccamp.

/Loa

PS
Hmmm... no OC48's to end-hosts? Who said that 3 or 4 computers was
all the world needed? Testbeds are today known to do GE to end
stations :)

/Loa


Kireeti Kompella wrote:
> Hi Loa,
> 
> On Fri, 26 Nov 2004, Loa Andersson wrote:
> 
> 
>>there seems to be a majority for doing L1VPN in ccamp, I don't
>>particular object, but remember the arguments when we placed the
>>L3VPN and L2VPN in the Internet Area.
> 
> 
> Thanks for articulating this -- I've been thinking about this as well.
> 
> 
>>The main argument was that the Internet Area deals with end-2-end
>>services over the Interent, thus VPNs belongs in the Internet Area.
>>
>>If we decides that L1VPN don't go together with L2/L3VPNs in the
>>Internet Area we should at least have some motivation for this.
>>What is it?  Is L1VPN not an end-2-end services or is it not an
>>Internet Service?
> 
> 
> I've come up with four reasons why CCAMP is a better venue for L1VPNs:
> 
> a) L1VPNs are definitely not an end-to-end service -- I don't think
>    we'll see end-hosts with OC-48s (or even fiber GE) and GMPLS
>    signaling any time soon.  However, it is clearly possible for end
>    hosts to connect to an L2 or L3VPN.
> b) L1VPNs are not necessarily an Internet service (well, for that
>    matter, neither are L2VPNs).
> c) Most of the work for L1VPNs is done -- starting a new WG for this
>    will hinder progress, and also expand work to fill out a whole WG.
>    The bulk of the work is documenting what we already have that works.
> d) L1VPNs are distinctly different from L2 and L3 VPNs -- in the
>    latter, the PEs do all the heavy lifting, and the CEs are then
>    immediately connected.  In L1VPNs, the PEs do discovery and
>    information exchange, but the *CEs* must do the signaling to set up
>    the (currently) desired CE topology.  To do the signaling, the CEs
>    must exchange information with the PEs.
> 
> This last part requires tight coordination with the CCAMP WG, both for
> signaling (GMPLS UNI), and also for information exchange (pretty much
> the same as for GMPLS inter-domain).  This is for me the most
> important reason why this work should be kept in CCAMP rather than
> creating up a new WG.
> 
> Kireeti.
> -------
> 
> 
> 

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  [phone]
Isafjordsgatan 22                  mobile: [phone]
Kista, Sweden                      email:  [e-mail]
                                            [e-mail]



Envelope-to: [e-mail]
Delivery-date: Sat, 27 Nov 2004 22:57:25 +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: New charter
Date: Sat, 27 Nov 2004 22:56:58 -0000
Message-ID: <[e-mail]>
Thread-Topic: New charter
Thread-Index: AcTUg1DDVtG+bXGmQg+05rOyp+CSfwARIIsg
From: <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>

Hi Scott....good remarks, a couple of observations below:

Scott wrote 27 November 2004 13:13

> On Fri, Nov 26, 2004 02:37:37PM +0100, Loa Andersson allegedly wrote:
> > All,
> >=20
> > there seems to be a majority for doing L1VPN in
> > ccamp, I don't particular object, but remember the arguments when we

> > placed the L3VPN and L2VPN in the Internet Area. The main argument=20
> > was that the Internet Area deals with end-2-end services
> > over the Interent, thus VPNs belongs in the
> > Internet Area.
> >=20
> > If we decides that L1VPN don't go together with
> > L2/L3VPNs in the Internet Area we should at least
> > have some motivation for this. What is it?
> > Is L1VPN not an end-2-end services or is it not
> > an Internet Service?
> >=20
> > /Loa
>=20
> Is it that L2 and L3 VPNs are services on top of the
> infrastructure provided by the network, but L1VPNs can=20
> allocate the infrastructure resources themselves?
NH=3D> I think we as an industry need to start to decoupling ourselves
from this L1/2/3 classification as it has no value.  Any network that
has addressing and routing functional components is a layer network (in
the obsolete/restricted OSI L3 meaning of 'network layer').  IP is a
layer network, and it belongs to the cl-ps mode...which is great.  FR,
ATM and MPLS are layer networks, and these all belong to the co-ps
mode...which is also great.  PDH, SDH and OTNs are also layer networks,
and these all belong to the co-cs mode...and this too is great.  But the
3 network modes are different and trying to apply a 1 size fits all
solution simply won't work.  Indeed, it is the modal differences that
are actually THE important bits, this is where the real value
lies.....so we should not knock this.  If folks want to classify layer
networks they should use these 3 modes and the G.805/809 methods of
describing them.  This is the only classification that makes any logical
and practical sense.


> L1VPNs=20
> aren't (necessarily) "over" anything?
NH=3D> To be accurate we can put any X (layer network/mode) over any Y
(layer network/mode).  Whether its makes real sense to do this (and/or
how many times such transitions should be allowed in some global
reference model) is another question.

>  In G.805-speak, unlike=20
> L2 and L3 VPNs, they aren't necessarily path layer networks.
NH=3D> Scott...when we create a layer network (any) the link connections
in that layer network are invariably formed/supported by trails (which
are end-end entities) in some server layer network.  In turn, the
link-connectines of these server layer trails are supported by even
lower level layer network trails.  This is a recursive behaviour until
we hit the duct.
=20
> It is an end-to-end service, but not necessarily an Internet=20
> service (the control of it is)?
NH=3D> I think some folks have a weird notion of what end-end actually
means. In a layer network end-end means between access points (which are
closely bound to trail termination points).  So one guys end-end network
is some other guys link-connection, ie a 'network builder service' for
example.  End-end is in the eye of the layer network beholder when we
talk of layer networks.  There are 2 end-stops of layer network
recursion however...the duct (obviously) and the customer end-system
applications (like voice, Email, whatever).  But between the application
and the duct there can, and are, many layer networks.

regards, Neil=20



Envelope-to: [e-mail]
Delivery-date: Sat, 27 Nov 2004 17:51:31 +0000
Date: Sat, 27 Nov 2004 09:48:43 -0800 (PST)
From: Kireeti Kompella <[e-mail]>
To: Scott W Brim <[e-mail]>
cc: Loa Andersson <[e-mail]>, [e-mail], Thomas Narten <[e-mail]>
Subject: Re: New charter
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Sat, 27 Nov 2004, Scott W Brim wrote:

> Is it that L2 and L3 VPNs are services on top of the infrastructure
> provided by the network, but L1VPNs can allocate the infrastructure
> resources themselves?

That's a good way of putting it.

> L1VPNs aren't (necessarily) "over" anything?  In G.805-speak, unlike
> L2 and L3 VPNs, they aren't necessarily path layer networks.  It is
> an end-to-end service, but

You'll have to define "end-to-end service" ...

> not necessarily an Internet service (the control of it is)?

Yes, that's also true.

Kireeti.
-------



Envelope-to: [e-mail]
Delivery-date: Sat, 27 Nov 2004 13:15:03 +0000
Date: Sat, 27 Nov 2004 08:12:47 -0500
From: Scott W Brim <[e-mail]>
To: Loa Andersson <[e-mail]>
Cc: [e-mail], Thomas Narten <[e-mail]>, Kireeti Kompella <[e-mail]>
Subject: Re: New charter
Message-ID: <20041127131246.GA1064@sbrim-w2k02>
Mail-Followup-To: Scott W Brim <[e-mail]>, Loa Andersson <[e-mail]>, [e-mail], Thomas Narten <[e-mail]>, Kireeti Kompella <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.1i

On Fri, Nov 26, 2004 02:37:37PM +0100, Loa Andersson allegedly wrote:
> All,
> 
> there seems to be a majority for doing L1VPN in
> ccamp, I don't particular object, but remember the
> arguments when we placed the L3VPN and L2VPN in
> the Internet Area. The main argument was that
> the Internet Area deals with end-2-end services
> over the Interent, thus VPNs belongs in the
> Internet Area.
> 
> If we decides that L1VPN don't go together with
> L2/L3VPNs in the Internet Area we should at least
> have some motivation for this. What is it?
> Is L1VPN not an end-2-end services or is it not
> an Internet Service?
> 
> /Loa

Is it that L2 and L3 VPNs are services on top of the infrastructure
provided by the network, but L1VPNs can allocate the infrastructure
resources themselves?  L1VPNs aren't (necessarily) "over" anything?  In
G.805-speak, unlike L2 and L3 VPNs, they aren't necessarily path layer
networks.  It is an end-to-end service, but not necessarily an Internet
service (the control of it is)?



Envelope-to: [e-mail]
Delivery-date: Sat, 27 Nov 2004 03:14:28 +0000
Date: Fri, 26 Nov 2004 19:11:46 -0800 (PST)
From: Kireeti Kompella <[e-mail]>
To: Loa Andersson <[e-mail]>
cc: [e-mail], Thomas Narten <[e-mail]>
Subject: Re: New charter
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi Loa,

On Fri, 26 Nov 2004, Loa Andersson wrote:

> there seems to be a majority for doing L1VPN in ccamp, I don't
> particular object, but remember the arguments when we placed the
> L3VPN and L2VPN in the Internet Area.

Thanks for articulating this -- I've been thinking about this as well.

> The main argument was that the Internet Area deals with end-2-end
> services over the Interent, thus VPNs belongs in the Internet Area.
>
> If we decides that L1VPN don't go together with L2/L3VPNs in the
> Internet Area we should at least have some motivation for this.
> What is it?  Is L1VPN not an end-2-end services or is it not an
> Internet Service?

I've come up with four reasons why CCAMP is a better venue for L1VPNs:

a) L1VPNs are definitely not an end-to-end service -- I don't think
   we'll see end-hosts with OC-48s (or even fiber GE) and GMPLS
   signaling any time soon.  However, it is clearly possible for end
   hosts to connect to an L2 or L3VPN.
b) L1VPNs are not necessarily an Internet service (well, for that
   matter, neither are L2VPNs).
c) Most of the work for L1VPNs is done -- starting a new WG for this
   will hinder progress, and also expand work to fill out a whole WG.
   The bulk of the work is documenting what we already have that works.
d) L1VPNs are distinctly different from L2 and L3 VPNs -- in the
   latter, the PEs do all the heavy lifting, and the CEs are then
   immediately connected.  In L1VPNs, the PEs do discovery and
   information exchange, but the *CEs* must do the signaling to set up
   the (currently) desired CE topology.  To do the signaling, the CEs
   must exchange information with the PEs.

This last part requires tight coordination with the CCAMP WG, both for
signaling (GMPLS UNI), and also for information exchange (pretty much
the same as for GMPLS inter-domain).  This is for me the most
important reason why this work should be kept in CCAMP rather than
creating up a new WG.

Kireeti.
-------



Envelope-to: [e-mail]
Delivery-date: Fri, 26 Nov 2004 13:41:22 +0000
Message-ID: <[e-mail]>
Date: Fri, 26 Nov 2004 14:37:37 +0100
From: Loa Andersson <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803
MIME-Version: 1.0
To: [e-mail]
CC: Thomas Narten <[e-mail]>, Kireeti Kompella <[e-mail]>
Subject: Re: New charter
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

All,

there seems to be a majority for doing L1VPN in
ccamp, I don't particular object, but remember the
arguments when we placed the L3VPN and L2VPN in
the Internet Area. The main argument was that
the Internet Area deals with end-2-end services
over the Interent, thus VPNs belongs in the
Internet Area.

If we decides that L1VPN don't go together with
L2/L3VPNs in the Internet Area we should at least
have some motivation for this. What is it?
Is L1VPN not an end-2-end services or is it not
an Internet Service?

/Loa

>3a) should the IETF take on L1VPNs? 
> yes.
> 
> 
>>3b) if yes to 3a, should this be done in CCAMP?
> yes.
> 
> Yakov.
> 
> 
> 

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  [phone]
Isafjordsgatan 22                  mobile: [phone]
Kista, Sweden                      email:  [e-mail]
                                            [e-mail]



Envelope-to: [e-mail]
Delivery-date: Fri, 26 Nov 2004 03:41:43 +0000
Message-Id: <[e-mail]>
Date: Fri, 26 Nov 2004 12:39:10 +0900
To: "Kireeti Kompella" <[e-mail]>, <[e-mail]>
From: Wataru Imajuku <[e-mail]>
Subject: Re: New charter
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed
Content-Transfer-Encoding: 7bit

Hi, Kiretti and all

  I think most important issues are

1) MPLS-GMPLS migration
2) GMPLS interoperability issues
3a) should the IETF take on L1VPNs?
3b) if yes to 3a, should this be done in CCAMP?
5) Control plane work
9) QoS control

Next important thing is
4) Waveband switching

  Also, I think we should address to scalability issues.
  Especially for restoration.

  But I'm neutral for following issues,
7) Deployment consi derations for GMPLS
8) PCE requirements

Best Regards,
Wataru

---------------------------------
Wataru Imajuku, Ph.D.
@NTT Network Innovation Labs.
TEL [phone]
FAX [phone] 





Envelope-to: [e-mail]
Delivery-date: Thu, 25 Nov 2004 20:23:27 +0000
Message-Id: <[e-mail]>
To: Kireeti Kompella <[e-mail]>
cc: [e-mail]
Subject: Re: New charter 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Thu, 25 Nov 2004 12:22:52 -0800
From: Yakov Rekhter <[e-mail]>

Kireeti,

> > If you have suggested charter updates, please send them to Adrian
> > and me.
> 
> Thanks all for your input.  I have the following items; for each,
> please say "Yes" (should be added to CCAMP charter), "No" (should not
> be added) or "-" (don't care).  I'll remind you once again that not
> all items will make it onto the new charter.
> 
> Please keep this subject line (simply reply to this mail).  The
> deadline is Friday Dec 3, 17:00 PST.

Top four:

> 
> 1) MPLS-GMPLS migration

yes.

> 2) GMPLS interoperability issues

yes.

> 3a) should the IETF take on L1VPNs?

yes.

> 3b) if yes to 3a, should this be done in CCAMP?

yes.

Yakov.



Envelope-to: [e-mail]
Delivery-date: Thu, 25 Nov 2004 19:51:49 +0000
Message-ID: <[e-mail]>
From: "Lam, Hing-Kam (Kam)" <[e-mail]>
To: "'Adrian Farrel'" <[e-mail]>, "Lam, Hing-Kam (Kam)" <[e-mail]>
Cc: "'Kireeti Kompella'" <[e-mail]>, [e-mail], Bill Fenner <[e-mail]>, Scott Bradner <[e-mail]>, [e-mail], [e-mail]
Subject: RE: Liaison to ITU-T Q14/15 - Comparison of LMP and ASON Discover y
Date: Thu, 25 Nov 2004 14:49:45 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

Dear Mr. Farrel,

Thank you for the Liaison Statement on Comparison of LMP and ASON Discovery. We appreciate the opportunity to provide input to the work. Q14/15 will address the LS in its upcoming meeting next week.

Regards,
Kam Lam, Q14/15 Rapporteur

> -----Original Message-----
> From: Adrian Farrel [mailto:[e-mail]]
> Sent: Thursday, November 25, 2004 9:09 AM
> To: Lam, Hing-Kam (Kam)
> Cc: 'Kireeti Kompella'; [e-mail]; Bill Fenner; Scott Bradner;
> [e-mail]; [e-mail]
> Subject: Liaison to ITU-T Q14/15 - Comparison of LMP and ASON 
> Discovery
> 
> 
> To:           Mr. Kam Lam, Rapporteur for Question 14 of 
> ITU-T Study Group 15.
> 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
>               Scott Bradner, IETF/ITU-T Liaison Coordinator
> For:          Action
> Deadline:     15th December 2004
> Subject:      Comparison of LMP and ASON Discovery
> 
> Dear Mr. Lam,
> 
> The IETF's CCAMP Working Group has been working on a draft to 
> compare LMP as used in a
> GMPLS system with the concept of 'discovery' as expressed in 
> ASON. Many of the people
> actively working on this draft are participants in the ITU-T 
> study groups.
> 
> The abstract of this draft is as follows:
>    The Link Management Protocol (LMP) has been developed as part of
>    the Generalized MPLS (GMPLS) protocol suite to manage Traffic
>    Engineering (TE) links. The GMPLS control plane (routing and
>    signaling) uses TE links for establishing Label Switched Paths
>    (LSPs). This memo describes the relationship of the LMP procedures
>    to 'discovery' as defined in the International Telecommunication
>    Union (ITU), i.e. G.8080, G.7714, and G.7714.1, and on-going ITU-T
>    work. This document provides an overview of LMP in the context of
>    the ITU-T Automatically Switched Optical Networks (ASON) [G.8080]
>    and transport network [G.805] terminology and relates it to the
>    ITU-T discovery work to promote a common understanding for
>    progressing the work of IETF and ITU-T.
> 
> The current version of the draft can be found at
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-transport
-lmp-00.txt

The CCAMP working group intends to carry out a "Working Group Last Call" on this draft.
The Working Group would welcome input from SG15 on this work.

Sincerely,
Kireeti Kompella & Adrian Farrel, CCAMP WG chairs



Envelope-to: [e-mail]
Delivery-date: Thu, 25 Nov 2004 16:29:43 +0000
Message-ID: <[e-mail]>
From: "Marco Carugi" <[e-mail]>
To: [e-mail]
Cc: Kireeti Kompella <[e-mail]>
Subject: RE: New charter
Date: Thu, 25 Nov 2004 17:28:50 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4D30B.D8BD66AE"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C4D30B.D8BD66AE
Content-Type: text/plain

Hello Kireeti.

Top 4:

1) MPLS-GMPLS migration
2) GMPLS interoperability issues
3) L1VPNs (in CCAMP)
8) PCE requirements

Regards, Marco

------_=_NextPart_001_01C4D30B.D8BD66AE
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2658.2">
<TITLE>RE: New charter</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Hello Kireeti.</FONT>
</P>

<P><FONT SIZE=2>Top 4:</FONT>
</P>

<P><FONT SIZE=2>1) MPLS-GMPLS migration</FONT>
<BR><FONT SIZE=2>2) GMPLS interoperability issues</FONT>
<BR><FONT SIZE=2>3) L1VPNs (in CCAMP)</FONT>
<BR><FONT SIZE=2>8) PCE requirements</FONT>
</P>

<P><FONT SIZE=2>Regards, Marco</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C4D30B.D8BD66AE--



Envelope-to: [e-mail]
Delivery-date: Thu, 25 Nov 2004 15:48:28 +0000
Message-ID: <001801c4d2fd$abb8f280$0601a8c0@pc6>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: "Kireeti Kompella" <[e-mail]>, <[e-mail]>
Subject: Re: New charter
Date: Thu, 25 Nov 2004 11:09:51 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

> 1) yes  MPLS-GMPLS migration
> 2) yes  GMPLS interoperability issues
> 3a) no should the IETF take on L1VPNs?
> 3b) no  if yes to 3a, should this be done in CCAMP?
> 4) no   Waveband switching
> 5) yes  Control plane work
> 6) no   Decoder ring for addresses
> 7) yes  Deployment considerations for GMPLS
> 8) no   PCE requirements
> 9) no   QoS control
> 

Tom Petch
NW Networks




Envelope-to: [e-mail]
Delivery-date: Thu, 25 Nov 2004 14:19:42 +0000
Message-ID: <028701c4d2f8$5b7b8300$ec919ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Lam, Hing-Kam (Kam)" <[e-mail]>
Cc: "'Kireeti Kompella'" <[e-mail]>, <[e-mail]>, "Bill Fenner" <[e-mail]>, "Scott Bradner" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Liaison to ITU-T Q14/15 - Comparison of LMP and ASON Discovery
Date: Thu, 25 Nov 2004 14:09:05 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

To:           Mr. Kam Lam, Rapporteur for Question 14 of ITU-T Study Group 15.
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
              Scott Bradner, IETF/ITU-T Liaison Coordinator
For:          Action
Deadline:     15th December 2004
Subject:      Comparison of LMP and ASON Discovery

Dear Mr. Lam,

The IETF's CCAMP Working Group has been working on a draft to compare LMP as used in a
GMPLS system with the concept of 'discovery' as expressed in ASON. Many of the people
actively working on this draft are participants in the ITU-T study groups.

The abstract of this draft is as follows:
   The Link Management Protocol (LMP) has been developed as part of
   the Generalized MPLS (GMPLS) protocol suite to manage Traffic
   Engineering (TE) links. The GMPLS control plane (routing and
   signaling) uses TE links for establishing Label Switched Paths
   (LSPs). This memo describes the relationship of the LMP procedures
   to 'discovery' as defined in the International Telecommunication
   Union (ITU), i.e. G.8080, G.7714, and G.7714.1, and on-going ITU-T
   work. This document provides an overview of LMP in the context of
   the ITU-T Automatically Switched Optical Networks (ASON) [G.8080]
   and transport network [G.805] terminology and relates it to the
   ITU-T discovery work to promote a common understanding for
   progressing the work of IETF and ITU-T.

The current version of the draft can be found at
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-transport-lmp-00.txt

The CCAMP working group intends to carry out a "Working Group Last Call" on this draft.
The Working Group would welcome input from SG15 on this work.

Sincerely,
Kireeti Kompella & Adrian Farrel, CCAMP WG chairs



Envelope-to: [e-mail]
Delivery-date: Thu, 25 Nov 2004 14:19:34 +0000
Message-ID: <028301c4d2f8$3530ced0$ec919ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Working group last call on draft-ietf-ccamp-tranport-lmp-00.txt
Date: Thu, 25 Nov 2004 14:08:04 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

http://www.ietf.org/internet-drafts/draft-ietf-ccamp-transport-lmp-00.txt

The authors tell me that this draft is cooked.
There may be future changes in the ITU-T that would require to be reflected in this work,
but at the moment it is the opinion of the authors that the I-D reflects the current set
of consented recommendations within the ITU-T.

I am liaising the current version of the I-D to ITU-T Study Group 15, Question 14 that has
responsibility for ASON Discovery, and I hope that they will spot any discrepancies that
may exist.

This email begins an elongated WG last call that will end on December 17th at noon GMT.
The unusually long last call period is to allow the ITU-T to return its comments.

Please review and comment on the draft with a view to accuracy, clarity and usability.

Thanks,
Adrian




Envelope-to: [e-mail]
Delivery-date: Thu, 25 Nov 2004 13:56:12 +0000
Message-ID: <[e-mail]>
From: "Hamid Ould-Brahim" <[e-mail]>
To: Kireeti Kompella <[e-mail]>
Cc: [e-mail]
Subject: RE: New charter
Date: Thu, 25 Nov 2004 08:54:34 -0500

Top 4:

3) L1VPNs (in CCAMP)
8) PCE requirements
1) MPLS-GMPLS migration
2) GMPLS interoperability issues

Hamid.



Envelope-to: [e-mail]
Delivery-date: Thu, 25 Nov 2004 10:39:40 +0000
Message-ID: <[e-mail]>
Date: Thu, 25 Nov 2004 19:40:09 +0900
From: Tomohiro Otani <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.7.2) Gecko/20040803
MIME-Version: 1.0
To: Kireeti Kompella <[e-mail]>
Cc: [e-mail]
Subject: Re: New charter
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Kireeti,

I support them rechartered in CCAMP WG and am personally
interested in MPLS/GMPLS migration and deployment consideration
of GMPLS to accelerate actual GMPLS deployment.

CCAMP WG is suitable for discussing about L1VPN.

With best regards,

tomo

----------------------------------
Tomohiro Otani
KDDI R&D Laboratories, Inc.
----------------------------------



Kireeti Kompella wrote:

>On Mon, 15 Nov 2004, Kireeti Kompella wrote:
>
>> If you have suggested charter updates, please send them to Adrian
>> and me.
>
>Thanks all for your input.  I have the following items; for each,
>please say "Yes" (should be added to CCAMP charter), "No" (should not
>be added) or "-" (don't care).  I'll remind you once again that not
>all items will make it onto the new charter.
>
>Please keep this subject line (simply reply to this mail).  The
>deadline is Friday Dec 3, 17:00 PST.
>
>1) MPLS-GMPLS migration
>2) GMPLS interoperability issues
>3a) should the IETF take on L1VPNs?
>3b) if yes to 3a, should this be done in CCAMP?
>4) Waveband switching
>5) Control plane work
>6) Decoder ring for addresses
>7) Deployment considerations for GMPLS
>8) PCE requirements
>9) QoS control
>
>A rough idea of what each of the above entails follows.
>
>1) MPLS-GMPLS migration
>	implementation shift from "MPLS" objects to "GMPLS" objects
>	BCP on deployment migration for the same
>
>2) GMPLS interoperability issues
>	what addresses to use where
>	nits/clarifications of the specs
>	guidelines for path computation & constraints
>	survay
>
>3) L1VPN work items
>	identify protocol extensions needed
>	state what can already be done with what we have
>	do the actual protocol work for requirements that are not met
>	liaisons to SG13 as needed
>
>5) Control plane work
>	resiliency
>	graceful shutdown
>
>6) Decoder ring for addresses
>	for each address field, identify its nature and ITU equivalent
>	(may overlap with part of (2))
>
>
>4, 7-9 are obvious or have been elaborated on the mailing list.
>
>Kireeti.
>-------
>
>PS: The topic of GTTP has carefully been avoided.  More later.
>
>
>  
>




Envelope-to: [e-mail]
Delivery-date: Thu, 25 Nov 2004 10:39:18 +0000
Message-ID: <[e-mail]>
Date: Thu, 25 Nov 2004 19:38:50 +0900
From: Tomohiro Otani <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.7.2) Gecko/20040803
MIME-Version: 1.0
To: Kireeti Kompella <[e-mail]>
Cc: [e-mail]
Subject: Re: New charter
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Kireeti,

I support them rechartered in CCAMP WG and am personally
intereted in MPLS/GMPLS migration and deployment consideration
of GMPLS to accelarate actualGMPLS deployment.

CCAMP WG is suitable for discussing about L1VPN.

With best regards,

tomo

----------------------------------
Tomohiro Otani
KDDI R&D Laboratories, Inc.
----------------------------------


Kireeti Kompella wrote:

>On Mon, 15 Nov 2004, Kireeti Kompella wrote:
>
>> If you have suggested charter updates, please send them to Adrian
>> and me.
>
>Thanks all for your input.  I have the following items; for each,
>please say "Yes" (should be added to CCAMP charter), "No" (should not
>be added) or "-" (don't care).  I'll remind you once again that not
>all items will make it onto the new charter.
>
>Please keep this subject line (simply reply to this mail).  The
>deadline is Friday Dec 3, 17:00 PST.
>
>1) MPLS-GMPLS migration
>2) GMPLS interoperability issues
>3a) should the IETF take on L1VPNs?
>3b) if yes to 3a, should this be done in CCAMP?
>4) Waveband switching
>5) Control plane work
>6) Decoder ring for addresses
>7) Deployment considerations for GMPLS
>8) PCE requirements
>9) QoS control
>
>A rough idea of what each of the above entails follows.
>
>1) MPLS-GMPLS migration
>	implementation shift from "MPLS" objects to "GMPLS" objects
>	BCP on deployment migration for the same
>
>2) GMPLS interoperability issues
>	what addresses to use where
>	nits/clarifications of the specs
>	guidelines for path computation & constraints
>	survay
>
>3) L1VPN work items
>	identify protocol extensions needed
>	state what can already be done with what we have
>	do the actual protocol work for requirements that are not met
>	liaisons to SG13 as needed
>
>5) Control plane work
>	resiliency
>	graceful shutdown
>
>6) Decoder ring for addresses
>	for each address field, identify its nature and ITU equivalent
>	(may overlap with part of (2))
>
>
>4, 7-9 are obvious or have been elaborated on the mailing list.
>
>Kireeti.
>-------
>
>PS: The topic of GTTP has carefully been avoided.  More later.
>
>
>  
>




Envelope-to: [e-mail]
Delivery-date: Thu, 25 Nov 2004 08:55:59 +0000
To: "Ong, Lyndon" <[e-mail]>
Cc: "'Igor Bryskin'" <[e-mail]>, [e-mail], [e-mail], [e-mail]
MIME-Version: 1.0
From: [e-mail]
Subject: RE: RS-DT Wrap-Up Statements
Date: Thu, 25 Nov 2004 09:55:20 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: base64

PFA+bHluZG9uIDxCUj48QlI+PEZPTlQgU0laRT0yPjxCPiZxdW90O09uZywgTHluZG9uJnF1b3Q7
ICZsdDtMeW9uZ0BDaWVuYS5jb20mZ3Q7PC9CPjwvRk9OVD48QlI+PEZPTlQgU0laRT0yPlNlbnQg
Ynk6IG93bmVyLWNjYW1wQG9wcy5pZXRmLm9yZzwvRk9OVD48QlI+PEZPTlQgU0laRT0yPjExLzI0
LzIwMDQgMjA6MTYgRVNUPC9GT05UPjxCUj48QlI+IDxGT05UIFNJWkU9Mj5Ubzo8L0ZPTlQ+IDxG
T05UIFNJWkU9Mj4mcXVvdDsnSWdvciBCcnlza2luJyZxdW90OyAmbHQ7aWJyeXNraW5AbW92YXou
Y29tJmd0OywgZHBhcGFkaW1pdHJpb3VAcHNnLmNvbSwgRGltaXRyaSBQQVBBRElNSVRSSU9VL0JF
L0FMQ0FURUxAQUxDQVRFTDwvRk9OVD48QlI+IDxGT05UIFNJWkU9Mj5jYzo8L0ZPTlQ+IDxGT05U
IFNJWkU9Mj5EaW1pdHJpIFBBUEFESU1JVFJJT1UvQkUvQUxDQVRFTEBBTENBVEVMLCBjY2FtcEBv
cHMuaWV0Zi5vcmc8L0ZPTlQ+PEJSPiA8Rk9OVCBTSVpFPTI+YmNjOjwvRk9OVD4gPEJSPiA8Rk9O
VCBTSVpFPTI+U3ViamVjdDo8L0ZPTlQ+IDxGT05UIFNJWkU9Mj5SRTogUlMtRFQgV3JhcC1VcCBT
dGF0ZW1lbnRzPC9GT05UPjxCUj4gPEJSPjxCUj48L1A+PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNl
LENvdXJpZXIiPkhpIElnb3IsPEJSPjwvRk9OVD48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENv
dXJpZXIiPkkgc3VwcG9ydCB5b3Ugb24gYm90aCBwb2ludHMsIGFuZCBJIGJlbGlldmU8QlI+RGlt
aXRyaSdzIHdyaXRldXAgaXMgaW50ZW5kZWQgdG8gYWxsb3cgdGhlPEJSPnNlcGFyYXRpb24gb2Yg
cm91dGluZyBhbmQgc2lnbmFsaW5nIGNvbnRyb2xsZXJzLjxCUj48L0ZPTlQ+PC9QPjxQPjxGT05U
IEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5bZHBdIHNob3J0IHJlbWluZGVyLCB0aGlzIGlzIHRo
ZSBEVCB3cml0ZS11cDwvRk9OVD48L1A+PFA+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3Vy
aWVyIj5UaGUgaXNzdWUgb2YgdGhlIHJvdXRlciBJRCBvciBsaW5rIElEIGJlaW5nPEJSPnJvdXRh
YmxlIHNlZW1zIHRvIGJlIGluZ3JhaW5lZCBpbiAzNDc3LCBhdDxCUj50aGUgc2FtZSB0aW1lIEkg
YW0gYWxzbyB1bmNvbWZvcnRhYmxlIGFib3V0PEJSPnRoaXMgcmVxdWlyZW1lbnQsIGlmIHRoZSB0
cmFuc3BvcnQgbm9kZTxCUj5kb2VzIG5vdCBzdXBwb3J0IFBTQy48L0ZPTlQ+PC9QPjxQPjxGT05U
IEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5bZHBdIGlzIFJGQyAzNDc3IGFwcGxpY2FibGUgdG8g
bm9uLVBTQyAtIGFzIG9mIHRvZGF5IHllczxCUj48L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9z
cGFjZSxDb3VyaWVyIj5DaGVlcnMsPEJSPjwvRk9OVD48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNl
LENvdXJpZXIiPkx5bmRvbjxCUj48L0ZPTlQ+PEJSPjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2Us
Q291cmllciI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08QlI+RnJvbTogSWdvciBCcnlza2lu
IFttYWlsdG86aWJyeXNraW5AbW92YXouY29tXTxCUj5TZW50OiBXZWRuZXNkYXksIE5vdmVtYmVy
IDI0LCAyMDA0IDg6MjkgQU08QlI+VG86IGRwYXBhZGltaXRyaW91QHBzZy5jb207IGRpbWl0cmku
cGFwYWRpbWl0cmlvdUBhbGNhdGVsLmJlPEJSPkNjOiBkaW1pdHJpLnBhcGFkaW1pdHJpb3VAYWxj
YXRlbC5iZTsgY2NhbXBAb3BzLmlldGYub3JnPEJSPlN1YmplY3Q6IFJlOiBSUy1EVCBXcmFwLVVw
IFN0YXRlbWVudHM8QlI+PC9GT05UPjxCUj48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJp
ZXIiPmRpbWl0cmksIHNlZSBpbi1saW5lPEJSPjwvRk9OVD48QlI+PEZPTlQgRkFDRT0iTW9ub3Nw
YWNlLENvdXJpZXIiPi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS08QlI+RnJvbTogJnF1b3Q7
ZGltaXRyaSBwYXBhZGltaXRyaW91JnF1b3Q7ICZsdDtkcGFwYWRpbWl0cmlvdUBwc2cuY29tJmd0
OzxCUj5UbzogJnF1b3Q7SWdvciBCcnlza2luJnF1b3Q7ICZsdDtpYnJ5c2tpbkBtb3Zhei5jb20m
Z3Q7PEJSPkNjOiAmbHQ7ZGltaXRyaS5wYXBhZGltaXRyaW91QGFsY2F0ZWwuYmUmZ3Q7ICZsdDtj
Y2FtcEBvcHMuaWV0Zi5vcmcmZ3Q7PEJSPlNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgMjQsIDIw
MDQgMTE6MDIgQU08QlI+U3ViamVjdDogUmU6IFJTLURUIFdyYXAtVXAgU3RhdGVtZW50czxCUj48
L0ZPTlQ+PEJSPjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+Jmd0OyBpZ29yIC0g
c2VlIGluLWxpbmU6PEJSPiZndDs8QlI+Jmd0OyBJZ29yIEJyeXNraW4gd3JvdGU6PEJSPiZndDs8
QlI+Jmd0OyAmZ3Q7IERpbWl0cmksPEJSPiZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgRG8geW91IHRo
aW5rIGl0IGlzIHJlYXNvbmFibGUvcHJhY3RpY2FsIHRvIHNlcGFyYXRlIHJvdXRpbmcgY29udHJv
bGxlcjxCUj5mcm9tPEJSPiZndDsgJmd0OyBzaWduYWxpbmcgY29udHJvbGxlciBhbmQgY29uc2lk
ZXIgc2NlbmFyaW9zIHN1Y2ggYXMgYSBzaW5nbGUgcm91dGluZzxCUj4mZ3Q7ICZndDsgY29udHJv
bGxlciBtYW5hZ2VzIChwcm92aWRlcyBhZHZlcnRpc2VtZW50cykgZm9yIHNldmVyYWwgdHJhbnNw
b3J0IG5vZGVzPEJSPiZndDsgJmd0OyB3aXRoIGVhY2ggb2YgdGhlIGxhdHRlciBoYXZpbmcgYSBk
ZWRpY2F0ZWQgc2lnbmFsaW5nIGNvbnRyb2xsZXIgZm9yIFRFPEJSPiZndDsgJmd0OyB0dW5uZWwg
cHJvdmlzaW9uaW5nPzxCUj4mZ3Q7PEJSPiZndDsgdGhpcyBpcyBhICZxdW90O2Z1bmN0aW9uYWwm
cXVvdDsgc2VwYXJhdGlvbiAtIGluIHRoZSBiYXNpYyBhc3NvY2lhdGlvbiBTaSAmbHQ7LSZndDsg
Umk8QlI+Jmd0OyAmbHQ7LSZndDsgaSwgd2UgcmV0cmlldmUgdGhlIGNhbm9uaWNhbCBMU1IgKG5v
dGUgaSB3aWxsIGNoYW5nZSB0aGUgd29yZCAmcXVvdDtjYW4mcXVvdDs8QlI+Jmd0OyBieSAmcXVv
dDttYXkmcXVvdDsgaW4gdGhlIGJlbG93IGluZm9ybWF0aW9uYWwgc3RhdGVtZW50KTxCUj48L0ZP
TlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5JQiZndDsmZ3Q7IFNlcGFyYXRp
b24gY291bGQgYmUgcGh5c2ljYWwsIG5vdCBqdXN0IGZ1bmN0aW9uYWwuIENvbnNpZGVyLCBmb3I8
QlI+aW5zdGFuY2UsIGEgdHJhbnNwb3J0IG5ldHdvcmsgYnVpbHQgb2YgV1hDcyB0aGF0IGRvIG5v
dCBoYXZlIG93biBjb250cm9sPEJSPnBsYW5lLiBJbiB0aGlzIGNhc2UgYSByb3V0aW5nIGNvbnRy
b2xsZXIgbWFuYWdpbmcgb25lIG9yIHNldmVyYWwgc3VjaCBXWENzPEJSPmNvdWxkIGFkdmVydGlz
ZSB0aGVpciByZXNvdXJjZXMsIHdoaWxlIHNlcGFyYXRlIHNpZ25hbGluZyBjb250cm9sbGVycyB3
aXRoPEJSPnRoZSBoZWxwIG9mIFBDRShzKSBjb3VsZCBjb21wdXRlIGFuZCBzaWduYWwgVEUgcGF0
aHMgZm9yIHRoZW0uPEJSPjwvRk9OVD48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIi
PiZndDs8QlI+Jmd0OyAmZ3Q7IEFsc28sIGhvdyBpbiB5b3VyIG9waW5pb24gYSBzaWduYWxpbmcg
Y29udHJvbGxlciBrbm93cyB3aGljaCBhZGRyZXNzIHRvPEJSPnNlbmQ8QlI+Jmd0OyAmZ3Q7IFBh
dGggbWVzc2FnZSBmb3IgdGhlIG5leHQgaG9wIGFsb25nIHRoZSBwYXRoLjxCUj4mZ3Q7ICZndDsg
UG9zc2libGUgb3B0aW9uczo8QlI+Jmd0OyAmZ3Q7IGEpIElEIG9mIGEgbnVtYmVyZWQgbGluayBp
cyByb3V0YWJsZSBvciBSb3V0ZXJJRCBpbiB1bm51bWJlcmVkIEVSTzxCUj4mZ3Q7ICZndDsgc3Vi
LW9iamVjdCAod2hpY2ggaXMgdHJhbnNwb3J0IG5vZGUgSUQpIGlzIHJvdXRhYmxlOzxCUj4mZ3Q7
PEJSPiZndDsgc2V2ZXJhbCBwb2ludHMgaGVyZTo8QlI+Jmd0OyAxLiB3ZSByZWZlciB0byBhICZx
dW90O1RFIFJvdXRlcl9JRCZxdW90OyBwZXIgUkZDIDM0NzcgcmVjb21tZW5kYXRpb248QlI+Jmd0
OyAyLiB3ZSBzaG91bGQgaW5kaWNhdGUgdGhlc2UgJnF1b3Q7aWRlbnRpZmllcnMmcXVvdDsgYXJl
IFRFIHJlYWNoYWJsZSBpbiB0aGUgc2NvcGU8QlI+Jmd0OyAmbmJzcDsgJm5ic3A7IG9mIHRoZSBj
b3ZlcmVkIGFwcGxpY2F0aW9uPEJSPiZndDsgMy4gZXZlbiBpZiByZWxldmFudCB0aGUgc2NvcGUg
b2YgdGhpcyBpcyByZWxhdGVkIHRvIHJvdXRpbmc8QlI+Jmd0OzxCUj4mZ3Q7ICZndDsgYikgbmVj
ZXNzYXJ5IGJpbmRpbmcgKG5laWdoYm9yIGxpbmtJRD0mZ3Q7IG5laWdoYm9yIHNpZ25hbGluZyBh
ZGRyZXNzLDxCUj5uZWlnaGJvcjxCUj4mZ3Q7ICZndDsgbm9kZUlEPSZndDsgbmVpZ2hib3Igc2ln
bmFsaW5nIGFkZHJlc3MpIGlzIHByb3ZpZGVkIHZpYSBMTVA8QlI+Jmd0OzxCUj4mZ3Q7IGluIHRo
ZSBjYXNlIG9mIG11bHRpcGxlIGFzc29jaWF0aW9uIGFuIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24g
aXM8QlI+Jmd0OyByZXF1aXJlZCB0aGF0IGZhbGxzIGJleW9uZCB0aGUgc2NvcGUgb2Ygcm91dGlu
ZyBhbmQgdGhhdCBjb3VsZCBiZTxCUj4mZ3Q7IGFjaGlldmVkIHVzaW5nIExNUDxCUj4mZ3Q7PEJS
PjwvRk9OVD48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPklCJmd0OyZndDsgUGVy
c29uYWxseSwgSSBkb24ndCBsaWtlIHRoZSBhc3N1bXB0aW9uIHRoYXQgdHJhbnNwb3J0IG5vZGUg
SURzIGFuZDxCUj5saW5rSURzIG9mIG51bWJlcmVkIGxpbmtzIGFyZSByb3V0YWJsZSAoZXNwZWNp
YWxseSBpbiB0aGUgY29udGV4dCBvZiBub24tUFNDPEJSPm5ldHdvcmtzKSBhbmQgcHJlZmVyIHJl
bHlpbmcgb24gTE1QIG9yIHNvbWUgb3RoZXIgbmVpZ2hib3IgYXV0by0tZGlzY292ZXJ5PEJSPm1l
Y2hhbmlzbS48QlI+PC9GT05UPjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+SWdv
cjxCUj48L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj4mZ3Q7IGhvcGUg
dGhpcyBjbGFyaWZpZXMsPEJSPiZndDsgLSB0aGFua3MuPEJSPiZndDs8QlI+Jmd0OyAmZ3Q7IFRo
YW5rcyw8QlI+Jmd0OyAmZ3Q7IElnb3I8QlI+Jmd0OyAmZ3Q7PEJSPiZndDsgJmd0OzwvRk9OVD48
L1A+



Envelope-to: [e-mail]
Delivery-date: Thu, 25 Nov 2004 08:24:18 +0000
Date: Thu, 25 Nov 2004 17:22:51 +0900
From: Eiji Oki <[e-mail]>
To: Kireeti Kompella <[e-mail]>
Subject: Re: New charter
Cc: [e-mail]
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Hi Kireeti and all, 

Most important items: 
1) MPLS-GMPLS migration
2) GMPLS interoperability issues
3) L1VPNs in CCAMP
8) PCE requirements

Next important items: 
7) Deployment considerations for GMPLS

Thank you.
Eiji

On Tue, 23 Nov 2004 22:22:19 -0800 (PST)
Kireeti Kompella <[e-mail]> wrote:

> On Mon, 15 Nov 2004, Kireeti Kompella wrote:
> 
> > If you have suggested charter updates, please send them to Adrian
> > and me.
> 
> Thanks all for your input.  I have the following items; for each,
> please say "Yes" (should be added to CCAMP charter), "No" (should not
> be added) or "-" (don't care).  I'll remind you once again that not
> all items will make it onto the new charter.
> 
> Please keep this subject line (simply reply to this mail).  The
> deadline is Friday Dec 3, 17:00 PST.
> 
> 1) MPLS-GMPLS migration
> 2) GMPLS interoperability issues
> 3a) should the IETF take on L1VPNs?
> 3b) if yes to 3a, should this be done in CCAMP?
> 4) Waveband switching
> 5) Control plane work
> 6) Decoder ring for addresses
> 7) Deployment considerations for GMPLS
> 8) PCE requirements
> 9) QoS control
> 
> A rough idea of what each of the above entails follows.
> 
> 1) MPLS-GMPLS migration
> 	implementation shift from "MPLS" objects to "GMPLS" objects
> 	BCP on deployment migration for the same
> 
> 2) GMPLS interoperability issues
> 	what addresses to use where
> 	nits/clarifications of the specs
> 	guidelines for path computation & constraints
> 	survay
> 
> 3) L1VPN work items
> 	identify protocol extensions needed
> 	state what can already be done with what we have
> 	do the actual protocol work for requirements that are not met
> 	liaisons to SG13 as needed
> 
> 5) Control plane work
> 	resiliency
> 	graceful shutdown
> 
> 6) Decoder ring for addresses
> 	for each address field, identify its nature and ITU equivalent
> 	(may overlap with part of (2))
> 
> 
> 4, 7-9 are obvious or have been elaborated on the mailing list.
> 
> Kireeti.
> -------
> 
> PS: The topic of GTTP has carefully been avoided.  More later.





Envelope-to: [e-mail]
Delivery-date: Thu, 25 Nov 2004 04:44:59 +0000
Message-Id: <[e-mail]>
Date: Thu, 25 Nov 2004 13:44:29 +0900
To: Kireeti Kompella <[e-mail]>
From: Tomonori TAKEDA <[e-mail]>
Subject: Re: New charter
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

IMO, all items are important, but here is my vote.

Top four:
1) MPLS-GMPLS migration
2) GMPLS interoperability issues
3) L1VPNs (and yes in CCAMP)
8) PCE requirements

Next:
5) Control plane work

At 08:21 04/11/24 -0800, Kireeti Kompella wrote:
>On Wed, 24 Nov 2004, Loa Andersson wrote:
>
> > not entirely happy to let the IESG do the pruning,
>
>Okay, Loa -- you are right.
>
>All: instead of Yes/No, can you pick the four most important items
>from your point of view?  Thanks!
>
>(To those who already replied, sorry to make you do this again!)
>
>Kireeti.
>-------

-----
Tomonori TAKEDA
NTT Network Service Systems Lab.
Phone: [phone]




Envelope-to: [e-mail]
Delivery-date: Thu, 25 Nov 2004 02:06:37 +0000
Message-ID: <[e-mail]>
Date: Thu, 25 Nov 2004 11:05:39 +0900
From: Kohei Shiomoto <[e-mail]>
Organization: NTT
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
MIME-Version: 1.0
To: Kireeti Kompella <[e-mail]>
CC: [e-mail]
Subject: Re: New charter
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hi Kireeti and all,

All items look important but I would propose the following items.
----- top four ----------
1+7 (they are related)
2+6* (they seem related)
3 (within CCAMP)
8
*note 5 seems related to 2+6
----- next ---------------
9 if 8 is done in PCE-WG.

-------------------
1) MPLS-GMPLS migration
2) GMPLS interoperability issues
3a) should the IETF take on L1VPNs?
3b) if yes to 3a, should this be done in CCAMP?
4) Waveband switching
5) Control plane work
6) Decoder ring for addresses
7) Deployment considerations for GMPLS
8) PCE requirements
9) QoS control


Kind regards

---
Kohei Shiomoto, NTT


Kireeti Kompella wrote:

>On Mon, 15 Nov 2004, Kireeti Kompella wrote:
>
>  
>
>>If you have suggested charter updates, please send them to Adrian
>>and me.
>>    
>>
>
>Thanks all for your input.  I have the following items; for each,
>please say "Yes" (should be added to CCAMP charter), "No" (should not
>be added) or "-" (don't care).  I'll remind you once again that not
>all items will make it onto the new charter.
>
>Please keep this subject line (simply reply to this mail).  The
>deadline is Friday Dec 3, 17:00 PST.
>
>1) MPLS-GMPLS migration
>2) GMPLS interoperability issues
>3a) should the IETF take on L1VPNs?
>3b) if yes to 3a, should this be done in CCAMP?
>4) Waveband switching
>5) Control plane work
>6) Decoder ring for addresses
>7) Deployment considerations for GMPLS
>8) PCE requirements
>9) QoS control
>
>A rough idea of what each of the above entails follows.
>
>1) MPLS-GMPLS migration
>	implementation shift from "MPLS" objects to "GMPLS" objects
>	BCP on deployment migration for the same
>
>2) GMPLS interoperability issues
>	what addresses to use where
>	nits/clarifications of the specs
>	guidelines for path computation & constraints
>	survay
>
>3) L1VPN work items
>	identify protocol extensions needed
>	state what can already be done with what we have
>	do the actual protocol work for requirements that are not met
>	liaisons to SG13 as needed
>
>5) Control plane work
>	resiliency
>	graceful shutdown
>
>6) Decoder ring for addresses
>	for each address field, identify its nature and ITU equivalent
>	(may overlap with part of (2))
>
>
>4, 7-9 are obvious or have been elaborated on the mailing list.
>
>Kireeti.
>-------
>
>PS: The topic of GTTP has carefully been avoided.  More later.
>
>
>  
>

-- 
Kohei Shiomoto, Ph.D
NTT Network Service Systems Laboratories
3-9-11 Midori, Musashino, Tokyo 180-8585, Japan
Phone [phone]    Fax [phone]






Envelope-to: [e-mail]
Delivery-date: Thu, 25 Nov 2004 01:11:31 +0000
Message-ID: <[e-mail]>
From: "Ong, Lyndon" <[e-mail]>
To: 'Igor Bryskin' <[e-mail]>, [e-mail],  [e-mail]
Cc: [e-mail], [e-mail]
Subject: RE: RS-DT Wrap-Up Statements
Date: Wed, 24 Nov 2004 20:16:42 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

Hi Igor,

I support you on both points, and I believe
Dimitri's writeup is intended to allow the
separation of routing and signaling controllers.

The issue of the router ID or link ID being 
routable seems to be ingrained in 3477, at
the same time I am also uncomfortable about
this requirement, if the transport node
does not support PSC.

Cheers,

Lyndon


-----Original Message-----
From: Igor Bryskin [mailto:[e-mail]]
Sent: Wednesday, November 24, 2004 8:29 AM
To: [e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]
Subject: Re: RS-DT Wrap-Up Statements


dimitri, see in-line

----- Original Message ----- 
From: "dimitri papadimitriou" <[e-mail]>
To: "Igor Bryskin" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
Sent: Wednesday, November 24, 2004 11:02 AM
Subject: Re: RS-DT Wrap-Up Statements


> igor - see in-line:
>
> Igor Bryskin wrote:
>
> > Dimitri,
> >
> > Do you think it is reasonable/practical to separate routing controller
from
> > signaling controller and consider scenarios such as a single routing
> > controller manages (provides advertisements) for several transport nodes
> > with each of the latter having a dedicated signaling controller for TE
> > tunnel provisioning?
>
> this is a "functional" separation - in the basic association Si <-> Ri
> <-> i, we retrieve the canonical LSR (note i will change the word "can"
> by "may" in the below informational statement)

IB>> Separation could be physical, not just functional. Consider, for
instance, a transport network built of WXCs that do not have own control
plane. In this case a routing controller managing one or several such WXCs
could advertise their resources, while separate signaling controllers with
the help of PCE(s) could compute and signal TE paths for them.

>
> > Also, how in your opinion a signaling controller knows which address to
send
> > Path message for the next hop along the path.
> > Possible options:
> > a) ID of a numbered link is routable or RouterID in unnumbered ERO
> > sub-object (which is transport node ID) is routable;
>
> several points here:
> 1. we refer to a "TE Router_ID" per RFC 3477 recommendation
> 2. we should indicate these "identifiers" are TE reachable in the scope
>     of the covered application
> 3. even if relevant the scope of this is related to routing
>
> > b) necessary binding (neighbor linkID=> neighbor signaling address,
neighbor
> > nodeID=> neighbor signaling address) is provided via LMP
>
> in the case of multiple association an additional information is
> required that falls beyond the scope of routing and that could be
> achieved using LMP
>

IB>> Personally, I don't like the assumption that transport node IDs and
linkIDs of numbered links are routable (especially in the context of non-PSC
networks) and prefer relying on LMP or some other neighbor auto--discovery
mechanism.

Igor

> hope this clarifies,
> - thanks.
>
> > Thanks,
> > Igor
> >
> >



Envelope-to: [e-mail]
Delivery-date: Thu, 25 Nov 2004 00:25:37 +0000
Message-ID: <[e-mail]>
From: "Ong, Lyndon" <[e-mail]>
To: 'Kireeti Kompella' <[e-mail]>
Cc: "'Brungard, Deborah A, ALABS'" <[e-mail]>, Adrian Farrel <[e-mail]>, [e-mail]
Subject: RE: Second incoming communication from the OIF
Date: Wed, 24 Nov 2004 19:30:45 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

Hi Kireeti,

I respect your opinion, but I suspect that the changes that
you would ask from ITU would amount to dropping G.7713.2
entirely.  It would probably be difficult to get agreement
on this (but that's up to ITU in any case).

There has certainly been an attempt to work cooperatively
in the routing protocol area, and hopefully this will be
mutually productive.  I wouldn't be overly pessimistic 
about convergence in the signaling area, although it's
obviously harder since documents have been approved and
implementations done and tested.

Cheers and Happy Thanksgiving,

Lyndon


-----Original Message-----
From: Kireeti Kompella [mailto:[e-mail]]
Sent: Wednesday, November 24, 2004 8:35 AM
To: Ong, Lyndon
Cc: 'Brungard, Deborah A, ALABS'; Adrian Farrel; [e-mail]
Subject: RE: Second incoming communication from the OIF


Hi Lyndon,

On Tue, 23 Nov 2004, Ong, Lyndon wrote:

> I'm reading into your email a concern with the use of "ASON" in the title
> of the project.  The interworking project is likely to cover ITU-T
> G.7713.2 as the ASON signaling standard at the UNI and E-NNI, taking into
> account experiences that members have had implementing and testing
> protocols.

Our concern is with the project as a whole.  There are several
deficiencies in G.7713.2 and the OIF UNI; these have been pointed out
many times by CCAMP, and liaised to the ITU, but we are not aware of
any significant changes that have been made to the OIF UNI or to
G.7713.2 to address these problems.  In view of this, it seems
premature to expend effort attempting to build networks that interwork
the OIF UNI with GMPLS since future work to fix the OIF UNI is likely
to have considerable impact on any interworking specifications.  The
real problem (namely, the ASON signaling requirements as well as a UNI
and E-NNI) have also been addressed by CCAMP; to continue work on
G.7713.2, and in fact to use it as the ASON signaling standard at the
UNI and E-NNI seems to us very shortsighted indeed.

The communication says, "We expect the OIF, ITU-T and IETF will
continue to work together to minimize or eliminate differences between
control plane signaling protocols."

Certainly a laudable goal.  Persisting with G.7713.2 and the OIF UNI
without any willingness to adapt these specifications clashes with
this goal.  Working together implies converging -- the IETF took a big
step in this direction by acceding to the ASON signaing requirements
as stated; it doesn't seem that the ITU-T or OIF are willing to take
similar steps.

> As you note, GMPLS is being extended to support ASON
> as well.  It sounds reasonable to comment that some clarification of
> the project definition may be helpful.

And very importantly, to state the need for more work on this front,
rather than beginning work on convergence at once.

> This also raises a good point about GMPLS continuing to evolve beyond
> RFC 3473.  As the work on GMPLS extensions to support ASON functionality
> continues to develop, this will need to be taken into account.

At what stage?  It seems that instead of converging, the object seems
to develop a full suite of competing protocols, and only then take the
GMPLS suite into account.

Kireeti.
-------



Envelope-to: [e-mail]
Delivery-date: Wed, 24 Nov 2004 23:43:29 +0000
Message-ID: <[e-mail]>
From: "Ong, Lyndon" <[e-mail]>
To: Kireeti Kompella <[e-mail]>, [e-mail]
Subject: RE: New charter
Date: Wed, 24 Nov 2004 18:48:44 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

Hmm, following the current procedure I would vote for:

(2) GMPLS interop issues
(6) address decoder ring
(8) PCE requirements
(3) L1 VPN

in that order, noting that (6) and (2) are closely related.

Cheers,

Lyndon



Envelope-to: [e-mail]
Delivery-date: Wed, 24 Nov 2004 23:28:02 +0000
Message-ID: <[e-mail]>
From: "Ong, Lyndon" <[e-mail]>
To: 'Adrian Farrel' <[e-mail]>
Cc: [e-mail]
Subject: RE: Second incoming communication from the OIF
Date: Wed, 24 Nov 2004 18:32:26 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

Hi Adrian,

These would be very good comments back to OIF.  I believe the
main interest has been G.7713.2 and RFC 3473, but the project
proposal (as you might expect) is worded broadly so that other
work might be done if there is sufficient interest.

Cheers,

Lyndon


-----Original Message-----
From: Adrian Farrel [mailto:[e-mail]]
Sent: Wednesday, November 24, 2004 9:59 AM
To: Ong, Lyndon
Cc: [e-mail]
Subject: Re: Second incoming communication from the OIF


Lyndon,
On another, but related, thread from this communication...

Do you know whether
  The project will result in a design guideline document to assist vendors
  and carriers in optical networks where signaling interworking is required
  between OIF/ITU-T ASON and GMPLS RSVP-TE.
refers to just a subset of the ITU-T ASON or to the whole of it?

For example, there is a basic discrepancy between (for example) G.7713.2 and
G.7713.3 in
terms of how Call setup is managed. Since the architecture is intended to be
entirely
abstract, the initiating UNI-C cannot know whether the responding UNI-C
expects to see
independent or piggy-backed Call setup. This same issue applies at E-NNI
reference points.

Although it is possible to conceive of ways of managing this type of problem
within
network nodes (for example, at the UNI-N) I should think that a basic
requirement before
documenting interworking between OIF/ITU-T ASON and GMPLS RSVP-TE is to
document
interworking between OIF and ITU-T ASON.

Thanks,
Adrian



Envelope-to: [e-mail]
Delivery-date: Wed, 24 Nov 2004 19:24:19 +0000
Message-ID: <00e701c4d25b$2564dac0$[e-mail]>
From: "Igor Bryskin" <[e-mail]>
To: "Kireeti Kompella" <[e-mail]>, <[e-mail]>
Subject: Re: New charter
Date: Wed, 24 Nov 2004 14:23:58 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Four most important:
1), 3), 5) and 8)

Next two:
2) and 7)

Igor

----- Original Message ----- 
From: "Kireeti Kompella" <[e-mail]>
To: <[e-mail]>
Sent: Wednesday, November 24, 2004 1:22 AM
Subject: New charter


> On Mon, 15 Nov 2004, Kireeti Kompella wrote:
> 
> > If you have suggested charter updates, please send them to Adrian
> > and me.
> 
> Thanks all for your input.  I have the following items; for each,
> please say "Yes" (should be added to CCAMP charter), "No" (should not
> be added) or "-" (don't care).  I'll remind you once again that not
> all items will make it onto the new charter.
> 
> Please keep this subject line (simply reply to this mail).  The
> deadline is Friday Dec 3, 17:00 PST.
> 
> 1) MPLS-GMPLS migration
> 2) GMPLS interoperability issues
> 3a) should the IETF take on L1VPNs?
> 3b) if yes to 3a, should this be done in CCAMP?
> 4) Waveband switching
> 5) Control plane work
> 6) Decoder ring for addresses
> 7) Deployment considerations for GMPLS
> 8) PCE requirements
> 9) QoS control
> 
> A rough idea of what each of the above entails follows.
> 
> 1) MPLS-GMPLS migration
> implementation shift from "MPLS" objects to "GMPLS" objects
> BCP on deployment migration for the same
> 
> 2) GMPLS interoperability issues
> what addresses to use where
> nits/clarifications of the specs
> guidelines for path computation & constraints
> survay
> 
> 3) L1VPN work items
> identify protocol extensions needed
> state what can already be done with what we have
> do the actual protocol work for requirements that are not met
> liaisons to SG13 as needed
> 
> 5) Control plane work
> resiliency
> graceful shutdown
> 
> 6) Decoder ring for addresses
> for each address field, identify its nature and ITU equivalent
> (may overlap with part of (2))
> 
> 
> 4, 7-9 are obvious or have been elaborated on the mailing list.
> 
> Kireeti.
> -------
> 
> PS: The topic of GTTP has carefully been avoided.  More later.
> 



Envelope-to: [e-mail]
Delivery-date: Wed, 24 Nov 2004 19:16:50 +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: New charter
Date: Wed, 24 Nov 2004 11:03:19 -0600
Message-ID: <[e-mail]>
Thread-Topic: New charter
Thread-Index: AcTSQfdQEoCL+px/Q0qw6aWIev0nBAABLM7A
From: "Ash, Gerald R \(Jerry\), ALABS" <[e-mail]>
To: "Kireeti Kompella" <[e-mail]>, <[e-mail]>
Cc: "Ash, Gerald R \(Jerry\), ALABS" <[e-mail]>

> All: instead of Yes/No, can you pick the four most important items
> from your point of view?

Top 4:
1) MPLS-GMPLS migration
2) GMPLS interoperability issues
3) L1VPNs (in CCAMP)
8) PCE requirements

Thanks,
Jerry



Envelope-to: [e-mail]
Delivery-date: Wed, 24 Nov 2004 18:38:26 +0000
Message-ID: <[e-mail]>
Date: Wed, 24 Nov 2004 18:46:40 +0100
From: Gert Grammel <[e-mail]>
Organization: Alcatel OND
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910
MIME-Version: 1.0
CC: [e-mail]
Subject: Re: New charter
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hi Kireeti,

>1) MPLS-GMPLS migration
>	implementation shift from "MPLS" objects to "GMPLS" objects
>	BCP on deployment migration for the same
>  
>
yes

>2) GMPLS interoperability issues
>	what addresses to use where
>	nits/clarifications of the specs
>	guidelines for path computation & constraints
>	survay
>  
>
yes

>3) L1VPN work items
>	identify protocol extensions needed
>	state what can already be done with what we have
>	do the actual protocol work for requirements that are not met
>	liaisons to SG13 as needed
>  
>
yes

>5) Control plane work
>	resiliency
>	graceful shutdown
>  
>
yes

>6) Decoder ring for addresses
>	for each address field, identify its nature and ITU equivalent
>	(may overlap with part of (2))
>  
>
-

>
>4, 7-9 are obvious or have been elaborated on the mailing list.
>
>Kireeti.
>-------
>
>PS: The topic of GTTP has carefully been avoided.  More later.
>
>  
>



Envelope-to: [e-mail]
Delivery-date: Wed, 24 Nov 2004 18:37:21 +0000
Message-ID: <[e-mail]>
Date: Wed, 24 Nov 2004 19:37:09 +0100
From: dimitri papadimitriou <[e-mail]>
Reply-To:  [e-mail],  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910
MIME-Version: 1.0
To:  [e-mail],  [e-mail]
CC: Kireeti Kompella <[e-mail]>,  [e-mail]
Subject: Re: New charter
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

all items have their importance - but as there is a poll for the most 
urgent items:

1. 1) + 2) + 7) - all related(*)
2. 8)
3. 9)
4. 3a) (and yes in CCAMP)

note: 5) will follow sooner or later

dimitri papadimitriou wrote:

> hi kireeti,
> 
>  > 1) MPLS-GMPLS migration
> 
> yes
> 
>  > 2) GMPLS interoperability issues
> 
> yes
> 
>  > 3a) should the IETF take on L1VPNs?
> 
> yes
> 
>  > 3b) if yes to 3a, should this be done in CCAMP?
> 
> as first option (note: with the current standpoint, could this done 
> elsewhere ?)
> 
>  > 4) Waveband switching
> 
> yes (note: need more support as rather limited since so far)
> 
>  > 5) Control plane work
> 
> yes ("document" CP resiliency and GS)
> 
>  > 6) Decoder ring for addresses
> 
> part of this work is in (2) and other should be part of the ongoing ASON 
> work
> 
>  > 7) Deployment considerations for GMPLS
> 
> is this an embryon of "gmplsops" ? in favor
> 
>  > 8) PCE requirements
> 
> yes
> 
>  > 9) QoS control
> 
> yes
> 
> ---
> 
> Kireeti Kompella wrote:
> 
>> On Mon, 15 Nov 2004, Kireeti Kompella wrote:
>>
>>
>>> If you have suggested charter updates, please send them to Adrian
>>> and me.
>>
>>
>>
>> Thanks all for your input.  I have the following items; for each,
>> please say "Yes" (should be added to CCAMP charter), "No" (should not
>> be added) or "-" (don't care).  I'll remind you once again that not
>> all items will make it onto the new charter.
>>
>> Please keep this subject line (simply reply to this mail).  The
>> deadline is Friday Dec 3, 17:00 PST.
>>
>> 1) MPLS-GMPLS migration
>> 2) GMPLS interoperability issues
>> 3a) should the IETF take on L1VPNs?
>> 3b) if yes to 3a, should this be done in CCAMP?
>> 4) Waveband switching
>> 5) Control plane work
>> 6) Decoder ring for addresses
>> 7) Deployment considerations for GMPLS
>> 8) PCE requirements
>> 9) QoS control
>>
>> A rough idea of what each of the above entails follows.
>>
>> 1) MPLS-GMPLS migration
>>     implementation shift from "MPLS" objects to "GMPLS" objects
>>     BCP on deployment migration for the same
>>
>> 2) GMPLS interoperability issues
>>     what addresses to use where
>>     nits/clarifications of the specs
>>     guidelines for path computation & constraints
>>     survay
>>
>> 3) L1VPN work items
>>     identify protocol extensions needed
>>     state what can already be done with what we have
>>     do the actual protocol work for requirements that are not met
>>     liaisons to SG13 as needed
>>
>> 5) Control plane work
>>     resiliency
>>     graceful shutdown
>>
>> 6) Decoder ring for addresses
>>     for each address field, identify its nature and ITU equivalent
>>     (may overlap with part of (2))
>>
>>
>> 4, 7-9 are obvious or have been elaborated on the mailing list.
>>
>> Kireeti.
>> -------
>>
>> PS: The topic of GTTP has carefully been avoided.  More later.
>>
>>
>> .
>>
> 



Envelope-to: [e-mail]
Delivery-date: Wed, 24 Nov 2004 18:34:34 +0000
Message-ID: <[e-mail]>
Date: Wed, 24 Nov 2004 19:32:08 +0100
From: dimitri papadimitriou <[e-mail]>
Reply-To:  [e-mail],  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910
MIME-Version: 1.0
To: Igor Bryskin <[e-mail]>
CC:  [e-mail],  [e-mail]
Subject: Re: RS-DT Wrap-Up Statements
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

igor,

>>>Do you think it is reasonable/practical to separate routing controller
>>>from 
>>>signaling controller and consider scenarios such as a single routing
>>>controller manages (provides advertisements) for several transport nodes
>>>with each of the latter having a dedicated signaling controller for TE
>>>tunnel provisioning?
>>
>>this is a "functional" separation - in the basic association Si <-> Ri
>><-> i, we retrieve the canonical LSR (note i will change the word "can"
>>by "may" in the below informational statement)
> 
> IB>> Separation could be physical, not just functional. Consider, for
> instance, a transport network built of WXCs that do not have own control
> plane. In this case a routing controller managing one or several such WXCs
> could advertise their resources, while separate signaling controllers with
> the help of PCE(s) could compute and signal TE paths for them.

there is a difference between functionally separate Si from Ri and 
physically separate the RDB from the path computation function (i am not 
covering the latter - per scope of the document) - the document covers 
routing information exchange between Ri (over routing adjacencies)

>>>Also, how in your opinion a signaling controller knows which address to
> 
> send
> 
>>>Path message for the next hop along the path.
>>>Possible options:
>>>a) ID of a numbered link is routable or RouterID in unnumbered ERO
>>>sub-object (which is transport node ID) is routable;
>>
>>several points here:
>>1. we refer to a "TE Router_ID" per RFC 3477 recommendation
>>2. we should indicate these "identifiers" are TE reachable in the scope
>>    of the covered application
>>3. even if relevant the scope of this is related to routing
>>
>>
>>>b) necessary binding (neighbor linkID=> neighbor signaling address,
> 
> neighbor
> 
>>>nodeID=> neighbor signaling address) is provided via LMP
>>
>>in the case of multiple association an additional information is
>>required that falls beyond the scope of routing and that could be
>>achieved using LMP
>> 
> IB>> Personally, I don't like the assumption that transport node IDs and
> linkIDs of numbered links are routable (especially in the context of non-PSC
> networks) and prefer relying on LMP or some other neighbor auto--discovery
> mechanism.

example: if you take gmpls-overlay that mentions "An edge-node is 
identified by either a single IP address representing its Node-ID, or by 
one or more numbered TE links that connect the edge-node to the core- 
nodes." there is nothing specifically different here compared to this 
approach

> Igor
> 
> 
>>hope this clarifies,
>>- thanks.
>>
>>
>>>Thanks,
>>>Igor
>>>
>>>
>>>----- Original Message ----- 
>>>From: "dimitri papadimitriou" <[e-mail]>
>>>To: <[e-mail]>
>>>Sent: Wednesday, November 24, 2004 4:25 AM
>>>Subject: RS-DT Wrap-Up Statements
>>>
>>>
>>>
>>>
>>>>folks -
>>>>
>>>>The initial evaluation phase of existing routing protocols required
>>>>definition of a common pattern. The definition of this pattern last
>>>>until beginning of november (input from several parties) now that pieces
>>>>are in place needs to move a step further.
>>>>
>>>>The evaluation document will be issued by end-november to close this
>>>>first phase. The content of this document will be articulated around the
>>>>below terminology, scenarios and features.
>>>>
>>>>1. Terminology:
>>>>--------------
>>>>
>>>>- Pi is a physical node (bearer/data/transport plane) node
>>>>- Li is a logical control plane identifier that is associated to a
>>>>  single data plane (abstract) node
>>>>  Li = logical node id or "TE router id" i.e. for
>>>>  . RFC 3630: Router_Address (top level) TLV of the Type 1 TE LSA
>>>>  . RFC 3784: Traffic Engineering Router ID TLV (Type 134)
>>>>- Ri is a control plane "router" e.g. (advertising) Router_ID i.e.
>>>>  . RFC 2328: Router ID (32-bit)
>>>>  . RFC 1195: IS-IS System ID (48-bit)
>>>>
>>>>Note: in the below Figure 1.
>>>>- R3 represents an LSR with all components collocated.
>>>>- R2 shows how the "router" component may be disjoint from the node
>>>>- R1 shows how a single "router" may manage multiple nodes
>>>>
>>>>The Router_ID (represented by Ri) does not enter into the identification
>>>>of the logical entities representing the data plane resources such as
>>>>links. The Routing DataBase (RDB) is associated to the Ri.
>>>>
>>>>Note: the "signaling controller" i.e. the control plane entity that
>>>>processes the signaling messages (referred to as Si) is not represented
>>>>in these Figures. Multiple signalling controllers can be associated to
>>>>one Ri and make use of the path computation function associated to the
> 
> Ri.
> 
>>>>2. Mechanisms:
>>>>-------------
>>>>
>>>>Focus is on routing information exchange between Ri entities (through
>>>>routing adjacencies) within single hierarchical level. Routing
>>>>information mapping between levels may require specific guidelines.
>>>>
>>>>The control plane does not transport Pi information as these are data
>>>>plane addresses for which the the Li/Pi mapping is kept (link) local -
>>>>see for instance the transport LMP document where such exchange is
>>>>described. Example: the transport plane identifier is the Pi (the
>>>>identifier assigned to the physical element) be for instance
>>>>"666B.F999.AF10.222C", the control plane identifier is the Li (the
>>>>identifier assigned by the control plane), be for instance "1.1.1.1".
>>>>The control plane exchanges the control plane identifier information but
>>>>not the transport plane identifier information (i.e. not
>>>>"666B.F999.AF10.222C" but only "1.1.1.1"), The mapping Li/Pi is kept
>>>>local. So, when the Si receives a control plane message requesting the
>>>>use of "1.1.1.1", Si knows locally that this information refers to the
>>>>data plane entity identified by the transport plane identifier
>>>>"666B.F999.AF10.222C".
>>>>
>>>>The control plane carries:
>>>>1) its view of the data plane link end-points and other link connection
>>>>end-points - note: advertisement of reachability can be achieved using
>>>>the techniques described in
>>
>>><http://www.ietf.org/internet-drafts/draft-ietf-ospf-te-node-addr-01.txt>
>>>
>>>>2) the identifiers scoped by the Li's i.e. we speak about an associated
>>>>IPv4/IPv6 addressing space;
>>>>
>>>>Evalution Scenarios:
>>>>-------------------
>>>>
>>>>The scenarios are the following: resp. case 1), 2) and 3)
>>>>
>>>>             -------------------     ------
>>>>            |R1                 |   |R2     |
>>>>            |                   |   |       |    ------
>>>>            |  L1    L2    L3   |   |   L4  |   |R3    |
>>>>            |   :     :     :   |   |   :   |   |      |
>>>>            |   :     :     :   |   |   :   |   |  L5  |
>>>>Control      ---+-----+-----+---     ---+---    |   :  |
>>>>Plane           :     :     :           :       |   :  |
>>>>----------------+-----+-----+-----------+-------+---+--+-
>>>>Data            :     :     :           :       |   :  |
>>>>Plane          --     :    --          --       |  --  |
>>>>          ----|P1|--------|P3|--------|P4|------+-|P5|-+-
>>>>               -- \   :  / --          --       |  --  |
>>>>                   \ -- /                       |      |
>>>>                    |P2|                         ------
>>>>                     --
>>>>
>>>>case 1) as represented either direct links between edges or "logical
>>>>links" as per below figure (or any combination of them)
>>>>
>>>>                ------                        ------
>>>>               |      |                      |      |
>>>>               |  L1  |                      |  L2  |
>>>>               |  :   |                      |  :   |
>>>>               |  : R1|                      |  : R2|
>>>>Control Plane   --+---                        --+---
>>>>Elements          :                             :
>>>>------------------+-----------------------------+------------------
>>>>Data Plane        :                             :
>>>>Elements          :                             :
>>>>              ----+-----------------------------+-----
>>>>             |    :                             :     |
>>>>             |   ---            ---            ---    |
>>>>             |  |   |----------| P |----------|   |   |
>>>>          ---+--|   |           ---           |   |---+---
>>>>             |  |   |                         |   |   |
>>>>             |  | P1|-------------------------| P2|   |
>>>>             |   ---                           ---    |
>>>>              ----------------------------------------
>>>>
>>>>Another case is constituted by the Abstract Node as represented in the
>>>>below figure. There is no internal structure associated to the abstract
>>>>node.
>>>>
>>>>                    --------------
>>>>                   |R4            |
>>>>                   |              |
>>>>                   |      L6      |
>>>>                   |       :      |
>>>>                   |    ......    |
>>>>                    ---:------:---
>>>>Control Plane          :      :
>>>>                +------+------+------+
>>>>Data Plane             :      :
>>>>                    ---:------:---
>>>>                   |P8 :      :   |
>>>>                   |  --      --  |
>>>>                 --+-|P |----|P |-+--
>>>>                   |  --      --  |
>>>>                    --------------
>>>>
>>>>Note: base scenarios (being not combinations or decomposition of
>>>>entities) can further complete this set
>>>>
>>>>4. Specific Considerations
>>>>   -----------------------
>>>>
>>>>Representation of bandwidth requires further analysis i.e. GMPLS Routing
>>>>defines an Interface Switching Capability Descriptor (ISCD) that
>>>>delivers information about the (maximum/minimum) bandwidth per priority
>>>>an LSP can make use of. In the ASON context, other representations are
>>>>possible, e.g. in terms of a set of tuples <signal_type; number of
>>>>unallocated timeslots>. The latter also may require definition of
>>>>additional signal types (from those defined in RFC 3496) to represent
>>>>contiguous concatenation i.e. STS-(3xN)c SPE / VC-4-Nc, N = 4, 16, 64,
>>>
>>>256.
>>>
>>>
>>>>The GMPLS routing method proposed in GMPLS Routing is the most
>>>>straightforward without requiring any bandwidth accounting change from
>>>>an LSR perspective. However, it introduces some lost of information.
>>>>This lost of information affects the number of signals that can be used
>>>>but not the range they cover. On the other hand, if additional
>>>>technology specific information (such as capabilities) are advertised a
>>>>finer grained resource countdown and accounting can be performed
>>>>allowing for network wide resource allocation in Sonet/SDH environments.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>.
>>>
>>
> 
> 
> 
> .
> 



Envelope-to: [e-mail]
Delivery-date: Wed, 24 Nov 2004 18:34:26 +0000
Message-ID: <01b501c4d24f$5ff222d0$ec919ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Ong, Lyndon" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Second incoming communication from the OIF
Date: Wed, 24 Nov 2004 17:59:28 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Lyndon,
On another, but related, thread from this communication...

Do you know whether
  The project will result in a design guideline document to assist vendors
  and carriers in optical networks where signaling interworking is required
  between OIF/ITU-T ASON and GMPLS RSVP-TE.
refers to just a subset of the ITU-T ASON or to the whole of it?

For example, there is a basic discrepancy between (for example) G.7713.2 and G.7713.3 in
terms of how Call setup is managed. Since the architecture is intended to be entirely
abstract, the initiating UNI-C cannot know whether the responding UNI-C expects to see
independent or piggy-backed Call setup. This same issue applies at E-NNI reference points.

Although it is possible to conceive of ways of managing this type of problem within
network nodes (for example, at the UNI-N) I should think that a basic requirement before
documenting interworking between OIF/ITU-T ASON and GMPLS RSVP-TE is to document
interworking between OIF and ITU-T ASON.

Thanks,
Adrian
----- Original Message ----- 
From: "Kireeti Kompella" <[e-mail]>
To: "Ong, Lyndon" <[e-mail]>
Cc: "'Brungard, Deborah A, ALABS'" <[e-mail]>; "Adrian Farrel"
<[e-mail]>; <[e-mail]>
Sent: Wednesday, November 24, 2004 4:34 PM
Subject: RE: Second incoming communication from the OIF


> Hi Lyndon,
>
> On Tue, 23 Nov 2004, Ong, Lyndon wrote:
>
> > I'm reading into your email a concern with the use of "ASON" in the title
> > of the project.  The interworking project is likely to cover ITU-T
> > G.7713.2 as the ASON signaling standard at the UNI and E-NNI, taking into
> > account experiences that members have had implementing and testing
> > protocols.
>
> Our concern is with the project as a whole.  There are several
> deficiencies in G.7713.2 and the OIF UNI; these have been pointed out
> many times by CCAMP, and liaised to the ITU, but we are not aware of
> any significant changes that have been made to the OIF UNI or to
> G.7713.2 to address these problems.  In view of this, it seems
> premature to expend effort attempting to build networks that interwork
> the OIF UNI with GMPLS since future work to fix the OIF UNI is likely
> to have considerable impact on any interworking specifications.  The
> real problem (namely, the ASON signaling requirements as well as a UNI
> and E-NNI) have also been addressed by CCAMP; to continue work on
> G.7713.2, and in fact to use it as the ASON signaling standard at the
> UNI and E-NNI seems to us very shortsighted indeed.
>
> The communication says, "We expect the OIF, ITU-T and IETF will
> continue to work together to minimize or eliminate differences between
> control plane signaling protocols."
>
> Certainly a laudable goal.  Persisting with G.7713.2 and the OIF UNI
> without any willingness to adapt these specifications clashes with
> this goal.  Working together implies converging -- the IETF took a big
> step in this direction by acceding to the ASON signaing requirements
> as stated; it doesn't seem that the ITU-T or OIF are willing to take
> similar steps.
>
> > As you note, GMPLS is being extended to support ASON
> > as well.  It sounds reasonable to comment that some clarification of
> > the project definition may be helpful.
>
> And very importantly, to state the need for more work on this front,
> rather than beginning work on convergence at once.
>
> > This also raises a good point about GMPLS continuing to evolve beyond
> > RFC 3473.  As the work on GMPLS extensions to support ASON functionality
> > continues to develop, this will need to be taken into account.
>
> At what stage?  It seems that instead of converging, the object seems
> to develop a full suite of competing protocols, and only then take the
> GMPLS suite into account.
>
> Kireeti.
> -------
>
>




Envelope-to: [e-mail]
Delivery-date: Wed, 24 Nov 2004 16:47:00 +0000
From: "Zafar Ali" <[e-mail]>
To: "'Kireeti Kompella'" <[e-mail]>, "'Loa Andersson'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: New charter
Date: Wed, 24 Nov 2004 11:46:29 -0500
Message-ID: <01d301c4d245$266312e0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

>-----Original Message-----
>From: [e-mail] 
>[mailto:[e-mail]] On Behalf Of Kireeti Kompella
>Sent: Wednesday, November 24, 2004 11:21 AM
>To: Loa Andersson
>Cc: [e-mail]
>Subject: Re: New charter
>
>
>On Wed, 24 Nov 2004, Loa Andersson wrote:
>
>> not entirely happy to let the IESG do the pruning,
>
>Okay, Loa -- you are right.
>
>All: instead of Yes/No, can you pick the four most important 
>items from your point of view?  Thanks!
>
>(To those who already replied, sorry to make you do this again!)
>

Hi Kireeti, 

My pick for the four items is (in this order),

- PCE requirements
- GMPLS interoperability issues (incl. MPLS-GMPLS migration), as "GMPLS
interoperability issues" and "MPLS-GMPLS migration" are overlapping in
nature. 
- Control plane work
- L1VPN

N.b. Items (in this order)... waveband switching, QoS control and Decoder
ring for addresses are lowest priority (don't care) for me.  

Thanks

Regards... Zafar 

><snip>
>>
>>1) MPLS-GMPLS migration
>
>Yes, .... You may like to rename it as from name it appears 
>that there is a lot of overlap of this with "7) Deployment 
>considerations for GMPLS". 
>

Important, 

>>2) GMPLS interoperability issues
>
>Yes, 

Very important, 

>
>>3a) should the IETF take on L1VPNs?
>
>Yes, 

Important, 

>
>>3b) if yes to 3a, should this be done in CCAMP?
>
>Yes, 

Important, 

>
>>4) Waveband switching

Don't care, 

>>5) Control plane work
>
>Yes, but the name is too board, may like to rename it, e.g., 
>Control plane resiliency and GS. 
>

Very Important. 

>>6) Decoder ring for addresses

Don't care, 

>>7) Deployment considerations for GMPLS
>
>Yes, 

Important, 

>
>>8) PCE requirements
>
>Yes, 

Very important, 

>
>>9) QoS control

Don't care, 

<snip>





Envelope-to: [e-mail]
Delivery-date: Wed, 24 Nov 2004 16:39:41 +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 : New charter
Date: Wed, 24 Nov 2004 17:39:17 +0100
Message-ID: <[e-mail]>
Thread-Topic: New charter
Thread-Index: AcTSQwAJfOed9eBGTTuuBDzjuUVrywAAFS3w
From: "LE ROUX Jean-Louis RD-CORE-LAN" <[e-mail]>
To: "Kireeti Kompella" <[e-mail]>, "Loa Andersson" <[e-mail]>
Cc: <[e-mail]>

All listed items seem really important, but if you need the four=20
most important, IMHO here they are

1) + 7) (as both are intimately linked)
2)=20
8)=20
9)=20

JL


>-----Message d'origine-----
>De : [e-mail]=20
>[mailto:[e-mail]] De la part de Kireeti Kompella
>Envoy=E9 : mercredi 24 novembre 2004 17:21
>=C0 : Loa Andersson
>Cc : [e-mail]
>Objet : Re: New charter
>
>
>On Wed, 24 Nov 2004, Loa Andersson wrote:
>
>> not entirely happy to let the IESG do the pruning,
>
>Okay, Loa -- you are right.
>
>All: instead of Yes/No, can you pick the four most important=20
>items from your point of view?  Thanks!
>
>(To those who already replied, sorry to make you do this again!)
>
>Kireeti.
>-------
>
>



Envelope-to: [e-mail]
Delivery-date: Wed, 24 Nov 2004 16:35:25 +0000
Date: Wed, 24 Nov 2004 08:34:56 -0800 (PST)
From: Kireeti Kompella <[e-mail]>
To: "Ong, Lyndon" <[e-mail]>
cc: "'Brungard, Deborah A, ALABS'" <[e-mail]>, Adrian Farrel <[e-mail]>, [e-mail]
Subject: RE: Second incoming communication from the OIF
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi Lyndon,

On Tue, 23 Nov 2004, Ong, Lyndon wrote:

> I'm reading into your email a concern with the use of "ASON" in the title
> of the project.  The interworking project is likely to cover ITU-T
> G.7713.2 as the ASON signaling standard at the UNI and E-NNI, taking into
> account experiences that members have had implementing and testing
> protocols.

Our concern is with the project as a whole.  There are several
deficiencies in G.7713.2 and the OIF UNI; these have been pointed out
many times by CCAMP, and liaised to the ITU, but we are not aware of
any significant changes that have been made to the OIF UNI or to
G.7713.2 to address these problems.  In view of this, it seems
premature to expend effort attempting to build networks that interwork
the OIF UNI with GMPLS since future work to fix the OIF UNI is likely
to have considerable impact on any interworking specifications.  The
real problem (namely, the ASON signaling requirements as well as a UNI
and E-NNI) have also been addressed by CCAMP; to continue work on
G.7713.2, and in fact to use it as the ASON signaling standard at the
UNI and E-NNI seems to us very shortsighted indeed.

The communication says, "We expect the OIF, ITU-T and IETF will
continue to work together to minimize or eliminate differences between
control plane signaling protocols."

Certainly a laudable goal.  Persisting with G.7713.2 and the OIF UNI
without any willingness to adapt these specifications clashes with
this goal.  Working together implies converging -- the IETF took a big
step in this direction by acceding to the ASON signaing requirements
as stated; it doesn't seem that the ITU-T or OIF are willing to take
similar steps.

> As you note, GMPLS is being extended to support ASON
> as well.  It sounds reasonable to comment that some clarification of
> the project definition may be helpful.

And very importantly, to state the need for more work on this front,
rather than beginning work on convergence at once.

> This also raises a good point about GMPLS continuing to evolve beyond
> RFC 3473.  As the work on GMPLS extensions to support ASON functionality
> continues to develop, this will need to be taken into account.

At what stage?  It seems that instead of converging, the object seems
to develop a full suite of competing protocols, and only then take the
GMPLS suite into account.

Kireeti.
-------



Envelope-to: [e-mail]
Delivery-date: Wed, 24 Nov 2004 16:29:44 +0000
Message-ID: <009901c4d242$c416ce80$[e-mail]>
From: "Igor Bryskin" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: Re: RS-DT Wrap-Up Statements
Date: Wed, 24 Nov 2004 11:29:26 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

dimitri, see in-line

----- Original Message ----- 
From: "dimitri papadimitriou" <[e-mail]>
To: "Igor Bryskin" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
Sent: Wednesday, November 24, 2004 11:02 AM
Subject: Re: RS-DT Wrap-Up Statements


> igor - see in-line:
>
> Igor Bryskin wrote:
>
> > Dimitri,
> >
> > Do you think it is reasonable/practical to separate routing controller
from
> > signaling controller and consider scenarios such as a single routing
> > controller manages (provides advertisements) for several transport nodes
> > with each of the latter having a dedicated signaling controller for TE
> > tunnel provisioning?
>
> this is a "functional" separation - in the basic association Si <-> Ri
> <-> i, we retrieve the canonical LSR (note i will change the word "can"
> by "may" in the below informational statement)

IB>> Separation could be physical, not just functional. Consider, for
instance, a transport network built of WXCs that do not have own control
plane. In this case a routing controller managing one or several such WXCs
could advertise their resources, while separate signaling controllers with
the help of PCE(s) could compute and signal TE paths for them.

>
> > Also, how in your opinion a signaling controller knows which address to
send
> > Path message for the next hop along the path.
> > Possible options:
> > a) ID of a numbered link is routable or RouterID in unnumbered ERO
> > sub-object (which is transport node ID) is routable;
>
> several points here:
> 1. we refer to a "TE Router_ID" per RFC 3477 recommendation
> 2. we should indicate these "identifiers" are TE reachable in the scope
>     of the covered application
> 3. even if relevant the scope of this is related to routing
>
> > b) necessary binding (neighbor linkID=> neighbor signaling address,
neighbor
> > nodeID=> neighbor signaling address) is provided via LMP
>
> in the case of multiple association an additional information is
> required that falls beyond the scope of routing and that could be
> achieved using LMP
>

IB>> Personally, I don't like the assumption that transport node IDs and
linkIDs of numbered links are routable (especially in the context of non-PSC
networks) and prefer relying on LMP or some other neighbor auto--discovery
mechanism.

Igor

> hope this clarifies,
> - thanks.
>
> > Thanks,
> > Igor
> >
> >
> > ----- Original Message ----- 
> > From: "dimitri papadimitriou" <[e-mail]>
> > To: <[e-mail]>
> > Sent: Wednesday, November 24, 2004 4:25 AM
> > Subject: RS-DT Wrap-Up Statements
> >
> >
> >
> >>folks -
> >>
> >>The initial evaluation phase of existing routing protocols required
> >>definition of a common pattern. The definition of this pattern last
> >>until beginning of november (input from several parties) now that pieces
> >>are in place needs to move a step further.
> >>
> >>The evaluation document will be issued by end-november to close this
> >>first phase. The content of this document will be articulated around the
> >>below terminology, scenarios and features.
> >>
> >>1. Terminology:
> >>--------------
> >>
> >>- Pi is a physical node (bearer/data/transport plane) node
> >>- Li is a logical control plane identifier that is associated to a
> >>   single data plane (abstract) node
> >>   Li = logical node id or "TE router id" i.e. for
> >>   . RFC 3630: Router_Address (top level) TLV of the Type 1 TE LSA
> >>   . RFC 3784: Traffic Engineering Router ID TLV (Type 134)
> >>- Ri is a control plane "router" e.g. (advertising) Router_ID i.e.
> >>   . RFC 2328: Router ID (32-bit)
> >>   . RFC 1195: IS-IS System ID (48-bit)
> >>
> >>Note: in the below Figure 1.
> >>- R3 represents an LSR with all components collocated.
> >>- R2 shows how the "router" component may be disjoint from the node
> >>- R1 shows how a single "router" may manage multiple nodes
> >>
> >>The Router_ID (represented by Ri) does not enter into the identification
> >>of the logical entities representing the data plane resources such as
> >>links. The Routing DataBase (RDB) is associated to the Ri.
> >>
> >>Note: the "signaling controller" i.e. the control plane entity that
> >>processes the signaling messages (referred to as Si) is not represented
> >>in these Figures. Multiple signalling controllers can be associated to
> >>one Ri and make use of the path computation function associated to the
Ri.
> >>
> >>2. Mechanisms:
> >>-------------
> >>
> >>Focus is on routing information exchange between Ri entities (through
> >>routing adjacencies) within single hierarchical level. Routing
> >>information mapping between levels may require specific guidelines.
> >>
> >>The control plane does not transport Pi information as these are data
> >>plane addresses for which the the Li/Pi mapping is kept (link) local -
> >>see for instance the transport LMP document where such exchange is
> >>described. Example: the transport plane identifier is the Pi (the
> >>identifier assigned to the physical element) be for instance
> >>"666B.F999.AF10.222C", the control plane identifier is the Li (the
> >>identifier assigned by the control plane), be for instance "1.1.1.1".
> >>The control plane exchanges the control plane identifier information but
> >>not the transport plane identifier information (i.e. not
> >>"666B.F999.AF10.222C" but only "1.1.1.1"), The mapping Li/Pi is kept
> >>local. So, when the Si receives a control plane message requesting the
> >>use of "1.1.1.1", Si knows locally that this information refers to the
> >>data plane entity identified by the transport plane identifier
> >>"666B.F999.AF10.222C".
> >>
> >>The control plane carries:
> >>1) its view of the data plane link end-points and other link connection
> >>end-points - note: advertisement of reachability can be achieved using
> >>the techniques described in
>
>><http://www.ietf.org/internet-drafts/draft-ietf-ospf-te-node-addr-01.txt>
> >>
> >>2) the identifiers scoped by the Li's i.e. we speak about an associated
> >>IPv4/IPv6 addressing space;
> >>
> >>Evalution Scenarios:
> >>-------------------
> >>
> >>The scenarios are the following: resp. case 1), 2) and 3)
> >>
> >>              -------------------     ------
> >>             |R1                 |   |R2     |
> >>             |                   |   |       |    ------
> >>             |  L1    L2    L3   |   |   L4  |   |R3    |
> >>             |   :     :     :   |   |   :   |   |      |
> >>             |   :     :     :   |   |   :   |   |  L5  |
> >>Control      ---+-----+-----+---     ---+---    |   :  |
> >>Plane           :     :     :           :       |   :  |
> >>----------------+-----+-----+-----------+-------+---+--+-
> >>Data            :     :     :           :       |   :  |
> >>Plane          --     :    --          --       |  --  |
> >>           ----|P1|--------|P3|--------|P4|------+-|P5|-+-
> >>                -- \   :  / --          --       |  --  |
> >>                    \ -- /                       |      |
> >>                     |P2|                         ------
> >>                      --
> >>
> >>case 1) as represented either direct links between edges or "logical
> >>links" as per below figure (or any combination of them)
> >>
> >>                 ------                        ------
> >>                |      |                      |      |
> >>                |  L1  |                      |  L2  |
> >>                |  :   |                      |  :   |
> >>                |  : R1|                      |  : R2|
> >>Control Plane   --+---                        --+---
> >>Elements          :                             :
> >>------------------+-----------------------------+------------------
> >>Data Plane        :                             :
> >>Elements          :                             :
> >>               ----+-----------------------------+-----
> >>              |    :                             :     |
> >>              |   ---            ---            ---    |
> >>              |  |   |----------| P |----------|   |   |
> >>           ---+--|   |           ---           |   |---+---
> >>              |  |   |                         |   |   |
> >>              |  | P1|-------------------------| P2|   |
> >>              |   ---                           ---    |
> >>               ----------------------------------------
> >>
> >>Another case is constituted by the Abstract Node as represented in the
> >>below figure. There is no internal structure associated to the abstract
> >>node.
> >>
> >>                     --------------
> >>                    |R4            |
> >>                    |              |
> >>                    |      L6      |
> >>                    |       :      |
> >>                    |    ......    |
> >>                     ---:------:---
> >>Control Plane          :      :
> >>                 +------+------+------+
> >>Data Plane             :      :
> >>                     ---:------:---
> >>                    |P8 :      :   |
> >>                    |  --      --  |
> >>                  --+-|P |----|P |-+--
> >>                    |  --      --  |
> >>                     --------------
> >>
> >>Note: base scenarios (being not combinations or decomposition of
> >>entities) can further complete this set
> >>
> >>4. Specific Considerations
> >>    -----------------------
> >>
> >>Representation of bandwidth requires further analysis i.e. GMPLS Routing
> >>defines an Interface Switching Capability Descriptor (ISCD) that
> >>delivers information about the (maximum/minimum) bandwidth per priority
> >>an LSP can make use of. In the ASON context, other representations are
> >>possible, e.g. in terms of a set of tuples <signal_type; number of
> >>unallocated timeslots>. The latter also may require definition of
> >>additional signal types (from those defined in RFC 3496) to represent
> >>contiguous concatenation i.e. STS-(3xN)c SPE / VC-4-Nc, N = 4, 16, 64,
> >
> > 256.
> >
> >>The GMPLS routing method proposed in GMPLS Routing is the most
> >>straightforward without requiring any bandwidth accounting change from
> >>an LSR perspective. However, it introduces some lost of information.
> >>This lost of information affects the number of signals that can be used
> >>but not the range they cover. On the other hand, if additional
> >>technology specific information (such as capabilities) are advertised a
> >>finer grained resource countdown and accounting can be performed
> >>allowing for network wide resource allocation in Sonet/SDH environments.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
> >
> > .
> >
>




Envelope-to: [e-mail]
Delivery-date: Wed, 24 Nov 2004 16:21:53 +0000
Date: Wed, 24 Nov 2004 08:21:16 -0800 (PST)
From: Kireeti Kompella <[e-mail]>
To: Loa Andersson <[e-mail]>
cc: [e-mail]
Subject: Re: New charter
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 24 Nov 2004, Loa Andersson wrote:

> not entirely happy to let the IESG do the pruning,

Okay, Loa -- you are right.

All: instead of Yes/No, can you pick the four most important items
from your point of view?  Thanks!

(To those who already replied, sorry to make you do this again!)

Kireeti.
-------



Envelope-to: [e-mail]
Delivery-date: Wed, 24 Nov 2004 16:03:39 +0000
Message-ID: <[e-mail]>
Date: Wed, 24 Nov 2004 17:02:53 +0100
From: dimitri papadimitriou <[e-mail]>
Reply-To:  [e-mail],  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910
MIME-Version: 1.0
To: Igor Bryskin <[e-mail]>
CC:  [e-mail],  [e-mail]
Subject: Re: RS-DT Wrap-Up Statements
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

igor - see in-line:

Igor Bryskin wrote:

> Dimitri,
> 
> Do you think it is reasonable/practical to separate routing controller from
> signaling controller and consider scenarios such as a single routing
> controller manages (provides advertisements) for several transport nodes
> with each of the latter having a dedicated signaling controller for TE
> tunnel provisioning?

this is a "functional" separation - in the basic association Si <-> Ri 
<-> i, we retrieve the canonical LSR (note i will change the word "can" 
by "may" in the below informational statement)

> Also, how in your opinion a signaling controller knows which address to send
> Path message for the next hop along the path.
> Possible options:
> a) ID of a numbered link is routable or RouterID in unnumbered ERO
> sub-object (which is transport node ID) is routable;

several points here:
1. we refer to a "TE Router_ID" per RFC 3477 recommendation
2. we should indicate these "identifiers" are TE reachable in the scope
    of the covered application
3. even if relevant the scope of this is related to routing

> b) necessary binding (neighbor linkID=> neighbor signaling address, neighbor
> nodeID=> neighbor signaling address) is provided via LMP

in the case of multiple association an additional information is 
required that falls beyond the scope of routing and that could be 
achieved using LMP

hope this clarifies,
- thanks.

> Thanks,
> Igor
> 
> 
> ----- Original Message ----- 
> From: "dimitri papadimitriou" <[e-mail]>
> To: <[e-mail]>
> Sent: Wednesday, November 24, 2004 4:25 AM
> Subject: RS-DT Wrap-Up Statements
> 
> 
> 
>>folks -
>>
>>The initial evaluation phase of existing routing protocols required
>>definition of a common pattern. The definition of this pattern last
>>until beginning of november (input from several parties) now that pieces
>>are in place needs to move a step further.
>>
>>The evaluation document will be issued by end-november to close this
>>first phase. The content of this document will be articulated around the
>>below terminology, scenarios and features.
>>
>>1. Terminology:
>>--------------
>>
>>- Pi is a physical node (bearer/data/transport plane) node
>>- Li is a logical control plane identifier that is associated to a
>>   single data plane (abstract) node
>>   Li = logical node id or "TE router id" i.e. for
>>   . RFC 3630: Router_Address (top level) TLV of the Type 1 TE LSA
>>   . RFC 3784: Traffic Engineering Router ID TLV (Type 134)
>>- Ri is a control plane "router" e.g. (advertising) Router_ID i.e.
>>   . RFC 2328: Router ID (32-bit)
>>   . RFC 1195: IS-IS System ID (48-bit)
>>
>>Note: in the below Figure 1.
>>- R3 represents an LSR with all components collocated.
>>- R2 shows how the "router" component may be disjoint from the node
>>- R1 shows how a single "router" may manage multiple nodes
>>
>>The Router_ID (represented by Ri) does not enter into the identification
>>of the logical entities representing the data plane resources such as
>>links. The Routing DataBase (RDB) is associated to the Ri.
>>
>>Note: the "signaling controller" i.e. the control plane entity that
>>processes the signaling messages (referred to as Si) is not represented
>>in these Figures. Multiple signalling controllers can be associated to
>>one Ri and make use of the path computation function associated to the Ri.
>>
>>2. Mechanisms:
>>-------------
>>
>>Focus is on routing information exchange between Ri entities (through
>>routing adjacencies) within single hierarchical level. Routing
>>information mapping between levels may require specific guidelines.
>>
>>The control plane does not transport Pi information as these are data
>>plane addresses for which the the Li/Pi mapping is kept (link) local -
>>see for instance the transport LMP document where such exchange is
>>described. Example: the transport plane identifier is the Pi (the
>>identifier assigned to the physical element) be for instance
>>"666B.F999.AF10.222C", the control plane identifier is the Li (the
>>identifier assigned by the control plane), be for instance "1.1.1.1".
>>The control plane exchanges the control plane identifier information but
>>not the transport plane identifier information (i.e. not
>>"666B.F999.AF10.222C" but only "1.1.1.1"), The mapping Li/Pi is kept
>>local. So, when the Si receives a control plane message requesting the
>>use of "1.1.1.1", Si knows locally that this information refers to the
>>data plane entity identified by the transport plane identifier
>>"666B.F999.AF10.222C".
>>
>>The control plane carries:
>>1) its view of the data plane link end-points and other link connection
>>end-points - note: advertisement of reachability can be achieved using
>>the techniques described in
>><http://www.ietf.org/internet-drafts/draft-ietf-ospf-te-node-addr-01.txt>
>>
>>2) the identifiers scoped by the Li's i.e. we speak about an associated
>>IPv4/IPv6 addressing space;
>>
>>Evalution Scenarios:
>>-------------------
>>
>>The scenarios are the following: resp. case 1), 2) and 3)
>>
>>              -------------------     ------
>>             |R1                 |   |R2     |
>>             |                   |   |       |    ------
>>             |  L1    L2    L3   |   |   L4  |   |R3    |
>>             |   :     :     :   |   |   :   |   |      |
>>             |   :     :     :   |   |   :   |   |  L5  |
>>Control      ---+-----+-----+---     ---+---    |   :  |
>>Plane           :     :     :           :       |   :  |
>>----------------+-----+-----+-----------+-------+---+--+-
>>Data            :     :     :           :       |   :  |
>>Plane          --     :    --          --       |  --  |
>>           ----|P1|--------|P3|--------|P4|------+-|P5|-+-
>>                -- \   :  / --          --       |  --  |
>>                    \ -- /                       |      |
>>                     |P2|                         ------
>>                      --
>>
>>case 1) as represented either direct links between edges or "logical
>>links" as per below figure (or any combination of them)
>>
>>                 ------                        ------
>>                |      |                      |      |
>>                |  L1  |                      |  L2  |
>>                |  :   |                      |  :   |
>>                |  : R1|                      |  : R2|
>>Control Plane   --+---                        --+---
>>Elements          :                             :
>>------------------+-----------------------------+------------------
>>Data Plane        :                             :
>>Elements          :                             :
>>               ----+-----------------------------+-----
>>              |    :                             :     |
>>              |   ---            ---            ---    |
>>              |  |   |----------| P |----------|   |   |
>>           ---+--|   |           ---           |   |---+---
>>              |  |   |                         |   |   |
>>              |  | P1|-------------------------| P2|   |
>>              |   ---                           ---    |
>>               ----------------------------------------
>>
>>Another case is constituted by the Abstract Node as represented in the
>>below figure. There is no internal structure associated to the abstract
>>node.
>>
>>                     --------------
>>                    |R4            |
>>                    |              |
>>                    |      L6      |
>>                    |       :      |
>>                    |    ......    |
>>                     ---:------:---
>>Control Plane          :      :
>>                 +------+------+------+
>>Data Plane             :      :
>>                     ---:------:---
>>                    |P8 :      :   |
>>                    |  --      --  |
>>                  --+-|P |----|P |-+--
>>                    |  --      --  |
>>                     --------------
>>
>>Note: base scenarios (being not combinations or decomposition of
>>entities) can further complete this set
>>
>>4. Specific Considerations
>>    -----------------------
>>
>>Representation of bandwidth requires further analysis i.e. GMPLS Routing
>>defines an Interface Switching Capability Descriptor (ISCD) that
>>delivers information about the (maximum/minimum) bandwidth per priority
>>an LSP can make use of. In the ASON context, other representations are
>>possible, e.g. in terms of a set of tuples <signal_type; number of
>>unallocated timeslots>. The latter also may require definition of
>>additional signal types (from those defined in RFC 3496) to represent
>>contiguous concatenation i.e. STS-(3xN)c SPE / VC-4-Nc, N = 4, 16, 64,
> 
> 256.
> 
>>The GMPLS routing method proposed in GMPLS Routing is the most
>>straightforward without requiring any bandwidth accounting change from
>>an LSR perspective. However, it introduces some lost of information.
>>This lost of information affects the number of signals that can be used
>>but not the range they cover. On the other hand, if additional
>>technology specific information (such as capabilities) are advertised a
>>finer grained resource countdown and accounting can be performed
>>allowing for network wide resource allocation in Sonet/SDH environments.
>>
>>
>>
>>
>>
>>
>>
>>
> 
> 
> 
> 
> .
> 



Envelope-to: [e-mail]
Delivery-date: Wed, 24 Nov 2004 15:46:44 +0000
Message-ID: <[e-mail]>
Date: Wed, 24 Nov 2004 16:45:23 +0100
From: Loa Andersson <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803
MIME-Version: 1.0
To: [e-mail]
CC: George Swallow <[e-mail]>, Alex Zinin <[e-mail]>, Bill Fenner <[e-mail]>, [e-mail]
Subject: MPLS wg last call on re-spun bundling draft
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Working group,

this is to initiate a 2 weeks working group last call on
<draft-ietf-mpls-bundle-05.txt>

The CCAMP working is copied on this MPLS working group last,
since there are interdependencies between specifications from
both working groups. Pleae use the MPLS mailing list for
comments, cross-publishing is not necessary.

Background: This draft was reviewed by the IESG and approved
for publication. During implementation there were some issues
found and it was decided to pull the draft from the RFC Editors
queue. This wg last call is limited to these issues and how
they been addressed only.

The list of issues and how the authors has addresed has been
sent to the mailing list(s). That text is also included in this
mail.

For the record please note that I've asked the authors to
update some ID-nits, those are not part of the wg last call.
But has been included just to make it easier to progress the
document through IESG review.

This working group last call ends on EOB December 10 PST.

/Loa

------- issues and how they been addressed -------------
Here is the summary:

draft-ietf-mpls-bundle-05.txt has been updated to reflect
the comments made in the MPLS WG and on the list.  The issues
raised are:

1. Scope of component identifiers is open to interpretation
    (i.e., node vs link)
2. No way to specify different upstream and downstream components
    then using TLV types 1, 2 and 3
3. Ambiguity of contents of the IP address field in TLV types 3, 4, 5
4. Lack of IPv6 support for types 3, 4, and 5.
5. Ambiguity of when to use types 4 and 5 and when to use type 3.
6. No coverage of ERO and RRO implications

These issues have been addressed in the following ways:

Issue 1:  The -05 document states that all component link TLV types
           have Node/IP scope
Issue 2: -05 Tightly defines support for different components in each
           direction (for bidirectional LSPs, and for all TLV types)
Issue 3: Format of the Value field for types 3, 4 and 5 now has the
           identical format as the contents of the C-Type 1
           LSP_TUNNEL_INTERFACE_ID object defined in [RFC3477].
Issue 4: Based on the previous change, support of IPv6 unnumbered
           components is now tied to, and the same as, the support of
           IPv6 unnumber TE links.
Issue 5: -05 allows, but recommend against use of types 4 and 5
Issue 6: EROs, RROs remain out of scope of bundling document

Current planned changes are:
- Fix nits found by Adrian and Loa
- Insert a Table of Contents
- Section numbering will remain unchanged so as not to break
   any potentially existing references to the draft

Yakov.
-------------------- end of included text --------------------

Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  [phone]
Isafjordsgatan 22                  mobile: [phone]
Kista, Sweden                      email:  [e-mail]
                                            [e-mail]



Envelope-to: [e-mail]
Delivery-date: Wed, 24 Nov 2004 15:37:59 +0000
Message-ID: <008201c4d23b$83c58580$[e-mail]>
From: "Igor Bryskin" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: RS-DT Wrap-Up Statements
Date: Wed, 24 Nov 2004 10:37:32 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Dimitri,

Do you think it is reasonable/practical to separate routing controller from
signaling controller and consider scenarios such as a single routing
controller manages (provides advertisements) for several transport nodes
with each of the latter having a dedicated signaling controller for TE
tunnel provisioning?

Also, how in your opinion a signaling controller knows which address to send
Path message for the next hop along the path.
Possible options:
a) ID of a numbered link is routable or RouterID in unnumbered ERO
sub-object (which is transport node ID) is routable;
b) necessary binding (neighbor linkID=> neighbor signaling address, neighbor
nodeID=> neighbor signaling address) is provided via LMP

Thanks,
Igor


----- Original Message ----- 
From: "dimitri papadimitriou" <[e-mail]>
To: <[e-mail]>
Sent: Wednesday, November 24, 2004 4:25 AM
Subject: RS-DT Wrap-Up Statements


> folks -
>
> The initial evaluation phase of existing routing protocols required
> definition of a common pattern. The definition of this pattern last
> until beginning of november (input from several parties) now that pieces
> are in place needs to move a step further.
>
> The evaluation document will be issued by end-november to close this
> first phase. The content of this document will be articulated around the
> below terminology, scenarios and features.
>
> 1. Terminology:
> --------------
>
> - Pi is a physical node (bearer/data/transport plane) node
> - Li is a logical control plane identifier that is associated to a
>    single data plane (abstract) node
>    Li = logical node id or "TE router id" i.e. for
>    . RFC 3630: Router_Address (top level) TLV of the Type 1 TE LSA
>    . RFC 3784: Traffic Engineering Router ID TLV (Type 134)
> - Ri is a control plane "router" e.g. (advertising) Router_ID i.e.
>    . RFC 2328: Router ID (32-bit)
>    . RFC 1195: IS-IS System ID (48-bit)
>
> Note: in the below Figure 1.
> - R3 represents an LSR with all components collocated.
> - R2 shows how the "router" component may be disjoint from the node
> - R1 shows how a single "router" may manage multiple nodes
>
> The Router_ID (represented by Ri) does not enter into the identification
> of the logical entities representing the data plane resources such as
> links. The Routing DataBase (RDB) is associated to the Ri.
>
> Note: the "signaling controller" i.e. the control plane entity that
> processes the signaling messages (referred to as Si) is not represented
> in these Figures. Multiple signalling controllers can be associated to
> one Ri and make use of the path computation function associated to the Ri.
>
> 2. Mechanisms:
> -------------
>
> Focus is on routing information exchange between Ri entities (through
> routing adjacencies) within single hierarchical level. Routing
> information mapping between levels may require specific guidelines.
>
> The control plane does not transport Pi information as these are data
> plane addresses for which the the Li/Pi mapping is kept (link) local -
> see for instance the transport LMP document where such exchange is
> described. Example: the transport plane identifier is the Pi (the
> identifier assigned to the physical element) be for instance
> "666B.F999.AF10.222C", the control plane identifier is the Li (the
> identifier assigned by the control plane), be for instance "1.1.1.1".
> The control plane exchanges the control plane identifier information but
> not the transport plane identifier information (i.e. not
> "666B.F999.AF10.222C" but only "1.1.1.1"), The mapping Li/Pi is kept
> local. So, when the Si receives a control plane message requesting the
> use of "1.1.1.1", Si knows locally that this information refers to the
> data plane entity identified by the transport plane identifier
> "666B.F999.AF10.222C".
>
> The control plane carries:
> 1) its view of the data plane link end-points and other link connection
> end-points - note: advertisement of reachability can be achieved using
> the techniques described in
> <http://www.ietf.org/internet-drafts/draft-ietf-ospf-te-node-addr-01.txt>
>
> 2) the identifiers scoped by the Li's i.e. we speak about an associated
> IPv4/IPv6 addressing space;
>
> Evalution Scenarios:
> -------------------
>
> The scenarios are the following: resp. case 1), 2) and 3)
>
>               -------------------     ------
>              |R1                 |   |R2     |
>              |                   |   |       |    ------
>              |  L1    L2    L3   |   |   L4  |   |R3    |
>              |   :     :     :   |   |   :   |   |      |
>              |   :     :     :   |   |   :   |   |  L5  |
> Control      ---+-----+-----+---     ---+---    |   :  |
> Plane           :     :     :           :       |   :  |
> ----------------+-----+-----+-----------+-------+---+--+-
> Data            :     :     :           :       |   :  |
> Plane          --     :    --          --       |  --  |
>            ----|P1|--------|P3|--------|P4|------+-|P5|-+-
>                 -- \   :  / --          --       |  --  |
>                     \ -- /                       |      |
>                      |P2|                         ------
>                       --
>
> case 1) as represented either direct links between edges or "logical
> links" as per below figure (or any combination of them)
>
>                  ------                        ------
>                 |      |                      |      |
>                 |  L1  |                      |  L2  |
>                 |  :   |                      |  :   |
>                 |  : R1|                      |  : R2|
> Control Plane   --+---                        --+---
> Elements          :                             :
> ------------------+-----------------------------+------------------
> Data Plane        :                             :
> Elements          :                             :
>                ----+-----------------------------+-----
>               |    :                             :     |
>               |   ---            ---            ---    |
>               |  |   |----------| P |----------|   |   |
>            ---+--|   |           ---           |   |---+---
>               |  |   |                         |   |   |
>               |  | P1|-------------------------| P2|   |
>               |   ---                           ---    |
>                ----------------------------------------
>
> Another case is constituted by the Abstract Node as represented in the
> below figure. There is no internal structure associated to the abstract
> node.
>
>                      --------------
>                     |R4            |
>                     |              |
>                     |      L6      |
>                     |       :      |
>                     |    ......    |
>                      ---:------:---
> Control Plane          :      :
>                  +------+------+------+
> Data Plane             :      :
>                      ---:------:---
>                     |P8 :      :   |
>                     |  --      --  |
>                   --+-|P |----|P |-+--
>                     |  --      --  |
>                      --------------
>
> Note: base scenarios (being not combinations or decomposition of
> entities) can further complete this set
>
> 4. Specific Considerations
>     -----------------------
>
> Representation of bandwidth requires further analysis i.e. GMPLS Routing
> defines an Interface Switching Capability Descriptor (ISCD) that
> delivers information about the (maximum/minimum) bandwidth per priority
> an LSP can make use of. In the ASON context, other representations are
> possible, e.g. in terms of a set of tuples <signal_type; number of
> unallocated timeslots>. The latter also may require definition of
> additional signal types (from those defined in RFC 3496) to represent
> contiguous concatenation i.e. STS-(3xN)c SPE / VC-4-Nc, N = 4, 16, 64,
256.
>
> The GMPLS routing method proposed in GMPLS Routing is the most
> straightforward without requiring any bandwidth accounting change from
> an LSR perspective. However, it introduces some lost of information.
> This lost of information affects the number of signals that can be used
> but not the range they cover. On the other hand, if additional
> technology specific information (such as capabilities) are advertised a
> finer grained resource countdown and accounting can be performed
> allowing for network wide resource allocation in Sonet/SDH environments.
>
>
>
>
>
>
>
>




Envelope-to: [e-mail]
Delivery-date: Wed, 24 Nov 2004 15:24:28 +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: New charter
Date: Wed, 24 Nov 2004 09:24:13 -0600
Message-ID: <[e-mail]>
Thread-Topic: New charter
Thread-Index: AcTR7jGaDjucPYCASRKcfE2WgKumLQAStlwg
From: "Brungard, Deborah A, ALABS" <[e-mail]>
To: "Kireeti Kompella" <[e-mail]>, <[e-mail]>

Yes to all (also see (6) as part of (2), and not sure title of (2) is
interoperability issues or more appropriately clarification (e.g. the
egress control draft)).
Deborah=20

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Kireeti Kompella
Sent: Wednesday, November 24, 2004 1:22 AM
To: [e-mail]
Subject: New charter

On Mon, 15 Nov 2004, Kireeti Kompella wrote:

> If you have suggested charter updates, please send them to Adrian
> and me.

Thanks all for your input.  I have the following items; for each,
please say "Yes" (should be added to CCAMP charter), "No" (should not
be added) or "-" (don't care).  I'll remind you once again that not
all items will make it onto the new charter.

Please keep this subject line (simply reply to this mail).  The
deadline is Friday Dec 3, 17:00 PST.

1) MPLS-GMPLS migration
2) GMPLS interoperability issues
3a) should the IETF take on L1VPNs?
3b) if yes to 3a, should this be done in CCAMP?
4) Waveband switching
5) Control plane work
6) Decoder ring for addresses
7) Deployment considerations for GMPLS
8) PCE requirements
9) QoS control

A rough idea of what each of the above entails follows.

1) MPLS-GMPLS migration
	implementation shift from "MPLS" objects to "GMPLS" objects
	BCP on deployment migration for the same

2) GMPLS interoperability issues
	what addresses to use where
	nits/clarifications of the specs
	guidelines for path computation & constraints
	survay

3) L1VPN work items
	identify protocol extensions needed
	state what can already be done with what we have
	do the actual protocol work for requirements that are not met
	liaisons to SG13 as needed

5) Control plane work
	resiliency
	graceful shutdown

6) Decoder ring for addresses
	for each address field, identify its nature and ITU equivalent
	(may overlap with part of (2))


4, 7-9 are obvious or have been elaborated on the mailing list.

Kireeti.
-------

PS: The topic of GTTP has carefully been avoided.  More later.





Envelope-to: [e-mail]
Delivery-date: Wed, 24 Nov 2004 15:19:18 +0000
Message-ID: <B258A372CEA20246A363BB86753DB536E2C458@zrtphxm2>
From: "Don Fedyk" <[e-mail]>
To: Kireeti Kompella <[e-mail]>, [e-mail]
Subject: RE: New charter
Date: Wed, 24 Nov 2004 10:18:19 -0500

Hi Kireeti

See Inline

<snip>
>Please keep this subject line (simply reply to this mail).  The
>deadline is Friday Dec 3, 17:00 PST.
>
>1) MPLS-GMPLS migration 
Yes

>2) GMPLS interoperability issues 
Yes

>3a) should the IETF take on L1VPNs? 
yes (as you outlined below)

>3b) if yes to 3a, should this be done in CCAMP?  
yes 

>4) Waveband switching 
I suppose Protocol aspects

>5) Control plane work
Yes

>6) Decoder ring for addresses
Is this IETF -> ITU or ITU -> IETF or both ? I think should be both. 

>7) Deployment considerations for GMPLS
Yes

>8) PCE requirements 
Depends on if there is PCE WG. Why not in PCE WG? 
  
>9) QoS control
Not sure what this is ? I missed it.
 
>
>A rough idea of what each of the above entails follows.
>
>1) MPLS-GMPLS migration implementation shift from "MPLS" objects
>to "GMPLS" objects BCP on deployment migration for the same
>
>2) GMPLS interoperability issues what addresses to use where
>nits/clarifications of the specs guidelines for path computation
>& constraints survay
>
>3) L1VPN work items identify protocol extensions needed state
>what can already be done with what we have do the actual
>protocol work for requirements that are not met liaisons to SG13
>as needed
>
>5) Control plane work resiliency graceful shutdown
>
>6) Decoder ring for addresses for each address field, identify
>its nature and ITU equivalent (may overlap with part of (2))
>
>
>4, 7-9 are obvious or have been elaborated on the mailing list.
>
>Kireeti.  -------
>
>PS: The topic of GTTP has carefully been avoided.  More later.
>
>
>
Regards,
Don 



Envelope-to: [e-mail]
Delivery-date: Wed, 24 Nov 2004 15:02:15 +0000
Message-ID: <[e-mail]>
From: "Hamid Ould-Brahim" <[e-mail]>
To: Kireeti Kompella <[e-mail]>, [e-mail]
Subject: RE: New charter
Date: Wed, 24 Nov 2004 10:01:44 -0500

Kireeti,

> 
> 1) MPLS-GMPLS migration

Yes.

> 2) GMPLS interoperability issues

Yes.

> 3a) should the IETF take on L1VPNs?

Definitely Yes.

> 3b) if yes to 3a, should this be done in CCAMP?

Yes.

> 4) Waveband switching
> 5) Control plane work
> 6) Decoder ring for addresses
> 7) Deployment considerations for GMPLS
> 8) PCE requirements
> 9) QoS control
> 

Yes to all.

Hamid.




Envelope-to: [e-mail]
Delivery-date: Wed, 24 Nov 2004 14:56:32 +0000
Message-ID: <007301c4d235$b45893a0$[e-mail]>
From: "Igor Bryskin" <[e-mail]>
To: "Kireeti Kompella" <[e-mail]>, <[e-mail]>
Subject: Re: New charter
Date: Wed, 24 Nov 2004 09:55:57 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

My vote is in-line.
Igor

----- Original Message ----- 
From: "Kireeti Kompella" <[e-mail]>
To: <[e-mail]>
Sent: Wednesday, November 24, 2004 1:22 AM
Subject: New charter


> On Mon, 15 Nov 2004, Kireeti Kompella wrote:
> 
> > If you have suggested charter updates, please send them to Adrian
> > and me.
> 
> Thanks all for your input.  I have the following items; for each,
> please say "Yes" (should be added to CCAMP charter), "No" (should not
> be added) or "-" (don't care).  I'll remind you once again that not
> all items will make it onto the new charter.
> 
> Please keep this subject line (simply reply to this mail).  The
> deadline is Friday Dec 3, 17:00 PST.
> 
> 1) MPLS-GMPLS migration
Yes

> 2) GMPLS interoperability issues
Yes

> 3a) should the IETF take on L1VPNs?
Yes

> 3b) if yes to 3a, should this be done in CCAMP?
Yes

> 4) Waveband switching


> 5) Control plane work
Yes, but should be stated more clearly.
In addition to waht other people said I'd like to add:
Managing of control plane partitioned LSPs 

> 6) Decoder ring for addresses

> 7) Deployment considerations for GMPLS
Yes,

> 8) PCE requirements
Yes, and I'd like it not to be limited by inter-domain LSPs

> 9) QoS control
I am not sure about that. Isn't MPLS/GMPLS is mostly about already ?

> 
> A rough idea of what each of the above entails follows.
> 
> 1) MPLS-GMPLS migration
> implementation shift from "MPLS" objects to "GMPLS" objects
> BCP on deployment migration for the same
> 
> 2) GMPLS interoperability issues
> what addresses to use where
> nits/clarifications of the specs
> guidelines for path computation & constraints
> survay
> 
> 3) L1VPN work items
> identify protocol extensions needed
> state what can already be done with what we have
> do the actual protocol work for requirements that are not met
> liaisons to SG13 as needed
> 
> 5) Control plane work
> resiliency
> graceful shutdown
> 
> 6) Decoder ring for addresses
> for each address field, identify its nature and ITU equivalent
> (may overlap with part of (2))
> 
> 
> 4, 7-9 are obvious or have been elaborated on the mailing list.
> 
> Kireeti.
> -------
> 
> PS: The topic of GTTP has carefully been avoided.  More later.
> 



Envelope-to: [e-mail]
Delivery-date: Wed, 24 Nov 2004 14:04:29 +0000
Message-ID: <[e-mail]>
Date: Wed, 24 Nov 2004 15:03:09 +0100
From: Loa Andersson <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803
MIME-Version: 1.0
To: Kireeti Kompella <[e-mail]>
CC: [e-mail], [e-mail], [e-mail]
Subject: Re: New charter
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Kireeti,

not entirely happy to let the IESG do the pruning,
so the most important to me is 5 (control plane)
and 8 (PCE requirments)

/Loa

Kireeti Kompella wrote:

> Hi Loa,
> 
> On Wed, 24 Nov 2004, Loa Andersson wrote:
> 
> 
>>I tend to agree with Dimitri, one concern is that
>>this could be rather big, do we want to prioritize
>>or is that implied in the numbering
> 
> 
> It is rather big, as I am trying to capture all the ideas of the
> community.  I don't expect that all the proposals will get enough
> support for "rough consensus"; in any case, even if all of them did,
> the IESG would very quickly prune the list :-)
> 
> There is *no* intended priority in the numbering!
> 
> Kireeti.
> -------
> 
> 

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  [phone]
Isafjordsgatan 22                  mobile: [phone]
Kista, Sweden                      email:  [e-mail]
                                            [e-mail]



Envelope-to: [e-mail]
Delivery-date: Wed, 24 Nov 2004 14:03:13 +0000
From: "Zafar Ali" <[e-mail]>
To: "'Kireeti Kompella'" <[e-mail]>, <[e-mail]>
Subject: RE: New charter
Date: Wed, 24 Nov 2004 09:01:49 -0500
Message-ID: <018c01c4d22e$25307dc0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Kireeti, 

Reply in-lined.

Thanks

Regards... Zafar

<snip>
>
>1) MPLS-GMPLS migration

Yes, .... You may like to rename it as from name it appears that there is a
lot of overlap of this with "7) Deployment considerations for GMPLS". 

>2) GMPLS interoperability issues

Yes, 

>3a) should the IETF take on L1VPNs?

Yes, 

>3b) if yes to 3a, should this be done in CCAMP?

Yes, 

>4) Waveband switching
>5) Control plane work

Yes, but the name is too board, may like to rename it, e.g., Control plane
resiliency and GS. 

>6) Decoder ring for addresses
>7) Deployment considerations for GMPLS

Yes, 

>8) PCE requirements

Yes, 

>9) QoS control
>
>A rough idea of what each of the above entails follows.
>
>1) MPLS-GMPLS migration
>	implementation shift from "MPLS" objects to "GMPLS" objects
>	BCP on deployment migration for the same
>
>2) GMPLS interoperability issues
>	what addresses to use where
>	nits/clarifications of the specs
>	guidelines for path computation & constraints
>	survay
>
>3) L1VPN work items
>	identify protocol extensions needed
>	state what can already be done with what we have
>	do the actual protocol work for requirements that are not met
>	liaisons to SG13 as needed
>
>5) Control plane work
>	resiliency
>	graceful shutdown
>
>6) Decoder ring for addresses
>	for each address field, identify its nature and ITU equivalent
>	(may overlap with part of (2))
>
>
>4, 7-9 are obvious or have been elaborated on the mailing list.
>
>Kireeti.
>-------
>
>PS: The topic of GTTP has carefully been avoided.  More later.
>




Envelope-to: [e-mail]
Delivery-date: Wed, 24 Nov 2004 12:19:00 +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: New charter
Date: Wed, 24 Nov 2004 06:17:47 -0600
Message-ID: <[e-mail]>
Thread-Topic: New charter
Thread-Index: AcTR7jHYf1aWHppfSfmVwFXRIKhHWwAMUK1A
From: "Ash, Gerald R \(Jerry\), ALABS" <[e-mail]>
To: "Kireeti Kompella" <[e-mail]>, <[e-mail]>
Cc: "Ash, Gerald R \(Jerry\), ALABS" <[e-mail]>

> please say "Yes" (should be added to CCAMP charter),=20
> "No" (should not be added) or "-" (don't care).

Yes to all.

Jerry



Envelope-to: [e-mail]
Delivery-date: Wed, 24 Nov 2004 11:53:21 +0000
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
Cc: [e-mail]
From: JP Vasseur <[e-mail]>
Subject: Re: New charter
Date: Wed, 24 Nov 2004 06:45:42 -0500
To: Kireeti Kompella <[e-mail]>

Hi Kireeti,

On Nov 24, 2004, at 1:22 AM, Kireeti Kompella wrote:

> On Mon, 15 Nov 2004, Kireeti Kompella wrote:
>
>> If you have suggested charter updates, please send them to Adrian
>> and me.
>
> Thanks all for your input.  I have the following items; for each,
> please say "Yes" (should be added to CCAMP charter), "No" (should not
> be added) or "-" (don't care).  I'll remind you once again that not
> all items will make it onto the new charter.
>
> Please keep this subject line (simply reply to this mail).  The
> deadline is Friday Dec 3, 17:00 PST.
>
> 1) MPLS-GMPLS migration
>
yes
> 2) GMPLS interoperability issues
>
yes
> 3a) should the IETF take on L1VPNs?
> 3b) if yes to 3a, should this be done in CCAMP?
>
yes
> 4) Waveband switching
>
yes
> 5) Control plane work
>
yes
> 6) Decoder ring for addresses
>
-
> 7) Deployment considerations for GMPLS
>
yes
> 8) PCE requirements
>
More precisely "PCE requirements for Inter-domain" which is the main 
objective of the potential future WG.
Other PCE requirements amy either be done in the PCE WG or may come 
from other WG in the future,
> 9) QoS control
>
yes

JP.

> A rough idea of what each of the above entails follows.
>
> 1) MPLS-GMPLS migration
> 	implementation shift from "MPLS" objects to "GMPLS" objects
> 	BCP on deployment migration for the same
>
> 2) GMPLS interoperability issues
> 	what addresses to use where
> 	nits/clarifications of the specs
> 	guidelines for path computation & constraints
> 	survay
>
> 3) L1VPN work items
> 	identify protocol extensions needed
> 	state what can already be done with what we have
> 	do the actual protocol work for requirements that are not met
> 	liaisons to SG13 as needed
>
> 5) Control plane work
> 	resiliency
> 	graceful shutdown
>
> 6) Decoder ring for addresses
> 	for each address field, identify its nature and ITU equivalent
> 	(may overlap with part of (2))
>
>
> 4, 7-9 are obvious or have been elaborated on the mailing list.
>
> Kireeti.
> -------
>
> PS: The topic of GTTP has carefully been avoided.  More later.
>
>




Envelope-to: [e-mail]
Delivery-date: Wed, 24 Nov 2004 10:54:52 +0000
Date: Wed, 24 Nov 2004 02:53:44 -0800 (PST)
From: Kireeti Kompella <[e-mail]>
To: Loa Andersson <[e-mail]>
cc: [e-mail], [e-mail], [e-mail]
Subject: Re: New charter
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi Loa,

On Wed, 24 Nov 2004, Loa Andersson wrote:

> I tend to agree with Dimitri, one concern is that
> this could be rather big, do we want to prioritize
> or is that implied in the numbering

It is rather big, as I am trying to capture all the ideas of the
community.  I don't expect that all the proposals will get enough
support for "rough consensus"; in any case, even if all of them did,
the IESG would very quickly prune the list :-)

There is *no* intended priority in the numbering!

Kireeti.
-------



Envelope-to: [e-mail]
Delivery-date: Wed, 24 Nov 2004 09:50:47 +0000
Message-ID: <[e-mail]>
Date: Wed, 24 Nov 2004 10:48:01 +0100
From: Loa Andersson <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803
MIME-Version: 1.0
To: [e-mail], [e-mail]
CC: Kireeti Kompella <[e-mail]>, [e-mail]
Subject: Re: New charter
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Kireeti,

I tend to agree with Dimitri, one concern is that
this could be rather big, do we want to prioritize
or is that implied in the numbering

/Loa

dimitri papadimitriou wrote:

> hi kireeti,
> 
>  > 1) MPLS-GMPLS migration
> 
> yes
> 
>  > 2) GMPLS interoperability issues
> 
> yes
> 
>  > 3a) should the IETF take on L1VPNs?
> 
> yes
> 
>  > 3b) if yes to 3a, should this be done in CCAMP?
> 
> as first option (note: with the current standpoint, could this done 
> elsewhere ?)
> 
>  > 4) Waveband switching
> 
> yes (note: need more support as rather limited since so far)
> 
>  > 5) Control plane work
> 
> yes ("document" CP resiliency and GS)
> 
>  > 6) Decoder ring for addresses
> 
> part of this work is in (2) and other should be part of the ongoing ASON 
> work
> 
>  > 7) Deployment considerations for GMPLS
> 
> is this an embryon of "gmplsops" ? in favor
> 
>  > 8) PCE requirements
> 
> yes
> 
>  > 9) QoS control
> 
> yes
> 
> ---
> 
> Kireeti Kompella wrote:
> 
>> On Mon, 15 Nov 2004, Kireeti Kompella wrote:
>>
>>
>>> If you have suggested charter updates, please send them to Adrian
>>> and me.
>>
>>
>>
>> Thanks all for your input.  I have the following items; for each,
>> please say "Yes" (should be added to CCAMP charter), "No" (should not
>> be added) or "-" (don't care).  I'll remind you once again that not
>> all items will make it onto the new charter.
>>
>> Please keep this subject line (simply reply to this mail).  The
>> deadline is Friday Dec 3, 17:00 PST.
>>
>> 1) MPLS-GMPLS migration
>> 2) GMPLS interoperability issues
>> 3a) should the IETF take on L1VPNs?
>> 3b) if yes to 3a, should this be done in CCAMP?
>> 4) Waveband switching
>> 5) Control plane work
>> 6) Decoder ring for addresses
>> 7) Deployment considerations for GMPLS
>> 8) PCE requirements
>> 9) QoS control
>>
>> A rough idea of what each of the above entails follows.
>>
>> 1) MPLS-GMPLS migration
>>     implementation shift from "MPLS" objects to "GMPLS" objects
>>     BCP on deployment migration for the same
>>
>> 2) GMPLS interoperability issues
>>     what addresses to use where
>>     nits/clarifications of the specs
>>     guidelines for path computation & constraints
>>     survay
>>
>> 3) L1VPN work items
>>     identify protocol extensions needed
>>     state what can already be done with what we have
>>     do the actual protocol work for requirements that are not met
>>     liaisons to SG13 as needed
>>
>> 5) Control plane work
>>     resiliency
>>     graceful shutdown
>>
>> 6) Decoder ring for addresses
>>     for each address field, identify its nature and ITU equivalent
>>     (may overlap with part of (2))
>>
>>
>> 4, 7-9 are obvious or have been elaborated on the mailing list.
>>
>> Kireeti.
>> -------
>>
>> PS: The topic of GTTP has carefully been avoided.  More later.
>>
>>
>> .
>>
> 
> 
> 

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  [phone]
Isafjordsgatan 22                  mobile: [phone]
Kista, Sweden                      email:  [e-mail]
                                            [e-mail]



Envelope-to: [e-mail]
Delivery-date: Wed, 24 Nov 2004 09:25:30 +0000
Message-ID: <[e-mail]>
Date: Wed, 24 Nov 2004 10:25:20 +0100
From: dimitri papadimitriou <[e-mail]>
Reply-To:  [e-mail],  [e-mail],  [e-mail],  [e-mail],  [e-mail],  [e-mail],  [e-mail],  [e-mail],  [e-mail],  [e-mail],  [e-mail],  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910
MIME-Version: 1.0
To:  [e-mail]
Subject: RS-DT Wrap-Up Statements
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

folks -

The initial evaluation phase of existing routing protocols required
definition of a common pattern. The definition of this pattern last
until beginning of november (input from several parties) now that pieces 
are in place needs to move a step further.

The evaluation document will be issued by end-november to close this
first phase. The content of this document will be articulated around the
below terminology, scenarios and features.

1. Terminology:
--------------

- Pi is a physical node (bearer/data/transport plane) node
- Li is a logical control plane identifier that is associated to a
   single data plane (abstract) node
   Li = logical node id or "TE router id" i.e. for
   . RFC 3630: Router_Address (top level) TLV of the Type 1 TE LSA
   . RFC 3784: Traffic Engineering Router ID TLV (Type 134)
- Ri is a control plane "router" e.g. (advertising) Router_ID i.e.
   . RFC 2328: Router ID (32-bit)
   . RFC 1195: IS-IS System ID (48-bit)

Note: in the below Figure 1.
- R3 represents an LSR with all components collocated.
- R2 shows how the "router" component may be disjoint from the node
- R1 shows how a single "router" may manage multiple nodes

The Router_ID (represented by Ri) does not enter into the identification
of the logical entities representing the data plane resources such as
links. The Routing DataBase (RDB) is associated to the Ri.

Note: the "signaling controller" i.e. the control plane entity that
processes the signaling messages (referred to as Si) is not represented
in these Figures. Multiple signalling controllers can be associated to
one Ri and make use of the path computation function associated to the Ri.

2. Mechanisms:
-------------

Focus is on routing information exchange between Ri entities (through
routing adjacencies) within single hierarchical level. Routing
information mapping between levels may require specific guidelines.

The control plane does not transport Pi information as these are data
plane addresses for which the the Li/Pi mapping is kept (link) local -
see for instance the transport LMP document where such exchange is
described. Example: the transport plane identifier is the Pi (the
identifier assigned to the physical element) be for instance
"666B.F999.AF10.222C", the control plane identifier is the Li (the
identifier assigned by the control plane), be for instance "1.1.1.1".
The control plane exchanges the control plane identifier information but
not the transport plane identifier information (i.e. not
"666B.F999.AF10.222C" but only "1.1.1.1"), The mapping Li/Pi is kept
local. So, when the Si receives a control plane message requesting the
use of "1.1.1.1", Si knows locally that this information refers to the
data plane entity identified by the transport plane identifier
"666B.F999.AF10.222C".

The control plane carries:
1) its view of the data plane link end-points and other link connection
end-points - note: advertisement of reachability can be achieved using
the techniques described in
<http://www.ietf.org/internet-drafts/draft-ietf-ospf-te-node-addr-01.txt>
	
2) the identifiers scoped by the Li's i.e. we speak about an associated
IPv4/IPv6 addressing space;

Evalution Scenarios:
-------------------

The scenarios are the following: resp. case 1), 2) and 3)

              -------------------     ------
             |R1                 |   |R2     |
             |                   |   |       |    ------
             |  L1    L2    L3   |   |   L4  |   |R3    |
             |   :     :     :   |   |   :   |   |      |
             |   :     :     :   |   |   :   |   |  L5  |
Control      ---+-----+-----+---     ---+---    |   :  |
Plane           :     :     :           :       |   :  |
----------------+-----+-----+-----------+-------+---+--+-
Data            :     :     :           :       |   :  |
Plane          --     :    --          --       |  --  |
           ----|P1|--------|P3|--------|P4|------+-|P5|-+-
                -- \   :  / --          --       |  --  |
                    \ -- /                       |      |
                     |P2|                         ------
                      --

case 1) as represented either direct links between edges or "logical
links" as per below figure (or any combination of them)

                 ------                        ------
                |      |                      |      |
                |  L1  |                      |  L2  |
                |  :   |                      |  :   |
                |  : R1|                      |  : R2|
Control Plane   --+---                        --+---
Elements          :                             :
------------------+-----------------------------+------------------
Data Plane        :                             :
Elements          :                             :
               ----+-----------------------------+-----
              |    :                             :     |
              |   ---            ---            ---    |
              |  |   |----------| P |----------|   |   |
           ---+--|   |           ---           |   |---+---
              |  |   |                         |   |   |
              |  | P1|-------------------------| P2|   |
              |   ---                           ---    |
               ----------------------------------------

Another case is constituted by the Abstract Node as represented in the
below figure. There is no internal structure associated to the abstract
node.

                     --------------
                    |R4            |
                    |              |
                    |      L6      |
                    |       :      |
                    |    ......    |
                     ---:------:---
Control Plane          :      :
                 +------+------+------+
Data Plane             :      :
                     ---:------:---
                    |P8 :      :   |
                    |  --      --  |
                  --+-|P |----|P |-+--
                    |  --      --  |
                     --------------

Note: base scenarios (being not combinations or decomposition of
entities) can further complete this set

4. Specific Considerations
    -----------------------

Representation of bandwidth requires further analysis i.e. GMPLS Routing
defines an Interface Switching Capability Descriptor (ISCD) that
delivers information about the (maximum/minimum) bandwidth per priority
an LSP can make use of. In the ASON context, other representations are
possible, e.g. in terms of a set of tuples <signal_type; number of
unallocated timeslots>. The latter also may require definition of
additional signal types (from those defined in RFC 3496) to represent
contiguous concatenation i.e. STS-(3xN)c SPE / VC-4-Nc, N = 4, 16, 64, 256.

The GMPLS routing method proposed in GMPLS Routing is the most
straightforward without requiring any bandwidth accounting change from
an LSR perspective. However, it introduces some lost of information.
This lost of information affects the number of signals that can be used
but not the range they cover. On the other hand, if additional
technology specific information (such as capabilities) are advertised a
finer grained resource countdown and accounting can be performed
allowing for network wide resource allocation in Sonet/SDH environments.










Envelope-to: [e-mail]
Delivery-date: Wed, 24 Nov 2004 09:22:21 +0000
Message-ID: <[e-mail]>
Date: Wed, 24 Nov 2004 10:20:29 +0100
From: dimitri papadimitriou <[e-mail]>
Reply-To:  [e-mail],  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910
MIME-Version: 1.0
To: Kireeti Kompella <[e-mail]>
CC:  [e-mail]
Subject: Re: New charter
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

hi kireeti,

 > 1) MPLS-GMPLS migration

yes

 > 2) GMPLS interoperability issues

yes

 > 3a) should the IETF take on L1VPNs?

yes

 > 3b) if yes to 3a, should this be done in CCAMP?

as first option (note: with the current standpoint, could this done 
elsewhere ?)

 > 4) Waveband switching

yes (note: need more support as rather limited since so far)

 > 5) Control plane work

yes ("document" CP resiliency and GS)

 > 6) Decoder ring for addresses

part of this work is in (2) and other should be part of the ongoing ASON 
work

 > 7) Deployment considerations for GMPLS

is this an embryon of "gmplsops" ? in favor

 > 8) PCE requirements

yes

 > 9) QoS control

yes

---

Kireeti Kompella wrote:

> On Mon, 15 Nov 2004, Kireeti Kompella wrote:
> 
> 
>>If you have suggested charter updates, please send them to Adrian
>>and me.
> 
> 
> Thanks all for your input.  I have the following items; for each,
> please say "Yes" (should be added to CCAMP charter), "No" (should not
> be added) or "-" (don't care).  I'll remind you once again that not
> all items will make it onto the new charter.
> 
> Please keep this subject line (simply reply to this mail).  The
> deadline is Friday Dec 3, 17:00 PST.
> 
> 1) MPLS-GMPLS migration
> 2) GMPLS interoperability issues
> 3a) should the IETF take on L1VPNs?
> 3b) if yes to 3a, should this be done in CCAMP?
> 4) Waveband switching
> 5) Control plane work
> 6) Decoder ring for addresses
> 7) Deployment considerations for GMPLS
> 8) PCE requirements
> 9) QoS control
> 
> A rough idea of what each of the above entails follows.
> 
> 1) MPLS-GMPLS migration
> 	implementation shift from "MPLS" objects to "GMPLS" objects
> 	BCP on deployment migration for the same
> 
> 2) GMPLS interoperability issues
> 	what addresses to use where
> 	nits/clarifications of the specs
> 	guidelines for path computation & constraints
> 	survay
> 
> 3) L1VPN work items
> 	identify protocol extensions needed
> 	state what can already be done with what we have
> 	do the actual protocol work for requirements that are not met
> 	liaisons to SG13 as needed
> 
> 5) Control plane work
> 	resiliency
> 	graceful shutdown
> 
> 6) Decoder ring for addresses
> 	for each address field, identify its nature and ITU equivalent
> 	(may overlap with part of (2))
> 
> 
> 4, 7-9 are obvious or have been elaborated on the mailing list.
> 
> Kireeti.
> -------
> 
> PS: The topic of GTTP has carefully been avoided.  More later.
> 
> 
> .
> 



Envelope-to: [e-mail]
Delivery-date: Wed, 24 Nov 2004 07:27:01 +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 : New charter
Date: Wed, 24 Nov 2004 08:25:49 +0100
Message-ID: <[e-mail]>
Thread-Topic: New charter
Thread-Index: AcTR75UaHP9MAxOVREWzGN3L+N3dAwABqjXw
From: "LE ROUX Jean-Louis RD-CORE-LAN" <[e-mail]>
To: "Kireeti Kompella" <[e-mail]>, <[e-mail]>

Hi Kireeti and all

Yes to all, except 3b: Don't care

JL

>-----Message d'origine-----
>De : [e-mail]=20
>[mailto:[e-mail]] De la part de Kireeti Kompella
>Envoy=E9 : mercredi 24 novembre 2004 07:22
>=C0 : [e-mail]
>Objet : New charter
>
>
>On Mon, 15 Nov 2004, Kireeti Kompella wrote:
>
>> If you have suggested charter updates, please send them to=20
>Adrian and=20
>> me.
>
>Thanks all for your input.  I have the following items; for=20
>each, please say "Yes" (should be added to CCAMP charter),=20
>"No" (should not be added) or "-" (don't care).  I'll remind=20
>you once again that not all items will make it onto the new charter.
>
>Please keep this subject line (simply reply to this mail). =20
>The deadline is Friday Dec 3, 17:00 PST.
>
>1) MPLS-GMPLS migration
>2) GMPLS interoperability issues
>3a) should the IETF take on L1VPNs?
>3b) if yes to 3a, should this be done in CCAMP?
>4) Waveband switching
>5) Control plane work
>6) Decoder ring for addresses
>7) Deployment considerations for GMPLS
>8) PCE requirements
>9) QoS control
>
>A rough idea of what each of the above entails follows.
>
>1) MPLS-GMPLS migration
>	implementation shift from "MPLS" objects to "GMPLS" objects
>	BCP on deployment migration for the same
>
>2) GMPLS interoperability issues
>	what addresses to use where
>	nits/clarifications of the specs
>	guidelines for path computation & constraints
>	survay
>
>3) L1VPN work items
>	identify protocol extensions needed
>	state what can already be done with what we have
>	do the actual protocol work for requirements that are not met
>	liaisons to SG13 as needed
>
>5) Control plane work
>	resiliency
>	graceful shutdown
>
>6) Decoder ring for addresses
>	for each address field, identify its nature and ITU equivalent
>	(may overlap with part of (2))
>
>
>4, 7-9 are obvious or have been elaborated on the mailing list.
>
>Kireeti.
>-------
>
>PS: The topic of GTTP has carefully been avoided.  More later.
>
>



Envelope-to: [e-mail]
Delivery-date: Wed, 24 Nov 2004 06:23:36 +0000
Date: Tue, 23 Nov 2004 22:22:19 -0800 (PST)
From: Kireeti Kompella <[e-mail]>
To: [e-mail]
Subject: New charter
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 15 Nov 2004, Kireeti Kompella wrote:

> If you have suggested charter updates, please send them to Adrian
> and me.

Thanks all for your input.  I have the following items; for each,
please say "Yes" (should be added to CCAMP charter), "No" (should not
be added) or "-" (don't care).  I'll remind you once again that not
all items will make it onto the new charter.

Please keep this subject line (simply reply to this mail).  The
deadline is Friday Dec 3, 17:00 PST.

1) MPLS-GMPLS migration
2) GMPLS interoperability issues
3a) should the IETF take on L1VPNs?
3b) if yes to 3a, should this be done in CCAMP?
4) Waveband switching
5) Control plane work
6) Decoder ring for addresses
7) Deployment considerations for GMPLS
8) PCE requirements
9) QoS control

A rough idea of what each of the above entails follows.

1) MPLS-GMPLS migration
	implementation shift from "MPLS" objects to "GMPLS" objects
	BCP on deployment migration for the same

2) GMPLS interoperability issues
	what addresses to use where
	nits/clarifications of the specs
	guidelines for path computation & constraints
	survay

3) L1VPN work items
	identify protocol extensions needed
	state what can already be done with what we have
	do the actual protocol work for requirements that are not met
	liaisons to SG13 as needed

5) Control plane work
	resiliency
	graceful shutdown

6) Decoder ring for addresses
	for each address field, identify its nature and ITU equivalent
	(may overlap with part of (2))


4, 7-9 are obvious or have been elaborated on the mailing list.

Kireeti.
-------

PS: The topic of GTTP has carefully been avoided.  More later.



Envelope-to: [e-mail]
Delivery-date: Wed, 24 Nov 2004 05:12:34 +0000
Thread-Topic: charter update
thread-index: AcTR5ACWta4mfw+0QE6IXI/OuEH3Gw==
Reply-To: <[e-mail]>
From: <[e-mail]>
To: "Kireeti Kompella" <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: 
Bcc: 
Subject: RE: charter update
Date: Wed, 24 Nov 2004 14:11:06 +0900
Comment: =?iso-8859-1?B?x9GxucD8wNrF673Fv6yxuL/4LCCxpMD8tN64wcGmvu7GwCwgtOO05w==?=
Message-ID: <5a0301c4d1e4$0098d060$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_5A04_01C4D22F.70807860"
Content-Class: urn:content-classes:message

This is a multi-part message in MIME format.

------=_NextPart_000_5A04_01C4D22F.70807860
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: base64


------=_NextPart_000_5A04_01C4D22F.70807860
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: base64

PERJViBpZD1tc2dib2R5IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0
ZW0iPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+SGkgS2lyZWV0aSw8L0RJVj4NCjxESVY+Jm5i
c3A7PC9ESVY+DQo8RElWPkkgYWxzbyB0aGluayB0aGF0IG9ubHkgdGhlIHRpdGxlIGNvdWxkIG5v
dCB1bmRlcnN0YW5kIHVzIHdlbGwuPC9ESVY+DQo8RElWPkkmbmJzcDt0aGluayB0aGF0IGlmIFRF
IGlzIGEgcGFydCBvZiBuZXR3b3JrIHZpZXctcG9pbnQsJm5ic3A7UW9TIGlzIGEgcGFydCBvZiBj
dXN0b21lciB2aWV3LXBvaW50LjwvRElWPg0KPERJVj5DdXN0b21lcnMgaGF2ZSBzZXZlcmFsIHJl
cXVpcmVtZW50cyBpbiBvcmRlciB0byB1c2UgSVAgc2VydmljZXMgc3VjaCBhcyBWb0lQLCBNTW9J
UCwgVlBOLCBhbmQgZXRjLiBUaG9zZSByZXF1aXJlbWVudHMgd291bGQgaW5jbHVkZSBhZG1pc3Np
b24gbGV2ZWwgb2YgbmV0d29yayByZXNvdXJjZXMgYW5kIHVzZXIgZ3JvdXAsIHBlcmZvcm1hbmNl
IGNoYXJhY3RlcmlzdGljZXMgc3VjaCBhcyBkZWxheSBhbmQgaml0dGVyLCBhbmQgcHJvdGVjdGlv
biBhbmQgcmVzdG9yYXRpb24gc28gb24uPC9ESVY+DQo8RElWPlNvIGZhciwgd2UgaGF2ZSB0YWxr
ZWQgYWJvdXQgcmVzcGVjdGl2ZSB0b3BpY3MgZnJvbSB0aGUgbmV0d29yayB2aWV3LXBvaW50LCBJ
IHRoaW5rIHRoZXJlIGlzIG5vIGludGVncmF0aW9uIGFwcHJvYWNoIGZvciB0aGUmbmJzcDtzdXBw
b3J0IG9mIFFvU3MgZnJvbSB0aGUgY3VzdG9tZXIgdmlldy1wb2ludC48L0RJVj4NCjxESVY+VGhl
IHRvcGljIG9mIFFvUyBjb250cm9sIGNvdWxkIGtlZXAgaW4gdG91Y2ggd2l0aCBQQ0UsIFRFV0cs
IHJvdXRpbmcgcmVsYXRlZCBXR3MsIGFuZCBzZXJ2aWNlIHJlbGF0ZWQgV0dzIHNvIG9uLiBQb3Nz
aWJsZSBwcm90b2NvbHMgc3VjaCBhcyBMTVAsIHNpZ25hbGluZyBhbmQgcm91dGluZyBwcm90b2Nv
bHMgd291bGQgYmUgZXhwYW5kZWQgYW5kIG5ldyBwcm90b2NvbHMgY291bGQgYmUgbmVlZGVkIGFj
Y29yZGluZyB0byB0aGUgbGV2ZWwgcmVxdWVzdGVkIGZyb20gY3VzdG9tbWVycyBhbmQgbmV0d29y
a3MuPC9ESVY+DQo8RElWPlByaW1hcmlseSwgSSB0aGluayB0aGUgaW50ZXJhY3Rpb24gYmV0d2Vl
biBhIGNlbnRyYWxpemVkIHByb3Zpc2lvbmluZyBzZXJ2ZXIgYW5kIG5ldHdvcmsgbm9kZXMgc2hv
dWxkIGJlIGNvbnNpZGVyZWQgZm9yIHRoZSBRb1MgY29udHJvbC48L0RJVj4NCjxESVY+Jm5ic3A7
PC9ESVY+DQo8RElWPlRoYW5rcyw8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPllvdW5n
LjwvRElWPg0KPERJVj48QlI+LS0tLS0/PyA/Pz8tLS0tLTxCUj48Qj4/PyA/Pzo8L0I+ICJLaXJl
ZXRpIEtvbXBlbGxhIiAmbHQ7a2lyZWV0aUBqdW5pcGVyLm5ldCZndDs8QlI+PEI+Pz8gPz86PC9C
PiAyMDA0LTExLTIzID8/IDEyOjM3OjUzPEJSPjxCPj8/ID8/OjwvQj4gPz8/ICZsdDt5aHdraW1A
ZXRyaS5yZS5rciZndDs8QlI+PEI+Pz86PC9CPiAiYWRyaWFuQG9sZGRvZy5jby51ayIgJmx0O2Fk
cmlhbkBvbGRkb2cuY28udWsmZ3Q7LCAiY2NhbXBAb3BzLmlldGYub3JnIiAmbHQ7Y2NhbXBAb3Bz
LmlldGYub3JnJmd0OzxCUj48Qj4/Pzo8L0I+IFJFOiBjaGFydGVyIHVwZGF0ZTxCUj48QlI+PC9E
SVY+DQo8RElWPjwhLS0gQ29udmVydGVkIGZyb20gdGV4dC9wbGFpbiBmb3JtYXQgLS0+PEJSPg0K
PFA+PEZPTlQgc2l6ZT0yPkhpIFlvdW5nLDxCUj48QlI+T24gRnJpLCAxOSBOb3YgMjAwNCwgW2tz
X2NfNTYwMS0xOTg3XSA/Pz8gd3JvdGU6PEJSPjxCUj4mZ3Q7IEluIGFkZGl0aW9uIHRvIHRob3Nl
IFphZmFyIHNhaWQsPEJSPi4uLjxCUj4mZ3Q7IC0gUW9TIENvbnRyb2wgZm9yIEdNUExTLCBpZiB3
ZSBmaW5kIHRoaXMgaXRlbSBvdXRzaWRlIHRoZSBjdXJyZW50PEJSPiZndDsgc2NvcGUuPEJSPjxC
Uj5Db3VsZCB5b3UgZWxhYm9yYXRlIG9uIHRoaXM/PEJSPjxCUj5UaGFua3MsPEJSPktpcmVldGku
PEJSPi0tLS0tLS08QlI+PC9GT05UPjwvUD48L0RJVj48L0RJVj4=

------=_NextPart_000_5A04_01C4D22F.70807860--



Envelope-to: [e-mail]
Delivery-date: Tue, 23 Nov 2004 21:51:12 +0000
Message-ID: <[e-mail]>
From: "Ong, Lyndon" <[e-mail]>
To: "'Brungard, Deborah A, ALABS'" <[e-mail]>, Adrian Farrel <[e-mail]>, [e-mail]
Subject: RE: Second incoming communication from the OIF
Date: Tue, 23 Nov 2004 16:54:57 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

Hi Deborah,

Just to clear up any potential misunderstanding:

There hasn't been any recent decision on the part of OIF to freeze
its work (as UNI 1.0 goes back to 2001, it's already pretty cold ;o)
The interworking proposal came up very recently, and it was understood that
IETF and ITU-T have no plans to document interworking at this time.

I'm reading into your email a concern with the use of "ASON" in the title
of the project.  The interworking project is likely to cover ITU-T 
G.7713.2 as the ASON signaling standard at the UNI and E-NNI, taking into
account experiences that members have had implementing and testing
protocols.  As you note, GMPLS is being extended to support ASON
as well.  It sounds reasonable to comment that some clarification of
the project definition may be helpful.

This also raises a good point about GMPLS continuing to evolve beyond
RFC 3473.  As the work on GMPLS extensions to support ASON functionality 
continues to develop, this will need to be taken into account.

Cheers,

Lyndon


-----Original Message-----
From: Brungard, Deborah A, ALABS [mailto:[e-mail]]
Sent: Monday, November 22, 2004 1:36 PM
To: Adrian Farrel; [e-mail]
Subject: RE: Second incoming communication from the OIF


Hi Adrian,

While this liaison may be considered "for information", it communicates
OIF's recognition and concern regarding the incompatibility problems of
G7713.2/UNI1.0 (SONET/SDH) with GMPLS, and regretfully (for operators
and vendors), it seems OIF is choosing to freeze it's work. While G8080
recognizes multiple protocols may exist, it does not encourage redundant
(same) protocol mechanisms for the same capability, and proliferation of
interworking functions. Here's a suggested response...
-----------------
It is regretful that you consider your SONET/SDH implementation
agreements frozen. Considering the (published) UNI1.0 statement: "since
the intent of OIF is to develop UNI protocols in close alignment with
the IETF work, any changes in GMPLS/LMP proposed standards that could be
incorporated in UNI signaling specifications will be included in future
versions", we had hoped to cooperatively work with you to minimize the
divergence between OIF IA on SONET/SDH and RFC3473 in the best interests
for the industry.

Noting your lack of a definition of "domain" at this time (re. your 2nd
liaison regarding OIF demo results), we question your interpretation
(below) of RFC3473 and the title "interworking of ASON-GMPLS network
domains". Per G8080, domains are based on functionality e.g. signaling,
routing. RFC3473 is a standard signaling interface for use between
different vendor equipment and different signaling domains (i.e. ENNI
and INNI). Recent work extended to UNI support. And as previously
communicated, CCAMP is progressing standards-track ASON-GMPLS (in
cooperation with ITU-T) in support of the full set of G8080 call
functionalities (i.e. independent call/connection setup and support of
multiple connections per call).

For your interworking design guidelines, we recommend for you to clarify
when referencing a non-standard signaling implementation or standard
RFC3473. As a basis for your work, we recommend use of our ASON-GMPLS
work to ensure proper interpretation of standard RFC3473's capabilities
in support of G8080. We can understand OIF operators' concerns on the
potential for mis-interpretation and the need for design guidelines
considering the multiplicity of protocols "based on RSVP". Hopefully, as
you progress this work, you will reconsider using UNI1.0 protocol
mechanisms based on standards-track modifications of RSVP. We look
forward to working with you on OIF UNI2.0 using CCAMP's standards track
work.
-----------

Regards,
Deborah



-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Adrian Farrel
Sent: Friday, November 19, 2004 2:09 PM
To: [e-mail]
Subject: Second incoming communication from the OIF

A second communication from Jim Jones, Chair of the OIF Technical
Committee, lands on my
e-doorstep.

This communication is helpfully in two files with different formats (one
PDF and one
PowerPoint). I have reproduced the text below.

Again, the real copy can be found at
http://www.olddog.co.uk/incoming.htm

Adrian

===

November 5, 2004
Mr. Adrian Farrel, [e-mail], IETF, CCAMP Working Group Chair
Mr. Kireeti Kompella, [e-mail], IETF, CCAMP Working Group
Chair
Re: New OIF Project on Interworking of ASON - GMPLS Network Domains

Dear Adrian and Kireeti,

I want to inform you of a new work project that was proposed and adopted
by the OIF
members at our 4Q Technical Committee meetings that took place October
26-28. The
project will result in a design guideline document to assist vendors and
carriers
in optical networks where signaling interworking is required between
OIF/ITU-T ASON
and GMPLS RSVP-TE.

As we have seen in interoperability trials and initial deployments,
vendor
implementations sometimes use different control plane protocols,
depending on the
NE requirements and function within a network. The OIF and ASON control
plane
requirements were written with the knowledge that a network composed of
multiple
domains could support a heterogeneous set of protocols. An NE that
exists at a
boundary between network domains may support a different protocol on
either side
of the boundary (for example OIF UNI on the client side and GMPLS I-NNI
on the
network side).

An interworking design guideline was cited as a high priority by OIF
member companies,
both carriers and vendors. It is also our understanding that an
interworking guide is
not currently within the work scope of either IETF CCAMP or ITU-T SG15.
An outline of
the project plan is provided in the document oif2004.442.01. Although
the proposal
illustrates an example network configuration (featuring GMPLS as INNI
protocol), this
is an example only and not meant to restrict interworking considerations
to this model.

In contrast to OIF Implementation Agreements (IAs), the design guideline
will define
optional interworking methods between existing optical control plane
protocols. This
will allow software stack vendors and system vendors to map information,
messages and
behaviors between different protocols while preserving the required
functionality on
each side of the interface.

We expect the OIF, ITU-T and IETF will continue to work together to
minimize or
eliminate differences between control plane signaling protocols. Given
that different
protocols currently exist to meet different requirements, an
interworking guide can
help ensure straightforward protocol interoperation. We welcome your
input on this
project and look forward to future collaboration.

Sincerely,
Jim Jones
OIF Technical Committee Chair
cc: [e-mail]

====
Slide1

Project proposal for interworking of G.8080 - RFC 3473 network domains

Contribution Number: oif2004.442.00
Working Group:  Architecture & Signaling
Title: Project proposal for interworking of G.8080 - RFC 3473 network
domains
Meeting: 4Q2004
Source:  Eve Varma Monica Lazer
Hans-Martin Foisel Satoru Okamoto
Jonathan Sadler Vishnu Shukla
Lyndon Ong Date: October 28, 2004
Abstract:  This contribution proposes to initiate a project with the
intention of
publishing a design guideline document for interworking between
OIF/ITU-T ASON control
plane interfaces (UNI, E-NNI) and IETF/GMPLS network domains.
Notice: This contribution has been created to assist the Optical
Internetworking Forum
(OIF).  This document is offered to the OIF solely as a basis for
discussion and is not a
binding proposal on the companies listed as resources above. Each
company in the source
list, and the OIF, reserves the rights to at any time to add, amend, or
withdraw
statements contained herein.
This Working Text represents work in progress by the OIF, and must not
be construed as an
official OIF Technical Report.  Nothing in this document is in any way
binding on the OIF
or any of its members.  The document is offered as a basis for
discussion and
communication, both within and without the OIF.
For additional information contact:
The Optical Internetworking Forum, 39355 California Street,
Suite 307, Fremont, CA 94538
510-608-5990 phone F [e-mail]
(c) 2001 Optical Internetworking Forum
===
Slide2

Contributors and Supporters
Alcatel, Jim Jones
AT&T - Monica Lazer
Avici - Amy Wang
Ciena - Lyndon Ong
Cisco - Richard Bradford
Deutsche Telekom - Hans-Martin Foisel
Lucent - Eve Varma
NTT - Satoru Okamoto
Tellabs - Jonathan Sadler
Verizon - Vishnu Shukla
.
===
Slide3

Network graph
===
Slide4

Project Start

Objective:
Generate an design guideline document for the interoperability of
OIF/ITU-T ASON and
IETF/GMPLS network domains

Scope
E-NNI, I-NNI(GMPLS) and UNI interoperability among these different
network architecture
approaches

Expected Output
Design guideline document (technical report) on this topic; not an
Implementation
Agreement

Interaction with other forums and standards bodies
Close cooperation with IETF/CCAMP and ITU-T,Q14/SG15
MTNM

Interaction with other OIF WG
Carrier, OAM&P, Interoperability

Why the OIF?
Interworking and interoperability among different standardization bodies
specifications
and standards approaches is a key goal of the Optical Internetworking
Forum
===
Slide5

Project Timeline

Project Start: This meeting (Oct 2004)
Liaison to ITU and IETF describing project scope and soliciting
interest: until next
meeting
Solicit and receive contributions for 2 quarterly meetings
Baseline draft 2nd Quarter 2005
Proposed editor: Hans-Martin Foisel
Straw ballot 3rd quarter 2005
Principal ballot 1st quarter 2006
===
Slide6

Motivation: Why Now?

Broad vendor and carrier support
- Strong request from the carrier and vendor members for interworking
among network
  domains, which may use IETF or OIF/ITU-T standards and specifications.
Current activities at IETF CCAMP design teams could benefit from this
document
This document will be based not only on available standards and
specifications but also on
first practical testing experiences
===
Slide7

References to Standards Contributions

RFC 3471, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling
Functional
Description"
RFC 3473, "Generalized Multi-Protocol Label Switching (GMPLS)Signaling
Resource
Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions".
RFC 3630, "Traffic Engineering (TE) Extensions to OSPF Version 2 ".
"Routing Extensions in Support of Generalized Multi-Protocol Label
Switching",
draft-ietf-ccamp-gmpls-routing-09.txt, work in progress..
OIF-UNI 1.0 Release 2, "OIF-UNI-01.0-R2-Common - User Network Interface
(UNI) 1.0
Signaling Specification, Release 2: Common Part" and
"OIF-UNI-01.0-R2-RSVP - RSVP
Extensions for User Network Interface (UNI) 1.0 Signaling, Release 2"
OIF E-NNI 1.0 Signaling, "OIF-E-NNI-Sig-01.0 - Intra-Carrier E-NNI
Signaling
 Specification"
===
Slide8

References to Standards Contributions

ITU-T G.8080/Y.1304, "Architecture for the Automatically Switched
Optical Network (ASON)"
ITU-T G.7713, "Distributed Call And Connection Management (DCM)".ITU-T
ITU-T G.7713.1, "Distributed Call and Connection Management (DCM) based
on PNNI".ITU-T
ITU-T G.7713.2, "Distributed Call and Connection Management: Signalling
mechanism using
GMPLS RSVP-TE".ITU-T
ITU-T G.7713.3, "Distributed Call and Connection Management: Signalling
mechanism using
GMPLS CR-LDP"
ITU-T G.7715, "Architecture and Requirements for Routing in the
Automatic Switched Optical
Networks".ITU-T
ITU-T G.7715.1, "ASON Routing Architecture and Requirements for Link
State Protocols"
===
Slide9

References to Standards Contributions

oif2004.435: Discussion points from routing solutions design team
oif2004.383: Project proposal for interworking to RFC 3473
oif2004.357: Interworking of OIF UNI/E-NNI with RFC 3473 GMPLS
oif2004.303: IETF draft with comparison of GMPLS and ASON signaling






Envelope-to: [e-mail]
Delivery-date: Mon, 22 Nov 2004 21:36:28 +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: Second incoming communication from the OIF
Date: Mon, 22 Nov 2004 15:35:35 -0600
Message-ID: <[e-mail]>
Thread-Topic: Second incoming communication from the OIF
Thread-Index: AcTOa2YM2iUW+Ss+Qmy1kEoLVfgHcgCVYP1Q
From: "Brungard, Deborah A, ALABS" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>

Hi Adrian,

While this liaison may be considered "for information", it communicates
OIF's recognition and concern regarding the incompatibility problems of
G7713.2/UNI1.0 (SONET/SDH) with GMPLS, and regretfully (for operators
and vendors), it seems OIF is choosing to freeze it's work. While G8080
recognizes multiple protocols may exist, it does not encourage redundant
(same) protocol mechanisms for the same capability, and proliferation of
interworking functions. Here's a suggested response...
-----------------
It is regretful that you consider your SONET/SDH implementation
agreements frozen. Considering the (published) UNI1.0 statement: "since
the intent of OIF is to develop UNI protocols in close alignment with
the IETF work, any changes in GMPLS/LMP proposed standards that could be
incorporated in UNI signaling specifications will be included in future
versions", we had hoped to cooperatively work with you to minimize the
divergence between OIF IA on SONET/SDH and RFC3473 in the best interests
for the industry.

Noting your lack of a definition of "domain" at this time (re. your 2nd
liaison regarding OIF demo results), we question your interpretation
(below) of RFC3473 and the title "interworking of ASON-GMPLS network
domains". Per G8080, domains are based on functionality e.g. signaling,
routing. RFC3473 is a standard signaling interface for use between
different vendor equipment and different signaling domains (i.e. ENNI
and INNI). Recent work extended to UNI support. And as previously
communicated, CCAMP is progressing standards-track ASON-GMPLS (in
cooperation with ITU-T) in support of the full set of G8080 call
functionalities (i.e. independent call/connection setup and support of
multiple connections per call).

For your interworking design guidelines, we recommend for you to clarify
when referencing a non-standard signaling implementation or standard
RFC3473. As a basis for your work, we recommend use of our ASON-GMPLS
work to ensure proper interpretation of standard RFC3473's capabilities
in support of G8080. We can understand OIF operators' concerns on the
potential for mis-interpretation and the need for design guidelines
considering the multiplicity of protocols "based on RSVP". Hopefully, as
you progress this work, you will reconsider using UNI1.0 protocol
mechanisms based on standards-track modifications of RSVP. We look
forward to working with you on OIF UNI2.0 using CCAMP's standards track
work.
-----------

Regards,
Deborah



-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Adrian Farrel
Sent: Friday, November 19, 2004 2:09 PM
To: [e-mail]
Subject: Second incoming communication from the OIF

A second communication from Jim Jones, Chair of the OIF Technical
Committee, lands on my
e-doorstep.

This communication is helpfully in two files with different formats (one
PDF and one
PowerPoint). I have reproduced the text below.

Again, the real copy can be found at
http://www.olddog.co.uk/incoming.htm

Adrian

=3D=3D=3D

November 5, 2004
Mr. Adrian Farrel, [e-mail], IETF, CCAMP Working Group Chair
Mr. Kireeti Kompella, [e-mail], IETF, CCAMP Working Group
Chair
Re: New OIF Project on Interworking of ASON - GMPLS Network Domains

Dear Adrian and Kireeti,

I want to inform you of a new work project that was proposed and adopted
by the OIF
members at our 4Q Technical Committee meetings that took place October
26-28. The
project will result in a design guideline document to assist vendors and
carriers
in optical networks where signaling interworking is required between
OIF/ITU-T ASON
and GMPLS RSVP-TE.

As we have seen in interoperability trials and initial deployments,
vendor
implementations sometimes use different control plane protocols,
depending on the
NE requirements and function within a network. The OIF and ASON control
plane
requirements were written with the knowledge that a network composed of
multiple
domains could support a heterogeneous set of protocols. An NE that
exists at a
boundary between network domains may support a different protocol on
either side
of the boundary (for example OIF UNI on the client side and GMPLS I-NNI
on the
network side).

An interworking design guideline was cited as a high priority by OIF
member companies,
both carriers and vendors. It is also our understanding that an
interworking guide is
not currently within the work scope of either IETF CCAMP or ITU-T SG15.
An outline of
the project plan is provided in the document oif2004.442.01. Although
the proposal
illustrates an example network configuration (featuring GMPLS as INNI
protocol), this
is an example only and not meant to restrict interworking considerations
to this model.

In contrast to OIF Implementation Agreements (IAs), the design guideline
will define
optional interworking methods between existing optical control plane
protocols. This
will allow software stack vendors and system vendors to map information,
messages and
behaviors between different protocols while preserving the required
functionality on
each side of the interface.

We expect the OIF, ITU-T and IETF will continue to work together to
minimize or
eliminate differences between control plane signaling protocols. Given
that different
protocols currently exist to meet different requirements, an
interworking guide can
help ensure straightforward protocol interoperation. We welcome your
input on this
project and look forward to future collaboration.

Sincerely,
Jim Jones
OIF Technical Committee Chair
cc: [e-mail]

=3D=3D=3D=3D
Slide1

Project proposal for interworking of G.8080 - RFC 3473 network domains

Contribution Number: oif2004.442.00
Working Group:  Architecture & Signaling
Title: Project proposal for interworking of G.8080 - RFC 3473 network
domains
Meeting: 4Q2004
Source:  Eve Varma Monica Lazer
Hans-Martin Foisel Satoru Okamoto
Jonathan Sadler Vishnu Shukla
Lyndon Ong Date: October 28, 2004
Abstract:  This contribution proposes to initiate a project with the
intention of
publishing a design guideline document for interworking between
OIF/ITU-T ASON control
plane interfaces (UNI, E-NNI) and IETF/GMPLS network domains.
Notice: This contribution has been created to assist the Optical
Internetworking Forum
(OIF).  This document is offered to the OIF solely as a basis for
discussion and is not a
binding proposal on the companies listed as resources above. Each
company in the source
list, and the OIF, reserves the rights to at any time to add, amend, or
withdraw
statements contained herein.
This Working Text represents work in progress by the OIF, and must not
be construed as an
official OIF Technical Report.  Nothing in this document is in any way
binding on the OIF
or any of its members.  The document is offered as a basis for
discussion and
communication, both within and without the OIF.
For additional information contact:
The Optical Internetworking Forum, 39355 California Street,
Suite 307, Fremont, CA 94538
510-608-5990 phone F [e-mail]
(c) 2001 Optical Internetworking Forum
=3D=3D=3D
Slide2

Contributors and Supporters
Alcatel, Jim Jones
AT&T - Monica Lazer
Avici - Amy Wang
Ciena - Lyndon Ong
Cisco - Richard Bradford
Deutsche Telekom - Hans-Martin Foisel
Lucent - Eve Varma
NTT - Satoru Okamoto
Tellabs - Jonathan Sadler
Verizon - Vishnu Shukla
.
=3D=3D=3D
Slide3

Network graph
=3D=3D=3D
Slide4

Project Start

Objective:
Generate an design guideline document for the interoperability of
OIF/ITU-T ASON and
IETF/GMPLS network domains

Scope
E-NNI, I-NNI(GMPLS) and UNI interoperability among these different
network architecture
approaches

Expected Output
Design guideline document (technical report) on this topic; not an
Implementation
Agreement

Interaction with other forums and standards bodies
Close cooperation with IETF/CCAMP and ITU-T,Q14/SG15
MTNM

Interaction with other OIF WG
Carrier, OAM&P, Interoperability

Why the OIF?
Interworking and interoperability among different standardization bodies
specifications
and standards approaches is a key goal of the Optical Internetworking
Forum
=3D=3D=3D
Slide5

Project Timeline

Project Start: This meeting (Oct 2004)
Liaison to ITU and IETF describing project scope and soliciting
interest: until next
meeting
Solicit and receive contributions for 2 quarterly meetings
Baseline draft 2nd Quarter 2005
Proposed editor: Hans-Martin Foisel
Straw ballot 3rd quarter 2005
Principal ballot 1st quarter 2006
=3D=3D=3D
Slide6

Motivation: Why Now?

Broad vendor and carrier support
- Strong request from the carrier and vendor members for interworking
among network
  domains, which may use IETF or OIF/ITU-T standards and specifications.
Current activities at IETF CCAMP design teams could benefit from this
document
This document will be based not only on available standards and
specifications but also on
first practical testing experiences
=3D=3D=3D
Slide7

References to Standards Contributions

RFC 3471, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling
Functional
Description"
RFC 3473, "Generalized Multi-Protocol Label Switching (GMPLS)Signaling
Resource
Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions".
RFC 3630, "Traffic Engineering (TE) Extensions to OSPF Version 2 ".
"Routing Extensions in Support of Generalized Multi-Protocol Label
Switching",
draft-ietf-ccamp-gmpls-routing-09.txt, work in progress..
OIF-UNI 1.0 Release 2, "OIF-UNI-01.0-R2-Common - User Network Interface
(UNI) 1.0
Signaling Specification, Release 2: Common Part" and
"OIF-UNI-01.0-R2-RSVP - RSVP
Extensions for User Network Interface (UNI) 1.0 Signaling, Release 2"
OIF E-NNI 1.0 Signaling, "OIF-E-NNI-Sig-01.0 - Intra-Carrier E-NNI
Signaling
 Specification"
=3D=3D=3D
Slide8

References to Standards Contributions

ITU-T G.8080/Y.1304, "Architecture for the Automatically Switched
Optical Network (ASON)"
ITU-T G.7713, "Distributed Call And Connection Management (DCM)".ITU-T
ITU-T G.7713.1, "Distributed Call and Connection Management (DCM) based
on PNNI".ITU-T
ITU-T G.7713.2, "Distributed Call and Connection Management: Signalling
mechanism using
GMPLS RSVP-TE".ITU-T
ITU-T G.7713.3, "Distributed Call and Connection Management: Signalling
mechanism using
GMPLS CR-LDP"
ITU-T G.7715, "Architecture and Requirements for Routing in the
Automatic Switched Optical
Networks".ITU-T
ITU-T G.7715.1, "ASON Routing Architecture and Requirements for Link
State Protocols"
=3D=3D=3D
Slide9

References to Standards Contributions

oif2004.435: Discussion points from routing solutions design team
oif2004.383: Project proposal for interworking to RFC 3473
oif2004.357: Interworking of OIF UNI/E-NNI with RFC 3473 GMPLS
oif2004.303: IETF draft with comparison of GMPLS and ASON signaling






Envelope-to: [e-mail]
Delivery-date: Mon, 22 Nov 2004 21:35:34 +0000
Message-Id: <[e-mail]>
Date: Fri, 19 Nov 2004 10:30:49 +0900
To: Kireeti Kompella <[e-mail]>, [e-mail]
From: Tomonori TAKEDA <[e-mail]>
Subject: Re: charter update
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

- L1VPNs:
     Define control and measurement plane mechanisms to support L1VPNs.
     Analize applicability of these mechanisms.

As we discussed in CCAMP WG, the work would be expected to be around the 
use and application of GMPLS protocols to support L1VPN services. (Note: 
services does not necessary mean to external customers, can be applicable 
to internal usage as well.) There may be minor protocol extensions needed 
for this.

- Implementation/Interoprability experience


Best regards,

At 07:51 04/11/15 -0800, Kireeti Kompella wrote:
>Hi All,
>
>If you have suggested charter updates, please send them to Adrian and
>me.  Please keep this subject line (simply reply to this mail).
>
>The deadline is Friday Nov 19, 17:00 PST.
>
>Thanks,
>Kireeti.
>-------

-----
Tomonori TAKEDA
NTT Network Service Systems Lab.
Phone: [phone]




Envelope-to: [e-mail]
Delivery-date: Mon, 22 Nov 2004 19:41:33 +0000
Message-Id: <[e-mail]>
To: "Adrian Farrel" <[e-mail]>
cc: [e-mail], [e-mail], "Kireeti Kompella" <[e-mail]>, [e-mail]
Subject: [mpls] New version of Bundling Draft
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 22 Nov 2004 11:38:50 -0800
From: Yakov Rekhter <[e-mail]>

Adrian,

> Thank you for the new version of this draft. I assume that the
> changes are to address the issues raised at the MPLS WG meeting in
> Washington.
> 
> Since the draft was already through WG and IETF last call, I wonder
> if you would be kind enough to summarize the issues you were
> addressing and what changes you made to the draft.

Here is the summary:

draft-ietf-mpls-bundle-05.txt has been updated to reflect the comments made
in the MPLS WG and on the list.  The issues raised are:

1. Scope of component identifiers is open to interpretation (i.e., node vs
link)
2. No way to specify different upstream and downstream components then
using TLV types 1, 2 and 3
3. Ambiguity of contents of the IP address field in TLV types 3, 4, 5
4. Lack of IPv6 support for types 3, 4, and 5.
5. Ambiguity of when to use types 4 and 5 and when to use type 3.
6. No coverage of ERO and RRO implications

These issues have been addressed in the following ways:

Issue 1:  The -05 document states that all component link TLV types
          have Node/IP scope
Issue 2: -05 Tightly defines support for different components in each
          direction (for bidirectional LSPs, and for all TLV types)
Issue 3: Format of the Value field for types 3, 4 and 5 now has the
          identical format as the contents of the C-Type 1
          LSP_TUNNEL_INTERFACE_ID object defined in [RFC3477].
Issue 4: Based on the previous change, support of IPv6 unnumbered
          components is now tied to, and the same as, the support of 
          IPv6 unnumber TE links.
Issue 5: -05 allows, but recommend against use of types 4 and 5
Issue 6: EROs, RROs remain out of scope of bundling document

Current planned changes are:
- Fix nits found by Adrian and Loa
- Insert a Table of Contents
- Section numbering will remain unchanged so as not to break any
potentially existing references to the draft

Yakov.



Envelope-to: [e-mail]
Delivery-date: Mon, 22 Nov 2004 15:39:49 +0000
Date: Mon, 22 Nov 2004 07:37:53 -0800 (PST)
From: Kireeti Kompella <[e-mail]>
To: =?ks_c_5601-1987?B?sei/tcit?= <[e-mail]>
cc: [e-mail], [e-mail]
Subject: RE: charter update
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN
Content-Transfer-Encoding: QUOTED-PRINTABLE

Hi Young,

On Fri, 19 Nov 2004, [ks_c_5601-1987] =B1=E8=BF=B5=C8=AD wrote:

> In addition to those Zafar said,
=2E..
> - QoS Control for GMPLS, if we find this item outside the current
> scope.

Could you elaborate on this?

Thanks,
Kireeti.
-------



Envelope-to: [e-mail]
Delivery-date: Mon, 22 Nov 2004 14:59:34 +0000
Message-Id: <6.1.2.0.2.20041122095526.04564c00@mo-ex1>
Date: Mon, 22 Nov 2004 09:55:52 -0500
To: "Adrian Farrel" <[e-mail]>
From: Lou Berger <[e-mail]>
Subject: Re: New version of Bundling Draft
Cc: "Berger, Lou" <[e-mail]>, "Yakov Rekhter" <[e-mail]>, "Kireeti Kompella" <[e-mail]>, <[e-mail]>, <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Adrian,
         Loa has asked for the same thing.  We should have it out this week.
Lou

At 10:44 AM 11/20/2004, Adrian Farrel wrote:

>Hi,
>
>Thank you for the new version of this draft. I assume that the changes are 
>to address the
>issues raised at the MPLS WG meeting in Washington.
>
>Since the draft was already through WG and IETF last call, I wonder if you 
>would be kind
>enough to summarize the issues you were addressing and what changes you 
>made to the draft.
>
>Thanks,
>Adrian




Envelope-to: [e-mail]
Delivery-date: Sat, 20 Nov 2004 18:08:55 +0000
Message-ID: <073301c4cf2b$eb625550$749c9ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Registry of bits in the Admin_Status object
Date: Sat, 20 Nov 2004 18:08:09 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

All,

I have created a temporary registry of bits in the Admin_Status object to track these
until they get under the care of IANA. Hopefully this will avoid drafts competing for the
bits.

Please let me know when you are pursuing the use of a new bit. Priority will be given to
drafts that choose bit names in such a way as to spell interesting words :-)

Look at http://www.olddog.co.uk/admin-status.txt

Cheers,
Adrian




Envelope-to: [e-mail]
Delivery-date: Sat, 20 Nov 2004 17:20:34 +0000
Message-ID: <072401c4cf24$f2b161e0$749c9ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>, "Yakov Rekhter" <[e-mail]>, "'Kireeti Kompella'" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: New version of Bundling Draft
Date: Sat, 20 Nov 2004 15:44:03 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

Thank you for the new version of this draft. I assume that the changes are to address the
issues raised at the MPLS WG meeting in Washington.

Since the draft was already through WG and IETF last call, I wonder if you would be kind
enough to summarize the issues you were addressing and what changes you made to the draft.

Thanks,
Adrian

PS.
A few nits.

"Status of this Memo" and "Abstract" should not be numbered.
"Specification of Requirements" is not now usually numbered.

Abstract must not contain citations except through full naming.

Notwithstanding RFC3471 section 4, I think you would be wise to enhance your use of
"downstream data channel" etc. with some text like "i.e., from initiator to terminator"

Section 4.2
   Once a bundled link is determined to be alive, it can
be advertised
--->formatting

Section 4.3
   Although SHOULD NOT be used, when used, the type 5 TLV MUST NOT be
"Although it SHOULD NOT"
   the first TLV in an IF_ID RSVP_HOP object or IF_ID TLV.

Section 5.9
   The Resource Classes for a bundled link are the same as those of the
   component link
s.
---> formatting

Section 8.1
   [GMPLS-ISIS] Kompella, K., Rekhter, Y., Banerjee, A. et al, "IS-IS
   Extensions in Support of Generalized MPLS", draft-ietf-ibis-gmpls-
   extensions-11.txt (work in progress)
"ibis"?





Envelope-to: [e-mail]
Delivery-date: Sat, 20 Nov 2004 14:37:27 +0000
Message-ID: <070501c4cf0e$46b511e0$749c9ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Incoming communication from the OIF
Date: Sat, 20 Nov 2004 14:32:55 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

You're right Dimitri,

There are only a couple of small points to respond to.
I'd welcome suggestions of text.

> 1. issue of loss of RSVP signaling adjacency to trigger procedure of
> draft-ietf-ccamp-ospf-gmpls-extensions

My view is that no change to the base spec is needed or appropriate, but we'd be happy to
see ann Applicability I-D if someone want to write one.

> 2. and the reachability advertisement

I admit to being confused by the prospect of summarising TNAs.

Adrian




Envelope-to: [e-mail]
Delivery-date: Fri, 19 Nov 2004 23:37:46 +0000
Message-ID: <[e-mail]>
Date: Sat, 20 Nov 2004 00:36:17 +0100
From: dimitri papadimitriou <[e-mail]>
Reply-To:  [e-mail],  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910
MIME-Version: 1.0
To: "Brungard, Deborah A, ALABS" <[e-mail]>
CC:  [e-mail],  Adrian Farrel <[e-mail]>, [e-mail]
Subject: Re: Incoming communication from the OIF
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

hi deborah,

Brungard, Deborah A, ALABS wrote:
> Hi Adrian,
> 
> On the second last item, even though "informational", it is very
> encouraging to hear that OIF has chosen to base it's UNI 2.0 IA on
> CCAMP's existing solution work. We should respond noting that we welcome
> the opportunity to collaborate with them and provide the updated status
> regarding GMPLS-UNI (which includes support of Ethernet and G709),
> GMPLS-G709, GMPLS-ASON, etc.

you mean bringing them the following documents:
<http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-overlay-05.txt>
<http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-g709-08.txt>
<http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-ason-02.txt>

could be also good to provide them with the details of RFC 3946 since it 
covers sub STS-1 signal types (hint: why only SONET is mentioned in the 
OIF liaison ?) and Ethernet (note: for the latter, i don't know if this 
is possible)

> Regards,
> Deborah
> 
> 
>>however planned UNI 2.0 features include
>>support of additional services including G.709, sub-STS-1 signal types
> 
> and Ethernet
> 
>>interfaces (using the same solutions from existing CCAMP documents).
> 
> 
> 
> .
> 



Envelope-to: [e-mail]
Delivery-date: Fri, 19 Nov 2004 23:05:51 +0000
Message-ID: <[e-mail]>
From: Payam Torab <[e-mail]>
To: 'Kireeti Kompella' <[e-mail]>, [e-mail],  [e-mail]
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: charter update
Date: Fri, 19 Nov 2004 18:00:35 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4CE8B.943E2736"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C4CE8B.943E2736
Content-Type: text/plain;
	charset="iso-8859-1"

Kireeti, Adrian -

We support waveband switching as described in
draft-douville-ccamp-gmpls-waveband-extensions-05.txt, and would like to see
waveband switching explicitly added to the charter, if not in the charter at
this time.

We believe this work plugs a hole in the GMPLS architecture- in particular
the need to recognize waveband switch capable (WBSC) interfaces. We indeed
have interfaces that are WBSC and not LSC or FSC.

Regards,

Payam Torab
Lambda OpticalSystems Corp.


 -----Original Message-----
From: 	[e-mail] [mailto:[e-mail]]  On
Behalf Of Kireeti Kompella
Sent:	Monday, November 15, 2004 10:51 AM
To:	[e-mail]
Subject:	charter update

Hi All,

If you have suggested charter updates, please send them to Adrian and
me.  Please keep this subject line (simply reply to this mail).

The deadline is Friday Nov 19, 17:00 PST.

Thanks,
Kireeti.
-------

------_=_NextPart_001_01C4CE8B.943E2736
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

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

<P><FONT SIZE=3D2>Kireeti, Adrian -</FONT>
</P>

<P><FONT SIZE=3D2>We support waveband switching as described in =
draft-douville-ccamp-gmpls-waveband-extensions-05.txt, and would like =
to see waveband switching explicitly added to the charter, if not in =
the charter at this time.</FONT></P>

<P><FONT SIZE=3D2>We believe this work plugs a hole in the GMPLS =
architecture- in particular the need to recognize waveband switch =
capable (WBSC) interfaces. We indeed have interfaces that are WBSC and =
not LSC or FSC.</FONT></P>

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

<P><FONT SIZE=3D2>Payam Torab</FONT>
<BR><FONT SIZE=3D2>Lambda OpticalSystems Corp.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&nbsp;-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: &nbsp; [e-mail] [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]=
</A>]&nbsp; On Behalf Of Kireeti Kompella</FONT>
<BR><FONT SIZE=3D2>Sent:&nbsp;&nbsp; Monday, November 15, 2004 10:51 =
AM</FONT>
<BR><FONT SIZE=3D2>To:&nbsp;&nbsp;&nbsp;&nbsp; =
[e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
charter update</FONT>
</P>

<P><FONT SIZE=3D2>Hi All,</FONT>
</P>

<P><FONT SIZE=3D2>If you have suggested charter updates, please send =
them to Adrian and</FONT>
<BR><FONT SIZE=3D2>me.&nbsp; Please keep this subject line (simply =
reply to this mail).</FONT>
</P>

<P><FONT SIZE=3D2>The deadline is Friday Nov 19, 17:00 PST.</FONT>
</P>

<P><FONT SIZE=3D2>Thanks,</FONT>
<BR><FONT SIZE=3D2>Kireeti.</FONT>
<BR><FONT SIZE=3D2>-------</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C4CE8B.943E2736--



Envelope-to: [e-mail]
Delivery-date: Fri, 19 Nov 2004 22:18:23 +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: Incoming communication from the OIF
Date: Fri, 19 Nov 2004 16:15:58 -0600
Message-ID: <[e-mail]>
Thread-Topic: Incoming communication from the OIF
Thread-Index: AcTOa4rCQjI9lNgKQ7qjFVSrQF720QAElvHg
From: "Brungard, Deborah A, ALABS" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, "Adrian Farrel" <[e-mail]>
Cc: <[e-mail]>

Hi Adrian,

On the second last item, even though "informational", it is very
encouraging to hear that OIF has chosen to base it's UNI 2.0 IA on
CCAMP's existing solution work. We should respond noting that we welcome
the opportunity to collaborate with them and provide the updated status
regarding GMPLS-UNI (which includes support of Ethernet and G709),
GMPLS-G709, GMPLS-ASON, etc.

Regards,
Deborah

> however planned UNI 2.0 features include
> support of additional services including G.709, sub-STS-1 signal types
and Ethernet
> interfaces (using the same solutions from existing CCAMP documents).



Envelope-to: [e-mail]
Delivery-date: Fri, 19 Nov 2004 19:10:49 +0000
Message-ID: <[e-mail]>
Date: Fri, 19 Nov 2004 20:10:05 +0100
From: dimitri papadimitriou <[e-mail]>
Reply-To:  [e-mail],  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910
MIME-Version: 1.0
To: Adrian Farrel <[e-mail]>
CC:  [e-mail]
Subject: Re: Incoming communication from the OIF
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

hi adrian - thanks for fwd'íng - reading here between the lines i guess 
there are two points to be addressed (others be "informational")

1. issue of loss of RSVP signaling adjacency to trigger procedure of 
draft-ietf-ccamp-ospf-gmpls-extensions

2. and the reachability advertisement

thanks,
- dimitri.

Adrian Farrel wrote:

> We have received the following communication from Jim Jones, chair of the Technical
> Committee of the OIF.
> 
> You can see the original version at http://www.olddog.co.uk/incoming.htm
> 
> Cheers,
> Adrian
> 
> ========
> 
> November 5, 2004
> Mr. Adrian Farrel, [e-mail], IETF, CCAMP Working Group Chair
> Mr. Kireeti Kompella, [e-mail], IETF, CCAMP Working Group Chair
> Re: IETF Response to Results from OIF World Interoperability Demo
> 
> Dear Adrian and Kireeti,
> Thank you for your responses to our liaison regarding our Supercomm Interoperability
> Demo. We appreciate the time and effort that was spent reviewing our liaison and your
> detailed reply, and hope for continued cooperation between our groups.
> 
> In response to your questions, we have the following information:
> - Regarding compliance with ASON: there are no compliance "tests" for ASON,
> however OIF has established a close liaison relationship with ITU-T over the past few
> years and has aligned its specifications closely with the ITU-T ASON specifications,
> especially G.8080, G.7713 and G.7713.1/2/3. We worked with ITU-T leading up to the
> Demo to make sure that our activities were considered supportive of ASON and
> welcomed by ITU-T.
> - Regarding the use of the term "domain": we have been following ITU-T G.8080 in the
> use of the term "domain". We are aware that an amendment to G.8080 is in progress in
> ITU-T. We are following work on refinements to the definition of "domain" in G.8080
> and expect that this work will also be liaised to IETF when complete.
> - Regarding the issue of loss of RSVP signaling adjacency: we thank IETF for the
> suggestion to utilize the procedures in draft-ietf-ccamp-ospf-gmpls-extensions for
> this case, which would result in the associated link being made unavailable for new
> connection requests. However, we note that the trigger identified in that draft is the
> restart of an OSPF instance, which is an independent event from loss of RSVP signaling
> adjacency due to DCN failure. Consequently we request that IETF consider the addition
> of loss of RSVP signaling adjacency as a trigger for the procedures identified in
> draft-ietf-ccamp-ospf-gmpls-extensions.
> - Regarding reachability advertisement: we also thank IETF for the suggestion to use
> the reachability advertisement document referenced in the liaison response, and would
> request also that each address entry be supplemented to include a mask length, as the
> reachable endpoints addresses may be summarizable. Including a mask would also
> allow for address packing as shown for the Extended IP Reachability TLV in RFC 3784.
> - Regarding the scope of OIF work, the existing Implementation Agreements for the
> UNI and E-NNI are SONET/SDH oriented, however planned UNI 2.0 features include
> support of additional services including G.709, sub-STS-1 signal types and Ethernet
> interfaces (using the same solutions from existing CCAMP documents). We understand
> that the ASON architecture itself is applicable to any layer network, existing and
> future, and are phasing our work based on input from our carrier members on
> capabilities that are of greatest importance to them.
> - As a clarification, all Implementation Agreements represent fully ratified
> documents, and are published on the OIF website after being voted on and approved by
> the OIF membership. Current Implementation Agreements include the UNI 1.0R2 and the
> Intra-Carrier E-NNI Signaling 1.0 specifications, available for open public access at
> http://oiforum.com/public/impagreements.html.
> 
> Sincerely,
> Jim Jones
> OIF Technical Committee Chair
> cc: [e-mail]
> 
> 
> 
> .
> 



Envelope-to: [e-mail]
Delivery-date: Fri, 19 Nov 2004 19:09:14 +0000
Message-ID: <06ca01c4ce6b$3a4305f0$749c9ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Second incoming communication from the OIF
Date: Fri, 19 Nov 2004 19:08:47 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit

A second communication from Jim Jones, Chair of the OIF Technical Committee, lands on my
e-doorstep.

This communication is helpfully in two files with different formats (one PDF and one
PowerPoint). I have reproduced the text below.

Again, the real copy can be found at http://www.olddog.co.uk/incoming.htm

Adrian

===

November 5, 2004
Mr. Adrian Farrel, [e-mail], IETF, CCAMP Working Group Chair
Mr. Kireeti Kompella, [e-mail], IETF, CCAMP Working Group Chair
Re: New OIF Project on Interworking of ASON - GMPLS Network Domains

Dear Adrian and Kireeti,

I want to inform you of a new work project that was proposed and adopted by the OIF
members at our 4Q Technical Committee meetings that took place October 26-28. The
project will result in a design guideline document to assist vendors and carriers
in optical networks where signaling interworking is required between OIF/ITU-T ASON
and GMPLS RSVP-TE.

As we have seen in interoperability trials and initial deployments, vendor
implementations sometimes use different control plane protocols, depending on the
NE requirements and function within a network. The OIF and ASON control plane
requirements were written with the knowledge that a network composed of multiple
domains could support a heterogeneous set of protocols. An NE that exists at a
boundary between network domains may support a different protocol on either side
of the boundary (for example OIF UNI on the client side and GMPLS I-NNI on the
network side).

An interworking design guideline was cited as a high priority by OIF member companies,
both carriers and vendors. It is also our understanding that an interworking guide is
not currently within the work scope of either IETF CCAMP or ITU-T SG15. An outline of
the project plan is provided in the document oif2004.442.01. Although the proposal
illustrates an example network configuration (featuring GMPLS as INNI protocol), this
is an example only and not meant to restrict interworking considerations to this model.

In contrast to OIF Implementation Agreements (IAs), the design guideline will define
optional interworking methods between existing optical control plane protocols. This
will allow software stack vendors and system vendors to map information, messages and
behaviors between different protocols while preserving the required functionality on
each side of the interface.

We expect the OIF, ITU-T and IETF will continue to work together to minimize or
eliminate differences between control plane signaling protocols. Given that different
protocols currently exist to meet different requirements, an interworking guide can
help ensure straightforward protocol interoperation. We welcome your input on this
project and look forward to future collaboration.

Sincerely,
Jim Jones
OIF Technical Committee Chair
cc: [e-mail]

====
Slide1

Project proposal for interworking of G.8080 - RFC 3473 network domains

Contribution Number: oif2004.442.00
Working Group:  Architecture & Signaling
Title: Project proposal for interworking of G.8080 - RFC 3473 network domains
Meeting: 4Q2004
Source:  Eve Varma Monica Lazer
Hans-Martin Foisel Satoru Okamoto
Jonathan Sadler Vishnu Shukla
Lyndon Ong Date: October 28, 2004
Abstract:  This contribution proposes to initiate a project with the intention of
publishing a design guideline document for interworking between OIF/ITU-T ASON control
plane interfaces (UNI, E-NNI) and IETF/GMPLS network domains.
Notice: This contribution has been created to assist the Optical Internetworking Forum
(OIF).  This document is offered to the OIF solely as a basis for discussion and is not a
binding proposal on the companies listed as resources above. Each company in the source
list, and the OIF, reserves the rights to at any time to add, amend, or withdraw
statements contained herein.
This Working Text represents work in progress by the OIF, and must not be construed as an
official OIF Technical Report.  Nothing in this document is in any way binding on the OIF
or any of its members.  The document is offered as a basis for discussion and
communication, both within and without the OIF.
For additional information contact:
The Optical Internetworking Forum, 39355 California Street,
Suite 307, Fremont, CA 94538
510-608-5990 phone F [e-mail]
© 2001 Optical Internetworking Forum
===
Slide2

Contributors and Supporters
Alcatel, Jim Jones
AT&T - Monica Lazer
Avici - Amy Wang
Ciena - Lyndon Ong
Cisco - Richard Bradford
Deutsche Telekom - Hans-Martin Foisel
Lucent - Eve Varma
NTT - Satoru Okamoto
Tellabs - Jonathan Sadler
Verizon - Vishnu Shukla
.
===
Slide3

Network graph
===
Slide4

Project Start

Objective:
Generate an design guideline document for the interoperability of OIF/ITU-T ASON and
IETF/GMPLS network domains

Scope
E-NNI, I-NNI(GMPLS) and UNI interoperability among these different network architecture
approaches

Expected Output
Design guideline document (technical report) on this topic; not an Implementation
Agreement

Interaction with other forums and standards bodies
Close cooperation with IETF/CCAMP and ITU-T,Q14/SG15
MTNM

Interaction with other OIF WG
Carrier, OAM&P, Interoperability

Why the OIF?
Interworking and interoperability among different standardization bodies specifications
and standards approaches is a key goal of the Optical Internetworking Forum
===
Slide5

Project Timeline

Project Start: This meeting (Oct 2004)
Liaison to ITU and IETF describing project scope and soliciting interest: until next
meeting
Solicit and receive contributions for 2 quarterly meetings
Baseline draft 2nd Quarter 2005
Proposed editor: Hans-Martin Foisel
Straw ballot 3rd quarter 2005
Principal ballot 1st quarter 2006
===
Slide6

Motivation: Why Now?

Broad vendor and carrier support
- Strong request from the carrier and vendor members for interworking among network
  domains, which may use IETF or OIF/ITU-T standards and specifications.
Current activities at IETF CCAMP design teams could benefit from this document
This document will be based not only on available standards and specifications but also on
first practical testing experiences
===
Slide7

References to Standards Contributions

RFC 3471, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional
Description"
RFC 3473, "Generalized Multi-Protocol Label Switching (GMPLS)Signaling Resource
Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions".
RFC 3630, "Traffic Engineering (TE) Extensions to OSPF Version 2 ".
"Routing Extensions in Support of Generalized Multi-Protocol Label Switching",
draft-ietf-ccamp-gmpls-routing-09.txt, work in progress..
OIF-UNI 1.0 Release 2, "OIF-UNI-01.0-R2-Common - User Network Interface (UNI) 1.0
Signaling Specification, Release 2: Common Part" and "OIF-UNI-01.0-R2-RSVP - RSVP
Extensions for User Network Interface (UNI) 1.0 Signaling, Release 2"
OIF E-NNI 1.0 Signaling, "OIF-E-NNI-Sig-01.0 - Intra-Carrier E-NNI Signaling
 Specification"
===
Slide8

References to Standards Contributions

ITU-T G.8080/Y.1304, "Architecture for the Automatically Switched Optical Network (ASON)"
ITU-T G.7713, "Distributed Call And Connection Management (DCM)".ITU-T
ITU-T G.7713.1, "Distributed Call and Connection Management (DCM) based on PNNI".ITU-T
ITU-T G.7713.2, "Distributed Call and Connection Management: Signalling mechanism using
GMPLS RSVP-TE".ITU-T
ITU-T G.7713.3, "Distributed Call and Connection Management: Signalling mechanism using
GMPLS CR-LDP"
ITU-T G.7715, "Architecture and Requirements for Routing in the Automatic Switched Optical
Networks".ITU-T
ITU-T G.7715.1, "ASON Routing Architecture and Requirements for Link State Protocols"
===
Slide9

References to Standards Contributions

oif2004.435: Discussion points from routing solutions design team
oif2004.383: Project proposal for interworking to RFC 3473
oif2004.357: Interworking of OIF UNI/E-NNI with RFC 3473 GMPLS
oif2004.303: IETF draft with comparison of GMPLS and ASON signaling




Envelope-to: [e-mail]
Delivery-date: Fri, 19 Nov 2004 18:58:35 +0000
Message-ID: <06c901c4ce69$95d811f0$749c9ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Incoming communication from the OIF
Date: Fri, 19 Nov 2004 18:57:00 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

We have received the following communication from Jim Jones, chair of the Technical
Committee of the OIF.

You can see the original version at http://www.olddog.co.uk/incoming.htm

Cheers,
Adrian

========

November 5, 2004
Mr. Adrian Farrel, [e-mail], IETF, CCAMP Working Group Chair
Mr. Kireeti Kompella, [e-mail], IETF, CCAMP Working Group Chair
Re: IETF Response to Results from OIF World Interoperability Demo

Dear Adrian and Kireeti,
Thank you for your responses to our liaison regarding our Supercomm Interoperability
Demo. We appreciate the time and effort that was spent reviewing our liaison and your
detailed reply, and hope for continued cooperation between our groups.

In response to your questions, we have the following information:
- Regarding compliance with ASON: there are no compliance "tests" for ASON,
however OIF has established a close liaison relationship with ITU-T over the past few
years and has aligned its specifications closely with the ITU-T ASON specifications,
especially G.8080, G.7713 and G.7713.1/2/3. We worked with ITU-T leading up to the
Demo to make sure that our activities were considered supportive of ASON and
welcomed by ITU-T.
- Regarding the use of the term "domain": we have been following ITU-T G.8080 in the
use of the term "domain". We are aware that an amendment to G.8080 is in progress in
ITU-T. We are following work on refinements to the definition of "domain" in G.8080
and expect that this work will also be liaised to IETF when complete.
- Regarding the issue of loss of RSVP signaling adjacency: we thank IETF for the
suggestion to utilize the procedures in draft-ietf-ccamp-ospf-gmpls-extensions for
this case, which would result in the associated link being made unavailable for new
connection requests. However, we note that the trigger identified in that draft is the
restart of an OSPF instance, which is an independent event from loss of RSVP signaling
adjacency due to DCN failure. Consequently we request that IETF consider the addition
of loss of RSVP signaling adjacency as a trigger for the procedures identified in
draft-ietf-ccamp-ospf-gmpls-extensions.
- Regarding reachability advertisement: we also thank IETF for the suggestion to use
the reachability advertisement document referenced in the liaison response, and would
request also that each address entry be supplemented to include a mask length, as the
reachable endpoints addresses may be summarizable. Including a mask would also
allow for address packing as shown for the Extended IP Reachability TLV in RFC 3784.
- Regarding the scope of OIF work, the existing Implementation Agreements for the
UNI and E-NNI are SONET/SDH oriented, however planned UNI 2.0 features include
support of additional services including G.709, sub-STS-1 signal types and Ethernet
interfaces (using the same solutions from existing CCAMP documents). We understand
that the ASON architecture itself is applicable to any layer network, existing and
future, and are phasing our work based on input from our carrier members on
capabilities that are of greatest importance to them.
- As a clarification, all Implementation Agreements represent fully ratified
documents, and are published on the OIF website after being voted on and approved by
the OIF membership. Current Implementation Agreements include the UNI 1.0R2 and the
Intra-Carrier E-NNI Signaling 1.0 specifications, available for open public access at
http://oiforum.com/public/impagreements.html.

Sincerely,
Jim Jones
OIF Technical Committee Chair
cc: [e-mail]




Envelope-to: [e-mail]
Delivery-date: Fri, 19 Nov 2004 12:15:16 +0000
Message-Id: <[e-mail]>
Date: Fri, 19 Nov 2004 21:12:57 +0900
To: Kireeti Kompella <[e-mail]>, [e-mail], [e-mail]
From: Tomonori TAKEDA <[e-mail]>
Subject: Re: charter update
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

The email I posted seems get lost. Sorry if this is a redundant email...

- L1VPNs:
     Define control and measurement plane mechanisms to support L1VPNs.
     Analyze applicability of these mechanisms.

As we discussed in CCAMP WG, the work would be expected to be around the 
use and application of GMPLS protocols to support L1VPN services. (Note: 
services does not necessary mean to external customers, can be applicable 
to internal usage as well.) There may be minor protocol extensions needed 
for this.

- Implementation/Interoperability experience


Best regards,

At 07:51 04/11/15 -0800, Kireeti Kompella wrote:
>Hi All,
>
>If you have suggested charter updates, please send them to Adrian and
>me.  Please keep this subject line (simply reply to this mail).
>
>The deadline is Friday Nov 19, 17:00 PST.
>
>Thanks,
>Kireeti.
>-------

-----
Tomonori TAKEDA
NTT Network Service Systems Lab.
Phone: [phone]




Envelope-to: [e-mail]
Delivery-date: Fri, 19 Nov 2004 00:40:03 +0000
Message-ID: <[e-mail]>
From: "Lam, Hing-Kam (Kam)" <[e-mail]>
To: Adrian Farrel <[e-mail]>
Cc: [e-mail], Bill Fenner <[e-mail]>, "'Kireeti Kompella'" <[e-mail]>, Scott Bradner <[e-mail]>, The IETF Secretariat <[e-mail]>, [e-mail]
Subject: RE: Liaison to ITU-T Q14 of SG15 on Crankback in GMPLS Systems
Date: Thu, 18 Nov 2004 19:37:46 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4CDCF.FD8B84C0"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C4CDCF.FD8B84C0
Content-Type: text/plain;
	charset="iso-8859-1"

Dear Mr. Farrel,

Thank you for the Liaison Statement on Crankback in GMPLS Systems. We appreciate the opportunity to provide input to the work. Q14/15 will address the LS in its upcoming meeting.

Regards,

Kam Lam, Q14/15 Rapporteur

-----Original Message-----
From: Adrian Farrel [mailto:[e-mail]]
Sent: Thursday, November 18, 2004 8:24 AM
To: Lam, Hing-Kam (Kam)
Cc: [e-mail]; Bill Fenner; 'Kireeti Kompella'; Scott Bradner; The IETF Secretariat; [e-mail]
Subject: Liaison to ITU-T Q14 of SG15 on Crankback in GMPLS Systems


To:           Mr. Kam Lam, Rapporteur for Question 14 of ITU-T Study Group 15.
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
              Scott Bradner, IETF/ITU-T Liaison Coordinator
For:          Action
Deadline:     15th December 2004
Subject:      Crankback in GMPLS Systems

Dear Mr. Lam,

The IETF's CCAMP Working Group notes that recent contributions to your question in SG15
have proposed adding the requirements, architecture and solutions for crankback
routing/signaling to your scope of work.

We would like to draw your attention to the work already done in the CCAMP Working Group
on this topic. The attached draft includes a discussion of requirements and solutions for
crankback within GMPLS systems.

The CCAMP Working Group would welcome input from SG15 on this work.

Sincerely,
Kireeti Kompella & Adrian Farrel, CCAMP WG chairs

Att/
draft-ietf-ccamp-crankback-03.txt 


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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 6.00.2800.1476" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV>
<P><FONT face=Arial color=#0000ff size=2>Dear Mr. Farrel,</FONT></P>
<P><FONT face=Arial color=#0000ff size=2>Thank you for the Liaison Statement 
on&nbsp;<SPAN class=969465623-18112004>Crankback in GMPLS Systems</SPAN>. We 
appreciate the opportunity to provide input to the work. Q14/15 will address the 
LS in its<SPAN class=969465623-18112004> up</SPAN>coming meeting.</FONT></P>
<P><FONT face=Arial color=#0000ff size=2>Regards,</FONT></P>
<P><FONT face=Arial color=#0000ff size=2>Kam Lam, Q14/15 
Rapporteur</FONT></P></DIV>
<BLOCKQUOTE 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Adrian Farrel 
  [mailto:[e-mail]]<BR><B>Sent:</B> Thursday, November 18, 2004 8:24 
  AM<BR><B>To:</B> Lam, Hing-Kam (Kam)<BR><B>Cc:</B> [e-mail]; Bill Fenner; 
  'Kireeti Kompella'; Scott Bradner; The IETF Secretariat; 
  [e-mail]<BR><B>Subject:</B> Liaison to ITU-T Q14 of SG15 on 
  Crankback in GMPLS Systems<BR><BR></FONT></DIV><FONT face=Courier 
  size=2>To:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Mr. Kam 
  Lam, Rapporteur for Question 14 of ITU-T Study Group 
  15.<BR>From:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Adrian Farrel and 
  Kireeti 
  Kompella<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  Co-chairs of the CCAMP Working Group of the 
  IETF<BR>Cc:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Alex 
  Zinin and Bill Fenner, Routing Area Directors of the 
  IETF<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  Scott Bradner, IETF/ITU-T Liaison 
  Coordinator<BR>For:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  Action<BR>Deadline:&nbsp;&nbsp;&nbsp;&nbsp; 15th December 
  2004<BR>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Crankback in GMPLS 
  Systems<BR><BR>Dear Mr. Lam,<BR><BR>The IETF's CCAMP Working Group notes that 
  recent contributions to your question in SG15<BR>have proposed adding the 
  requirements, architecture and solutions for crankback<BR>routing/signaling to 
  your scope of work.<BR><BR>We would like to draw your attention to the work 
  already done in the CCAMP Working Group<BR>on this topic. The attached draft 
  includes a discussion of requirements and solutions for<BR>crankback within 
  GMPLS systems.<BR><BR>The CCAMP Working Group would welcome input from SG15 on 
  this work.<BR><BR>Sincerely,<BR>Kireeti Kompella &amp; Adrian Farrel, CCAMP WG 
  chairs<BR><BR>Att/<BR>draft-ietf-ccamp-crankback-03.txt</FONT> 
</BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C4CDCF.FD8B84C0--



Envelope-to: [e-mail]
Delivery-date: Thu, 18 Nov 2004 15:02:29 +0000
Thread-Topic: charter update
thread-index: AcTNf24e1FlWjWPwRcqRYe0GK0fCyA==
Reply-To: =?ks_c_5601-1987?B?sei/tcit?= <[e-mail]>
From: =?ks_c_5601-1987?B?sei/tcit?= <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: 
Bcc: 
Subject: RE: charter update
Date: Fri, 19 Nov 2004 00:01:06 +0900
Comment: =?ks_c_5601-1987?B?x9GxucD8wNrF673Fv6yxuL/4LCCxpMD8tN64wcGmvu7GwCwgtOM=?= =?ks_c_5601-1987?B?tOc=?=
Message-ID: <078401c4cd7f$6e233bc0$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0785_01C4CDCA.DE0AE3C0"
Content-Class: urn:content-classes:message

This is a multi-part message in MIME format.

------=_NextPart_000_0785_01C4CDCA.DE0AE3C0
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64


------=_NextPart_000_0785_01C4CDCA.DE0AE3C0
Content-Type: text/html;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

PERJViBpZD1tc2dib2R5IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiCxvLiy
Ij4NCjxESVY+SGkgS2lyZWV0aSBhbmQgQWRyaWFuLDwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4N
CjxESVY+SW4gYWRkaXRpb24gdG8gdGhvc2UgWmFmYXIgc2FpZCw8L0RJVj4NCjxESVY+Jm5ic3A7
PC9ESVY+DQo8RElWPi0gUHJvdGVjdGlvbiBvZiBjb250cm9sIGNoYW5uZWwsIGlmIHdlIGZpbmQg
dGhpcyBpdGVtIG91dHNpZGUgdGhlIGN1cnJlbnQgc2NvcGUuPC9ESVY+DQo8RElWPiZuYnNwOzwv
RElWPg0KPERJVj4tIFByb3RvY29scy9TZXJ2aWNlcyBJbnRlcm9wZXJhYmlsaXR5LCBpZiB0aGlz
IGl0ZW0gaXMgbm90IGNvdmVyZWQgaW4gdGhlIGN1cnJlbnQgc2NvcGUuPC9ESVY+DQo8RElWPiZu
YnNwOyZuYnNwOyBJIHRoaW5rLCBmb3IgaGVscGluZyZuYnNwO2FuIGludGVyd29ya2luZyBndWlk
ZWxpbmUgb2Ygc3lzdGVtcyZuYnNwO2Zyb20gZGlmZmVyZW50IHZlbmRlcnMsIHRoZSA8L0RJVj4N
CjxESVY+Jm5ic3A7Jm5ic3A7IGludGVyb3BlcmFiaWxpdHkgaXNzdWUgc2hvdWwgYmUgaGFuZGxl
ZC48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPi0gUW9TIENvbnRyb2wgZm9yIEdNUExT
LCBpZiB3ZSBmaW5kIHRoaXMgaXRlbSBvdXRzaWRlIHRoZSBjdXJyZW50IHNjb3BlLjwvRElWPg0K
PERJVj4mbmJzcDs8L0RJVj4NCjxESVY+VGhhbmtzPEJSPjxCUj5SZWdhcmRzLi4uIFlvdW5nPEJS
PjxCUj4tLS0tLb/4ursguN69w8H2LS0tLS08QlI+PEI+urizvSC757b3OjwvQj4gIktpcmVldGkg
S29tcGVsbGEiICZsdDtraXJlZXRpQGp1bmlwZXIubmV0Jmd0OzxCUj48Qj66uLO9ILOvwqU6PC9C
PiAyMDA0LTExLTE2IL/AwPwgMTI6NTE6MDI8QlI+PEI+ud60wiC757b3OjwvQj4gImNjYW1wQG9w
cy5pZXRmLm9yZyIgJmx0O2NjYW1wQG9wcy5pZXRmLm9yZyZndDs8QlI+PEI+wvzBtjo8L0I+IDxC
Uj48Qj7BprjxOjwvQj4gY2hhcnRlciB1cGRhdGU8QlI+PEJSPg0KPE1FVEEgY29udGVudD0iTVMg
RXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNi41LjcyMjYuMCIgbmFtZT1HZW5lcmF0b3I+PCEtLSBD
b252ZXJ0ZWQgZnJvbSB0ZXh0L3BsYWluIGZvcm1hdCAtLT48QlI+PC9ESVY+DQo8UD48Rk9OVCBz
aXplPTI+SGkgQWxsLDxCUj48QlI+SWYgeW91IGhhdmUgc3VnZ2VzdGVkIGNoYXJ0ZXIgdXBkYXRl
cywgcGxlYXNlIHNlbmQgdGhlbSB0byBBZHJpYW4gYW5kPEJSPm1lLiZuYnNwOyBQbGVhc2Uga2Vl
cCB0aGlzIHN1YmplY3QgbGluZSAoc2ltcGx5IHJlcGx5IHRvIHRoaXMgbWFpbCkuPEJSPjxCUj5U
aGUgZGVhZGxpbmUgaXMgRnJpZGF5IE5vdiAxOSwgMTc6MDAgUFNULjxCUj48QlI+VGhhbmtzLDxC
Uj5LaXJlZXRpLjxCUj4tLS0tLS0tPEJSPjxCUj48L0ZPTlQ+PC9QPjwvRElWPg==

------=_NextPart_000_0785_01C4CDCA.DE0AE3C0--



Envelope-to: [e-mail]
Delivery-date: Thu, 18 Nov 2004 13:56:01 +0000
Message-ID: <03af01c4cd76$1a4a79e0$749c9ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Lam, Hing-Kam (Kam)" <[e-mail]>
Cc: <[e-mail]>, "Bill Fenner" <[e-mail]>, "'Kireeti Kompella'" <[e-mail]>, "Scott Bradner" <[e-mail]>, "The IETF Secretariat" <[e-mail]>, <[e-mail]>
Subject: Liaison to ITU-T Q14 of SG15 on Crankback in GMPLS Systems
Date: Thu, 18 Nov 2004 13:24:24 -0000
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_0380_01C4CD71.EBB34750"

This is a multi-part message in MIME format.

------=_NextPart_000_0380_01C4CD71.EBB34750
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0381_01C4CD71.EBB34750"


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

To:           Mr. Kam Lam, Rapporteur for Question 14 of ITU-T Study =
Group 15.
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
              Scott Bradner, IETF/ITU-T Liaison Coordinator
For:          Action
Deadline:     15th December 2004
Subject:      Crankback in GMPLS Systems

Dear Mr. Lam,

The IETF's CCAMP Working Group notes that recent contributions to your =
question in SG15
have proposed adding the requirements, architecture and solutions for =
crankback
routing/signaling to your scope of work.

We would like to draw your attention to the work already done in the =
CCAMP Working Group
on this topic. The attached draft includes a discussion of requirements =
and solutions for
crankback within GMPLS systems.

The CCAMP Working Group would welcome input from SG15 on this work.

Sincerely,
Kireeti Kompella & Adrian Farrel, CCAMP WG chairs

Att/
draft-ietf-ccamp-crankback-03.txt 
------=_NextPart_001_0381_01C4CD71.EBB34750
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.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff><FONT face=3DCourier=20
size=3D2>To:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Mr. Kam=20
Lam, Rapporteur for Question 14 of ITU-T Study Group=20
15.<BR>From:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Adrian =
Farrel and=20
Kireeti=20
Kompella<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;=20
Co-chairs of the CCAMP Working Group of the=20
IETF<BR>Cc:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Alex=20
Zinin and Bill Fenner, Routing Area Directors of the=20
IETF<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;=20
Scott Bradner, IETF/ITU-T Liaison=20
Coordinator<BR>For:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
Action<BR>Deadline:&nbsp;&nbsp;&nbsp;&nbsp; 15th December=20
2004<BR>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Crankback in GMPLS=20
Systems<BR><BR>Dear Mr. Lam,<BR><BR>The IETF's CCAMP Working Group notes =
that=20
recent contributions to your question in SG15<BR>have proposed adding =
the=20
requirements, architecture and solutions for =
crankback<BR>routing/signaling to=20
your scope of work.<BR><BR>We would like to draw your attention to the =
work=20
already done in the CCAMP Working Group<BR>on this topic. The attached =
draft=20
includes a discussion of requirements and solutions for<BR>crankback =
within=20
GMPLS systems.<BR><BR>The CCAMP Working Group would welcome input from =
SG15 on=20
this work.<BR><BR>Sincerely,<BR>Kireeti Kompella &amp; Adrian Farrel, =
CCAMP WG=20
chairs<BR><BR>Att/<BR>draft-ietf-ccamp-crankback-03.txt</FONT> =
</BODY></HTML>

------=_NextPart_001_0381_01C4CD71.EBB34750--

------=_NextPart_000_0380_01C4CD71.EBB34750
Content-Type: text/plain;
	name="draft-ietf-ccamp-crankback-03.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="draft-ietf-ccamp-crankback-03.txt"

Network Working Group                             Adrian Farrel (editor)
Internet Draft                                        Old Dog Consulting
Category: Standards Track
Expires: April 2005                                   Arun Satyanarayana
                                                    Movaz Networks, Inc.

                                                           Atsushi Iwata
                                                         Norihito Fujita
                                                         NEC Corporation

                                                    Gerald R. Ash (AT&T)

                                                            October 2004

           Crankback Signaling Extensions for MPLS Signaling
                 <draft-ietf-ccamp-crankback-03.txt>

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   or will be disclosed, and any of which I become aware will be
   disclosed, in accordance with RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be
   accessed at http://www.ietf.org/shadow.html.

Abstract

   In a distributed, constraint-based routing environment, the
   information used to compute a path may be out of date. This means
   that Multiprotocol Label Switching (MPLS) label switched path (LSP)
   setup requests may be blocked by links or nodes without sufficient
   resources. Crankback is a scheme whereby setup failure information is
   returned from the point of failure to allow new setup attempts to be
   made avoiding the blocked resources. Crankback can also be applied to
   LSP restoration to indicate the location of the failed link or node.

   This document specifies crankback signaling extensions for use in
   MPLS signaling using RSVP-TE as defined in "RSVP-TE: Extensions to
   RSVP for LSP Tunnels", RFC3209, so that the LSP setup request can be
   retried on an alternate path that detours around blocked links or
   nodes. This offers significant improvements in the successful setup
   and recovery ratios for LSPs, especially in situations where a large
   number of setup requests are triggered at the same time.

A. Farrel et al.                                                  Page 1
=0C
draft-ietf-ccamp-crankback-03.txt                           October 2004

Table of Contents

   Section A : Problem Statement

   1. Terminology......................................................3
   2. Introduction and Framework.......................................3
   2.1. Background.....................................................3
   2.2. Repair and Restoration.........................................4
   3. Discussion: Explicit Versus Implicit Re-routing Indications......5
   4. Required Operation...............................................6
   4.1. Resource Failure or Unavailability.............................6
   4.2. Computation of an Alternate Path...............................6
   4.2.1 Information Required for Re-routing...........................7
   4.2.2 Signaling a New Route.........................................7
   4.3. Persistence of Error Information...............................7
   4.4. Handling Re-route Failure......................................7
   4.5. Limiting Re-routing Attempts...................................8
   5. Existing Protocol Support for Crankback Re-routing...............8
   5.1. RSVP-TE [RFC 3209].............................................9
   5.2. GMPLS-RSVP-TE [RFC 3473].......................................9

   Section B : Solution

   6. Control of Crankback Operation..................................10
   6.1. Requesting Crankback and Controlling In-Network Re-routing....10
   6.2. Action on Detecting a Failure.................................11
   6.3. Limiting Re-routing Attempts..................................11
   6.3.1 New Status Codes for Re-routing..............................11
   6.4. Protocol Control of Re-routing Behavior.......................11
   7. Reporting Crankback Information.................................12
   7.1. Required Information..........................................12
   7.2. Protocol Extensions...........................................12
   7.3 Guidance for Use of IF_ID Error Spec TLVs......................16
   7.3.1 General Principles...........................................16
   7.3.2 Error Report TLVs............................................17
   7.3.3 Fundamental Crankback TLVs...................................17
   7.3.4 Additional Crankback TLVs....................................18
   7.3.5 Grouping TLVs by Failure Location............................19
   7.3.6 Alternate Path identification................................20
   7.4. Action on Receiving Crankback Information.....................20
   7.4.1 Re-route Attempts............................................20
   7.4.2 Location Identifiers of Blocked Links or Nodes...............20
   7.4.3 Locating Errors within Loose or Abstract Nodes...............21
   7.4.4 When Re-routing Fails........................................21
   7.4.5 Aggregation of Crankback Information.........................21
   7.5. Notification of Errors........................................22
   7.5.1 ResvErr Processing...........................................22
   7.5.2 Notify Message Processing....................................22
   7.6. Error Values..................................................23
   7.7. Backward Compatibility........................................23
   8. Routing Protocol Interactions...................................23
   9. LSP Restoration Considerations..................................24
   9.1. Upstream of the Fault.........................................24
   9.2. Downstream of the Fault.......................................25
   10. IANA Considerations............................................25

A. Farrel et al.                                                  Page 2
=0C
draft-ietf-ccamp-crankback-03.txt                           October 2004

   10.1. Error Codes..................................................25
   10.2. IF_ID_ERROR_SPEC TLVs........................................25
   10.3. LSP_ATTRIBUTES Object........................................25
   11. Security Considerations........................................26
   12. Acknowledgments................................................26
   13. Intellectual Property Considerations...........................26
   14. Normative References...........................................26
   15. Informational References.......................................27
   16. Authors' Addresses.............................................28
   17. Disclaimer of Validity.........................................29
   18. Full Copyright Statement.......................................29
   A.  Experience of Crankback in TDM-based Networks..................30

Section A : Problem Statement

0. Changes

(This section to be removed before publication as an RFC.)

0.1 Changes from 01 to 02, and 02 to 03 Versions

   - Update IPR and copyright
   - Update references

0.2 Changes from 00 to 01 Versions

   - Removal of background descriptive material pertaining to TDM
     network experience from section 3 to an Appendix.
   - Removal of definition of Error Spec TLVs for unnumbered bundled
     links from section 7.2 to a separate document.
   - More detailed guidance on which Error Spec TLVs to use when.
   - Change LSP_ATTRIBUTE flags from hex values to bit numbers.
   - Typographic errors fixed.
   - Update references.

1. Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2. Introduction and Framework

2.1. Background

   RSVP-TE (RSVP Extensions for LSP Tunnels) [RFC3209] can be
   used for establishing explicitly routed LSPs in an MPLS
   network. Using RSVP-TE, resources can also be reserved
   along a path to guarantee or control QoS for traffic
   carried on the LSP. To designate an explicit path that
   satisfies QoS constraints, it is necessary to discern the
   resources available to each link or node in the network.
   For the collection of such resource information, routing
   protocols, such as OSPF and IS-IS , can be extended to
   distribute additional state information [RFC2702].

A. Farrel et al.                                                  Page 3
=0C
draft-ietf-ccamp-crankback-03.txt                           October 2004

   Explicit paths can be computed based on the distributed
   information at the LSR initiating an LSP and signaled as
   Explicit Routes during LSP establishment. Explicit Routes
   may contain 'loose hops' and 'abstract nodes' that convey
   routing through any of a collection of nodes. This
   mechanism may be used to devolve parts of the path
   computation to intermediate nodes such as area border LSRs.

   In a distributed routing environment, however, the
   resource information used to compute a constraint-based
   path may be out of date. This means that a setup request
   may be blocked, for example, because a link or node along
   the selected path has insufficient resources.

   In RSVP-TE, a blocked LSP setup may result in a PathErr
   message sent to the initiator, or a ResvErr sent to the
   terminator (egress LSR). These messages may result in the
   LSP setup being abandoned. In Generalized MPLS [RC3473]
   the Notify message may additionally be used to expedite
   notification of LSP failures to ingress and egress LSRs,
   or to a specific "repair point".

   These existing mechanisms provide a certain amount of
   information about the path of the failed LSP.

2.2. Repair and Restoration

   If the ingress LSR or intermediate area border LSR knows
   the location of the blocked link or node, the LSR can
   designate an alternate path and then reissue the setup
   request. Determination of the identity of the blocked
   link or node can be achieved by the mechanism known as
   crankback routing [PNNI, ASH1]. In RSVP-TE, crankback
   signaling requires notifying an upstream LSR of the
   location of the blocked link or node. In some cases this
   requires more information than is currently available in
   the signaling protocols.

   On the other hand, various restoration schemes for link
   or node failures have been proposed in [RFC3469] and
   include fast restoration. These schemes rely on
   the existence of a backup LSP to protect the primary, but
   if both the primary and backup paths fail it is necessary
   to re-establish the LSP on an end-to-end basis avoiding
   the known failures. Similarly, fast restoration by
   establishing a restoration path on demand after failure
   requires computation of a new LSP that avoids the known
   failures. End-to-end restoration for alternate routing
   requires the location of the failed link or node.
   Crankback routing schemes could be used to notify
   upstream LSRs of the location of the failure.

   Furthermore, in situations where many link or node
   failures occur at the same time, the difference between
   the distributed routing information and the real-time

A. Farrel et al.                                                  Page 4
=0C
draft-ietf-ccamp-crankback-03.txt                           October 2004

   network state becomes much greater than in normal LSP
   setups. LSP restoration might, therefore, be performed
   with inaccurate information, which is likely to cause
   setup blocking. Crankback routing could improve failure
   recovery in these situations.

   Generalized MPLS [RFC3471] extends MPLS into networks
   that manage Layer 2, TDM and lambda resources. In a
   network without wavelength converters, setup requests are
   likely to be blocked more often than in a conventional
   MPLS environment because the same wavelength must be
   allocated at each Optical Cross-Connect on an end-to-end
   explicit path. Furthermore, end-to-end restoration is the
   only way to recover LSP failures. This implies that
   crankback routing would also be useful in a GMPLS
   network, in particular in dynamic LSP re-routing cases
   (no backup LSP pre-establishment).

3. Discussion: Explicit Versus Implicit Re-routing Indications

   There have been problems in service provider networks
   when "inferring" from indirect information that re-routing
   is allowed. This document proposes the use of an explicit
   re-routing indication that explicitly authorizes re-routing.

   Various existing protocol options and exchanges including
   the error values of PathErr message [RFC2205, RFC3209]
   and the Notify message [RFC3473] allow an implementation
   to infer a situation where re-routing can be done. This
   allows for recovery from network errors or resource
   contention.

   However, such inference of recovery signaling is not always
   desirable since it may be doomed to failure.  For example,
   experience of using release messages in TDM-based networks for
   analogous implicit and explicit re-routing indications purposes
   provides some guidance. This background information is given in
   Appendix A."

   It is certainly the case that with topology exchange,
   such as OSPF, the ingress LSR could infer the re-routing
   condition. However, convergence of routing information is
   typically slower than the expected LSP setup times. One of
   the reasons for crankback is to avoid the overhead of
   available-link-bandwidth flooding, and to more efficiently
   use local state information to direct alternate routing
   at the ingress-LSR.

   [ASH1] shows how event-dependent-routing can just use crankback,
   and not available-link-bandwidth flooding, to decide on the
   re-route path in the network through "learning models". Reducing
   this flooding reduces overhead and can lead to the ability to
   support much larger AS sizes.



A. Farrel et al.                                                  Page 5
=0C
draft-ietf-ccamp-crankback-03.txt                           October 2004

   Therefore, the alternate routing should be indicated based on
   an explicit indication, and it is best to know the following
   information separately:

   - where blockage/congestion occurred
   - whether alternate routing "should" be attempted.

4. Required Operation

   Section 2 identifies some of the circumstances under which
   crankback may be useful. Crankback routing is performed as
   described in the following procedures, when an LSP setup
   request is blocked along the path, or when an existing LSP fails.

4.1. Resource Failure or Unavailability

   When an LSP setup request is blocked due to unavailable
   resources, an error message response with the location
   identifier of the blockage should be returned to the LSR
   initiating the LSP setup (ingress LSR), the area border
   LSR, the AS border LSR, or to some other repair point.

   This error message carries an error specification
   according to [RFC3209] - this indicates the cause of the
   error and the node/link on which the error occurred.
   Crankback operation may require further information as
   detailed in sections 4.2.1 and 7.

4.2. Computation of an Alternate Path

   In a flat network without partitioning, when the ingress
   LSR receives the error message it computes an alternate
   path around the blocked link or node to satisfy QoS
   constraints using link state information about the network.
   If an alternate path is found, a new LSP setup request is
   sent over this path.

   On the other hand, in a network partitioned into areas
   such as with hierarchical OSPF, an area border LSR may
   intercept and terminate the error response, and perform
   alternate (re-)routing within the downstream area.

   In a third scenario, any node within an area may act as a
   repair point. In this case, each LSR behaves much as an
   area border LSR as described above. It can intercept and
   terminate the error response, and perform alternate
   routing. This may be particularly useful where domains of
   computation are applied within the network, however if
   all nodes in the network perform re-routing it is
   possible to spend excessive network and CPU resources on
   re-routing attempts that would be better made only at
   designated re-routing nodes. This scenario is somewhat
   like 'MPLS fast re-route' [FASTRR], in which any node in
   the MPLS domain can establish 'local repair' LSPs after
   failure notification.

A. Farrel et al.                                                  Page 6
=0C
draft-ietf-ccamp-crankback-03.txt                           October 2004

4.2.1 Information Required for Re-routing

   In order to correctly compute a route that avoids the
   blocking problem, a repair point LSR must gather as much
   crankback information as possible. Ideally, the repair
   node will be given the node, link and reason for the
   failure.

   However, this information may not be enough to help with
   re-computation. Consider for instance an explicit route
   that contains a non-explicit abstract node or a loose
   hop. In this case, the failed node and link is not
   necessarily enough to tell the repair point which hop in
   the explicit route has failed. The crankback information
   needs to provide the context into the explicit route.

4.2.2 Signaling a New Route

   If the crankback information can be used to compute a new
   route avoiding the blocking problem, the route can be
   signaled as an Explicit Route.

   However, it may be that the repair point does not have
   sufficient topology information to compute an Explicit
   Route that is guaranteed to avoid the failed link or
   node. In this case, Route Exclusions [EXCLUDE] may be
   particularly helpful. To achieve this, [EXCLUDE] allows
   the crankback information to be presented as route exclusions
   to force avoidance of the failed node, link or resource.

4.3. Persistence of Error Information

   The repair point LSR that computes the alternate path
   should store the location identifiers of the blockages
   indicated in the error message until the LSP is
   successfully established or until the LSR abandons re-routing
   attempts. Since crankback routing may happen more than once
   while establishing a specific LSP, a history table of all
   experienced blockages for this LSP SHOULD be maintained (at
   least until the routing protocol updates the state of this
   information) to perform an accurate path computation to
   detour all blockages.

   If a second error response is received by a repair point (while
   it is performing crankback re-routing) it should update the
   history table that lists all experienced blockages, and use the
   entire gathered information when making a further re-routing attempt.

4.4. Handling Re-route Failure

   Multiple blockages (for the same LSP) may occur, and successive
   setup retry attempts may fail. Retaining error information from
   previous attempts ensures that there is no thrashing of setup
   attempts, and knowledge of the blockages increases with each
   attempt.

A. Farrel et al.                                                  Page 7
=0C
draft-ietf-ccamp-crankback-03.txt                           October 2004

   It may be that after several retries, a given repair point is
   unable to compute a path to the destination (that is, the egress
   of the LSP) that avoids all of the blockages. In this case, it
   must pass the error indication upstream. It is most useful to the
   upstream nodes (and in particular the ingress LSR) that may,
   themselves, attempt new routes for the LSP setup, if the error
   indication in this case identifies all of the downstream blockages
   and also the node that has been unable to compute an alternate path.

4.5. Limiting Re-routing Attempts

   It is important to prevent an endless repetition of LSP
   setup attempts using crankback routing information after
   error conditions are signaled, or during periods of high
   congestion. It may also be useful to reduce the number of
   retries, since failed retries will increase setup latency
   and degrade performance.

   The maximum number of crankback re-routing attempts
   allowed may be limited in a variety of ways. The number
   may be limited by LSP, by node, by area or by AS. Control
   of the limit may be applied as a configuration item per
   LSP, per node, per area or per AS.

   When the number of retries at a particular node, area or
   AS is exceeded, the LSR handling the current failure
   reports the failure upstream to the next node, area or AS
   where further re-routing attempts may be attempted. It is
   important that the crankback information provided
   indicates that routing back through this node, area or AS
   will not succeed - this situation is similar to that in
   section 4.4. Note that in some circumstances, such a
   report will also mean that no further re-routing attempts
   can possibly succeed - for example, when the egress node
   is within the failed area.

   When the maximum number of retries for a specific LSP has
   been exceeded, the LSR handling the current failure
   should send an error message upstream indicating "Maximum
   number of re-routings exceeded". This error will be
   passed back to the ingress LSR with no further re-routing
   attempts. The ingress LSR may choose to retry the LSP
   setup according to local policy and might choose to re-use
   its original path or seek to compute a path that avoids
   the blocked resources. In the latter case, it may be
   useful to indicate the blocked resource in this error
   message.

5. Existing Protocol Support for Crankback Re-routing

   Crankback re-routing is appropriate for use with RSVP-TE.

   1) LSP establishment may fail because of an inability to
      route, perhaps because links are down. In this case a
      PathErr message is returned to the initiator.

A. Farrel et al.                                                  Page 8
=0C
draft-ietf-ccamp-crankback-03.txt                           October 2004

   2) LSP establishment may fail because resources are
      unavailable. This is particularly relevant in GMPLS where
      explicit label control may be in use. Again, a PathErr
      message is returned to the initiator.

   3) Resource reservation may fail during LSP establishment,
      as the Resv is processed. If
      resources are not available on the required link or at a
      specific node, a ResvErr message is returned to the egress
      node indicating "Admission Control failure" [RFC2205]. The
      egress is allowed to change the FLOWSPEC and try again, but
      in the event that this is not practical or not supported
      (particularly in the GMPLS context), the egress LSR may
      choose to take any one of the following actions.

      - Ignore the situation and allow recovery to happen through
        Path refresh message and refresh timeout [RFC2205].
      - Send a PathErr message towards the initiator indicating
        "Admission Control failure".
      - Send a ResvTear message towards the initiator to abort
        the LSP setup.

      Note that in multi-area/AS networks, the ResvErr might be
      intercepted and acted on at an area/AS border router.

   4) It is also possible to make resource reservations on the forward
      path as the Path message is processed. This choice is compatible
      with LSP setup in GMPLS networks [RFC3471]. In this case if
      resources are not available, a PathErr message is returned to
      initiator indicating "Admission Control failure".

   Crankback information would be useful to an upstream node (such as
   the ingress) if it is supplied on a PathErr or a Notify message that
   is sent upstream.

5.1. RSVP-TE [RFC 3209]

   In RSVP-TE a failed LSP setup attempt results in a PathErr
   message returned upstream. The PathErr message carries an
   ERROR_SPEC object, which indicates the node or interface
   reporting the error and the reason for the failure.

   Crankback re-routing can be performed explicitly avoiding
   the node or interface reported.

5.2. GMPLS-RSVP-TE [RFC 3473]

   GMPLS extends the error reporting described above by
   allowing LSRs to report the interface that is in error in
   addition to the identity of the node reporting the error.
   This further enhances the ability of a re-computing node
   to route around the error.

   GMPLS introduces a targeted Notify message that may be used to
   report LSP failures direct to a selected node. This message carries

A. Farrel et al.                                                  Page 9
=0C
draft-ietf-ccamp-crankback-03.txt                           October 2004

   the same error reporting facilities as described above. The Notify
   message may be used to expedite the propagation of error
   notifications, but in a network that offers crankback routing at
   multiple nodes there would need to be some agreement between LSRs
   as to whether PathErr or Notify provides the stimulus for crankback
   operation. Otherwise, multiple nodes might attempt to repair the LSP
   at the same time, because

   1) these messages can flow through different paths before
      reaching the ingress LSR, and
   2) the destination of the Notify message might not be the
      ingress LSR.


Section B : Solution

6. Control of Crankback Operation

6.1. Requesting Crankback and Controlling In-Network Re-routing

   When a request is made to set up an LSP tunnel, the ingress LSR
   should specify whether it wants crankback information to be collected
   in the event of a failure, and whether it requests re-routing
   attempts by any or specific intermediate nodes. For this purpose, a
   Re-routing Flag field is added to the protocol setup request
   messages. The corresponding values are mutually exclusive.

   No Re-routing          The ingress node MAY attempt re-routing after
                          failure. Intermediate nodes SHOULD NOT attempt
                          re-routing after failure. Nodes detecting
                          failures MUST report an error and MAY supply
                          crankback information. This is the default
                          and backwards compatible option.

   End-to-end Re-routing  The ingress node MAY attempt re-routing after
                          failure. Intermediate nodes SHOULD NOT attempt
                          re-routing after failure. Nodes detecting
                          failures MUST report an error and SHOULD
                          supply crankback information.

   Boundary Re-routing    Intermediate nodes MAY attempt re-routing
                          after failure only if they are Area Border
                          Routers or AS Border Routers. The boundary
                          (ABR/ASBR) can either decide to forward the
                          error message upstream to the ingress
                          LSR or try to select another egress boundary
                          LSR. Other intermediate nodes SHOULD NOT
                          attempt re-routing. Nodes detecting failures
                          MUST report an error and SHOULD supply
                          crankback information.






A. Farrel et al.                                                 Page 10
=0C
draft-ietf-ccamp-crankback-03.txt                           October 2004

   Segment-based Re-routing
                          All nodes MAY attempt re-routing after
                          failure. Nodes detecting failures MUST report
                          an error and SHOULD supply full crankback
                          information.

6.2. Action on Detecting a Failure

   A node that detects the failure to setup an LSP or the failure of an
   established LSP SHOULD act according to the Re-routing Flag passed on
   the LSP setup request.

   If Segment-based Re-routing is allowed, or if Boundary Re-routing is
   allowed and the detecting node is an ABR or ASBR, the detecting node
   MAY immediately attempt to re-route.

   If End-to-end Re-routing is indicated, or if Segment-based or
   Boundary Re-routing is allowed and the detecting node chooses
   not to make re-routing attempts (or has exhausted all possible
   re-routing attempts), the detecting node MUST return a protocol
   error indication and SHOULD include full crankback information.

6.3. Limiting Re-routing Attempts

   Each repair point SHOULD apply a locally configurable
   limit to the number of attempts it makes to re-route an
   LSP. This helps to prevent excessive network usage in the
   event of significant faults, and allows back-off to other
   repair points which may have a better chance of routing
   around the problem.

6.3.1 New Status Codes for Re-routing

   An error code/value of "Routing Problem"/"Re-routing
   limit exceeded" (24/TBD) is used to identify that a node
   has abandoned crankback re-routing because it has reached
   a threshold for retry attempts.

   A node receiving an error response with this status code
   MAY also attempt crankback re-routing, but it is RECOMMENDED
   that such attempts be limited to the ingress LSR.

6.4. Protocol Control of Re-routing Behavior

   The Session Attributes Object in RSVP-TE is used on Path
   messages to indicate the capabilities and attributes of the
   session. This object contains an 8-bit flag field which is
   used to signal individual Boolean capabilities or attributes.
   The Re-Routing Flag described in section 5.1 would fit
   naturally into this field, but there is a scarcity of bits, so
   use is made of the new LSP_ATTRIBUTES object defined in
   [LSP-ATTRIB]. Three bits are defined for inclusion in the LSP
   Attributes TLV as follows. The bit numbers below are suggested
   and actual values are TBD by IETF consensus.


A. Farrel et al.                                                 Page 11
=0C
draft-ietf-ccamp-crankback-03.txt                           October 2004

   Bit     Name and Usage
   Number

      1    End-to-end re-routing desired.
           This flag indicates the end-to-end re-routing behavior
           for an LSP under establishment. This MAY also be used
           for specifying the behavior of end-to-end LSP restoration
           for established LSPs.

      2    Boundary re-routing desired.
           This flag indicates the boundary re-routing
           behavior for an LSP under establishment.
           This MAY also be used for specifying the
           segment-based (hierarchical) LSP restoration
           for established LSPs. The boundary ABR/ASBR
           can either decide to forward the PathErr
           message upstream to the Head-end LSR or try
           to select another egress boundary LSR.

      3    Segment-based re-routing desired.
           This flag indicates the segment-based
           re-routing behavior for an LSP under
           establishment. This MAY also be used
           for specifying the segment-based LSP
           restoration for established LSPs.

7. Reporting Crankback Information

7.1. Required Information

   As described above, full crankback information SHOULD
   indicate the node, link and other resources, which have
   been attempted but have failed because of allocation
   issues or network failure.

   The default crankback information SHOULD include the
   interface and the node address.

7.2. Protocol Extensions

   [RFC3473] defines an IF_ID ERROR_SPEC object that can be
   used on PathErr, ResvErr and Notify messages to convey
   the information carried in the Error Spec Object defined
   in [RFC 3209]. Additionally, the IF_ID ERROR_SPEC Object
   has scope for carrying TLVs that identify the link
   associated with the error.

   The TLVs for use with this object are defined in [RFC3471], and
   are listed below. They are used to identify links in the IF_ID
   PHOP Object and in the IF_ID ERROR_SPEC object to identify the
   failed resource which is usually the downstream resource from
   the reporting node.




A. Farrel et al.                                                 Page 12
=0C
draft-ietf-ccamp-crankback-03.txt                           October 2004

   Type Length Format     Description
   --------------------------------------------------------------------
    1      8   IPv4 Addr. IPv4                    (Interface address)
    2     20   IPv6 Addr. IPv6                    (Interface address)
    3     12   Compound   IF_INDEX                (Interface index)
    4     12   Compound   COMPONENT_IF_DOWNSTREAM (Component interface)
    5     12   Compound   COMPONENT_IF_UPSTREAM   (Component interface)

   Two further TLVs are defined in [TE-BUNDLE] for use in the IF_ID
   PHOP Object and in the IF_ID ERROR_SPEC object to identify component
   links of unnumbered interfaces. Note that the Type values shown here
   are only suggested values in [TE-BUNDLE] - final values are TBD and
   to be determined by IETF consensus.

   Type Length Format     Description
   --------------------------------------------------------------------
    6     16   Compound   UNUM_COMPONENT_IF_DOWN  (Component interface)
    7     16   Compound   UNUM_COMPONENT_IF_UP    (Component interface)

   In order to facilitate reporting of crankback information, the
   following additional TLVs are defined. Note that the Type values
   shown here are only suggested values - final values are TBD and to be
   determined by IETF consensus.

   Type Length Format     Description
   --------------------------------------------------------------------
    8    var   See below  DOWNSTREAM_LABEL        (GMPLS label)
    9    var   See below  UPSTREAM_LABEL          (GMPLS label)
   10      8   See below  NODE_ID                 (Router Id)
   11      x   See below  OSPF_AREA               (Area Id)
   12      x   See below  ISIS_AREA               (Area Id)
   13      8   See below  AUTONOMOUS_SYSTEM       (Autonomous system)
   14    var   See below  ERO_CONTEXT             (ERO subobject)
   15    var   See below  ERO_NEXT_CONTEXT        (ERO subobjects)
   16      8   IPv4 Addr. PREVIOUS_HOP_IPv4       (Node address)
   17     20   IPv6 Addr. PREVIOUS_HOP_IPv6       (Node address)
   18      8   IPv4 Addr. INCOMING_IPv4           (Interface address)
   19     20   IPv6 Addr. INCOMING_IPv6           (Interface address)
   20     12   Compound   INCOMING_IF_INDEX       (Interface index)
   21     12   Compound   INCOMING_COMP_IF_DOWN   (Component interface)
   22     12   Compound   INCOMING_COMP_IF_UP     (Component interface)
   23     16   See below  INCOMING_UNUM_COMP_DOWN (Component interface)
   24     16   See below  INCOMING_UNUM_COMP_UP   (Component interface)
   25    var   See below  INCOMING_DOWN_LABEL     (GMPLS label)
   26    var   See below  INCOMING_UP_LABEL       (GMPLS label)
   27      8   See below  REPORTING_NODE_ID       (Router Id)
   28      x   See below  REPORTING_OSPF_AREA     (Area Id)
   29      x   See below  REPORTING_ISIS_AREA     (Area Id)
   30      8   See below  REPORTING_AS            (Autonomous system)
   31    var   See below  PROPOSED_ERO            (ERO subobjects)
   32    var   See below  NODE_EXCLUSIONS         (List of nodes)
   33    var   See below  LINK_EXCLUSIONS         (List of interfaces)




A. Farrel et al.                                                 Page 13
=0C
draft-ietf-ccamp-crankback-03.txt                           October 2004

   For types 1, 2, 3, 4 and 5, the format of the Value field
   is already defined in [RFC3471].

   For types 6 and 7 the format of the Value field is already
   defined in [TE-BUNDLE].

   For types 16 and 18, they format of the Value field is
   the same as for type 1.

   For types 17 and 19, the format of the Value field is the
   same as for type 2.

   For types 20, 21 and 22, the formats of the Value fields
   are the same as for types 3, 4 and 5 respectively.

   For types 23 and 24 the Value field is the same as for
   types 6 and 7 respectively.

   For types 8, 9, 25 and 26 the length field is variable
   and the Value field is a label as defined in [RFC3471].
   As with all uses of labels, it is assumed that any node
   that can process the label information knows the syntax
   and semantics of the label from the context. Note that
   all TLVs are zero-padded to a multiple four octets so
   that if a label is not itself a multiple of four octets
   it must be disambiguated from the trailing zero pads by
   knowledge derived from the context.
   For types 10 and 27 the Value field has the format:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Router Id                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Router Id: 32 bits

          The Router Id used to identify the node within the IGP.

   For types 11 and 28 the Value field has the format:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     OSPF Area Identifier                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       OSPF Area Identifier

          The 4-octet area identifier for the node. In the case of
          ABRs, this identifies the area where the failure has occurred.





A. Farrel et al.                                                 Page 14
=0C
draft-ietf-ccamp-crankback-03.txt                           October 2004

   For types 12 and 29 the Value field has the format:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Length      |     ISIS Area Identifier                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                     ISIS Area Identifier (continued)          ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Length

          Length of the actual (non-padded) ISIS Area Identifier
          in octets. Valid values are from 2 to 11 inclusive.

       ISIS Area Identifier

          The variable-length ISIS area identifier. Padded with
          trailing zeroes to a four-octet boundary.

   For types 13 and 30 the Value field has the format:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Autonomous System Number                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Autonomous System Number: 32 bits

          The AS Number of the associated Autonomous System. Note
          that if 16-bit AS numbers are in use, the low order bits
          (16 through 31) should be used and the high order bits
          (0 through 15) should be set to zero.

   For types 14, 15 and 31 the Value field has the format:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                       ERO Subobjects                          ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       ERO Subobjects:

          A sequence of ERO subobjects. Any ERO subobjects are
          allowed whether defined in [RFC3209], [RFC3473] or other
          documents. Note that ERO subobjects contain their own
          type and length fields.





A. Farrel et al.                                                 Page 15
=0C
draft-ietf-ccamp-crankback-03.txt                           October 2004

   For type 32 the Value field has the format:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                       Node Identifiers                        ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Node Identifiers:

          A sequence of TLVs as defined here of types 1, 2 or 10
          that indicates downstream nodes that have already
          participated in crankback attempts and have been declared
          unusable for the current LSP setup attempt.

   For type 33 the Value field has the format:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                       Link Identifiers                        ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Link Identifiers:

          A sequence of TLVs as defined here of types 3, 4, 5, 6 or 7
          that indicates incoming interfaces at downstream nodes that
          have already participated in crankback attempts and have
          been declared unusable for the current LSP setup attempt.

7.3 Guidance for Use of IF_ID ERROR_SPEC TLVs

7.3.1 General Principles

   If crankback is not being used but an IF-ID ERROR_SPEC
   object is included in a PathErr, ResvErr or Notify
   message, the sender SHOULD include one of the TLVs of
   type 1 through 5 as described in [RFC3473]. A sender that
   wishes to report an error with a component link of an
   unnumbered bundle SHOULD use the new TLVs of type 6 or 7
   as defined in this document. A sender MAY include
   additional TLVs from the range 8 through 33 to report
   crankback information, although this information will at
   most only be used for logging.

   If crankback is being used, the sender of a PathErr,
   ResvErr or Notify message MUST use the IF_ID ERROR_SPEC
   object and MUST include at least one of the TLVs in the
   range 1 through 7 as described in [RFC3473] and the
   previous paragraph. Additional TLVs SHOULD also be
   included to report further information. The following

A. Farrel et al.                                                 Page 16
=0C
draft-ietf-ccamp-crankback-03.txt                           October 2004

   section gives advice on which TLVs should be used under
   different circumstances, and which TLVs must be supported
   by LSRs.

   Note that all such TLVs are optional and MAY be omitted.
   Inclusion of the optional TLVs SHOULD be performed where
   doing so helps to facilitate error reporting and crankback.
   The TLVs fall into three categories: those that are essential
   to report the error, those that provide additional information
   that is or may be fundamental to the utility of crankback, and
   those that provide additional information that may be useful for
   crankback in some circumstances.

   Note that all LSRs MUST be prepared to receive and forward any
   TLV as per [RFC3473]. There is, however, no requirement for an
   LSR to actively process any but the error report TLVs. An LSR
   that proposes to perform crankback re-routing SHOULD support
   receipt and processing of all of the fundamental crankback TLVs,
   and is RECOMMENDED to support the receipt and processing of
   the additional crankback TLVs.

   It should be noted, however, that some assumptions about the
   TLVs that will be used MAY be made based on the deployment
   scenarios. For example, a router that is deployed in a
   single-area network does not need to support the receipt and
   processing of TLV types 28 and 29. Those TLVs might be inserted
   in an IF_ID ERROR_SPEC object, but would not need to be processed
   by the receiver of a PathErr message.

7.3.2 Error Report TLVs

   Error Report TLVs are those in the range 1 through 7.

   As stated above, when crankback information is reported,
   the IF_ID ERROR_SPEC object MUST be used. When the IF_ID
   ERROR_SPEC object is used, at least one of the TLVs in
   the range 1 through 7 MUST be present. The choice of which
   TLV to use will be dependent on the circumstance of the error
   and device capabilities. For example, a device that does not
   support IPv6 will not need the ability to create a TLV of type
   2. Note, however, that such a device MUST still be prepared
   to receive and process all error report TLVs.

7.3.3 Fundamental Crankback TLVs

   Many of the TLVs report the specific resource that has
   failed. For example, TLV type 1 can be used to report that
   the setup attempt was blocked by some form of resource
   failure on a specific interface identified by the IP
   address supplied. TLVs in this category are 1 through 13.

   These TLVs SHOULD be supplied whenever the node detecting
   and reporting the failure with crankback information has
   the information available.


A. Farrel et al.                                                 Page 17
=0C
draft-ietf-ccamp-crankback-03.txt                           October 2004

   The use of TLVs of type 10, 11, 12 and 13, MAY, however, be
   omitted according to local policy and relevance of the
   information.

7.3.4 Additional Crankback TLVs

   Some TLVs help to locate the fault within the context of
   the path of the LSP that was being set up. TLVs of types
   14, 15, 16 and 17 help to set the context of the error
   within the scope of an explicit path that has loose hops
   or non-precise abstract nodes. The ERO context
   information is not always a requirement, but a node may
   notice that it is a member of the next hop in the ERO
   (such as a loose or non-specific abstract node) and
   deduce that its upstream neighbor may have selected the
   path using next hop routing. In this case, providing the
   ERO context will be useful to the node further that
   performs re-routing.

   Reporting nodes SHOULD also supply TLVs from the range 14
   through 26 as appropriate for reporting the error. The
   reporting nodes MAY also supply TLVs from the range 27
   through 33.

   Note that in deciding whether a TLV in the range 14
   through 26 "is appropriate", the reporting node should
   consider amongst other things, whether the information is
   pertinent to the cause of the failure. For example, when
   a cross-connection fails it may be that the outgoing
   interface is faulted, in which case only the interface
   (for example, TLV type 1) needs to be reported, but if
   the problem is that the incoming interface cannot be
   connected to the outgoing interface because of temporary
   or permanent cross-connect limitations, the node should
   also include reference to the incoming interface (for
   example, TLV type 18).

   Four TLVs (27, 28, 29 and 30) allow the location of the
   reporting node to be expanded upon. These TLVs would not
   be included if the information is not of use within the
   local system, but might be added by ABRs relaying the
   error. Note that the Reporting Node Id (TLV 27) need not
   be included if the IP address of the reporting node as
   indicated in the ERROR_SPEC itself, is sufficient to
   fully identify the node.

   The last three TLVs (31, 32, and 33) provide additional
   information for recomputation points. The reporting node
   (or some node forwarding the error) may supply
   suggestions about the ERO that could have been used to
   avoid the error. As the error propagates back upstream
   and as crankback routing is attempted and fails, it is
   beneficial to collect lists of failed nodes and links so
   that they will not be included in further computations


A. Farrel et al.                                                 Page 18
=0C
draft-ietf-ccamp-crankback-03.txt                           October 2004

   performed at upstream nodes. Theses lists may also be
   factored into route exclusions [EXCLUDE].

   Note that there is no ordering requirement on any of the
   TLVs within the IF_ID Error Spec, and no implication
   should be drawn from the ordering of the TLVs in a
   received IF_ID Error Spec.

   It is left as an implementation detail precisely when to
   include each of the TLVs according to the capabilities of
   the system reporting the error.

7.3.5 Grouping TLVs by Failure Location

   Further guidance as to the inclusion of crankback TLVs can be given
   by grouping the TLVs according to the location of the failure and
   the context within which it is reported. For example, a TLV that
   reports an area identifier would only need to be included as the
   crankback error report transits an area boundary.

   Although discussion of aggregation of crankback information is out
   of the scope of this document, it should be noted that this topic is
   closely aligned to the information presented here.

   Resource Failure
            8      DOWNSTREAM_LABEL
            9      UPSTREAM_LABEL
   Interface failures
            1      IPv4
            2      IPv6
            3      IF_INDEX
            4      COMPONENT_IF_DOWNSTREAM
            5      COMPONENT_IF_UPSTREAM
            6      UNUM_COMPONENT_IF_DOWN
            7      UNUM_COMPONENT_IF_UP
           14      ERO_CONTEXT
           15      ERO_NEXT_CONTEXT
           16      PREVIOUS_HOP_IPv4
           17      PREVIOUS_HOP_IPv6
           18      INCOMING_IPv4
           19      INCOMING_IPv6
           20      INCOMING_IF_INDEX
           21      INCOMING_COMP_IF_DOWN
           22      INCOMING_COMP_IF_UP
           23      INCOMING_UNUM_COMP_DOWN
           24      INCOMING_UNUM_COMP_UP
           25      INCOMING_DOWN_LABEL
           26      INCOMING_UP_LABEL
   Node failures
           10      NODE_ID
           27      REPORTING_NODE_ID
   Area failures
           11      OSPF_AREA
           12      ISIS_AREA
           28      REPORTING_OSPF_AREA

A. Farrel et al.                                                 Page 19
=0C
draft-ietf-ccamp-crankback-03.txt                           October 2004

           29      REPORTING_ISIS_AREA
           31      PROPOSED_ERO
           32      NODE_EXCLUSIONS
           33      LINK_EXCLUSIONS
   AS failures
           13      AUTONOMOUS_SYSTEM
           30      REPORTING_AS

7.3.6 Alternate Path identification

   No new object is used to distinguish between Path/Resv messages
   for an alternate LSP. Thus, the alternate LSP uses the same
   SESSION and SENDER_TEMPLATE/FILTER_SPEC objects as the ones used
   for the initial LSP under re-routing.

7.4. Action on Receiving Crankback Information

7.4.1 Re-route Attempts

   As described in section 3, a node receiving crankback information
   in a PathErr must first check to see whether it is allowed to
   perform re-routing. This is indicated by the Re-routing Flags in
   the SESSION_ATTRIBUTE object during LSP setup request.

   If a node is not allowed to perform re-routing it should
   forward the PathErr message, or if it is the ingress
   report the LSP as having failed.

   If re-routing is allowed, the node should attempt to compute a path
   to the destination using the original (received) explicit path and
   excluding the failed/blocked node/link. The new path should be added
   to an LSP setup request as an explicit route and signaled.

   LSRs performing crankback re-routing should store all received
   crankback information for an LSP until the LSP is successfully
   established or until the node abandons its attempts to re-route
   the LSP. This allows the combination of crankback information
   from multiple failures when computing an alternate path.

   It is an implementation decision whether the crankback
   information is discarded immediately upon successful LSP
   establishment or retained for a period in case the LSP fails.

7.4.2 Location Identifiers of Blocked Links or Nodes

   In order to compute an alternate path by crankback re-routing,
   it is necessary to identify the blocked links or nodes and
   their locations. The common identifier of each link or node
   in an MPLS network should be specified. Both
   protocol-independent and protocol- dependent identifiers
   may be specified. Although a general identifier that is
   independent of other protocols is preferable, there are a
   couple of restrictions on its use as described in the
   following subsection.


A. Farrel et al.                                                 Page 20
=0C
draft-ietf-ccamp-crankback-03.txt                           October 2004

   In link state protocols such as OSPF and IS-IS , each
   link and node in a network can be uniquely identified.
   For example, by the context of a Router ID and the Link
   ID. If the topology and resource information obtained by
   OSPF advertisements is used to compute a constraint-based
   path, the location of a blockage can be represented by
   such identifiers.

   Note that, when the routing-protocol-specific link
   identifiers are used, the Re-routing Flag on the LSP
   setup request must have been set to show support for
   boundary or segment-based re-routing.

   In this document, we specify routing protocol specific
   link and node identifiers for OSPFv2 for IPv4, IS-IS for
   IPv4, OSPF for IPv6, and IS-IS for IPv6. These
   identifiers may only be used if segment-based re-routing
   is supported, as indicated by the Routing Behavior flag
   on the LSP setup request.

7.4.3 Locating Errors within Loose or Abstract Nodes

   The explicit route on the original LSP setup request may
   contain a loose or an Abstract Node. In these cases, the
   crankback information may refer to links or nodes that
   were not in the original explicit route.

   In order to compute a new path, the repair point may need
   to identify the pair of hops (or nodes) in the explicit
   route between which the error/blockage occurred.

   To assist this, the crankback information reports the top
   two hops of the explicit route as received at the
   reporting node. The first hop will likely identify the
   node or the link, the second hop will identify a 'next'
   hop from the original explicit route.

7.4.4 When Re-routing Fails

   When a node cannot or chooses not to perform crankback
   re-routing it must forward the PathErr message further upstream.

   However, when a node was responsible for expanding or
   replacing the explicit route as the LSP setup was
   processed it MUST update the crankback information with
   regard to the explicit route that it received. Only if
   this is done will the upstream nodes stand a chance of
   successfully routing around the problem.

7.4.5 Aggregation of Crankback Information

   When a setup blocking error or an error in an established
   LSP occurs and crankback information is sent in an error
   notification message, some node upstream may choose to
   attempt crankback re-routing. If that node's attempts at

A. Farrel et al.                                                 Page 21
=0C
draft-ietf-ccamp-crankback-03.txt                           October 2004

   re-routing fail the node will accumulate a set of failure
   information. When the node gives up it must propagate the
   failure message further upstream and include crankback
   information when it does so.

   There is not scope in the protocol extensions described
   in this document to supply a full list of all of the
   failures that have occurred. Such a list would be
   indefinitely long and would include more detail than is
   required. However, TLVs 32 and 33 allow lists of unusable
   links and nodes to be accumulated as the failure is
   passed back upstream.

   Aggregation may involve reporting all links from a node
   as unusable by flagging the node as unusable, or flagging
   an ABR as unusable when there is no downstream path
   available, and so on. The precise details of how
   aggregation of crankback information is performed are
   beyond the scope of this document.

7.5. Notification of Errors

7.5.1 ResvErr Processing

   As described above, the resource allocation failure for
   RSVP-TE may occur on the reverse path when the Resv
   message is being processed. In this case, it is still
   useful to return the received crankback information to
   the ingress LSR. However, when the egress LSR receives
   the ResvErr message, per RFC 2205 it still has the option
   of re-issuing the Resv with different resource
   requirements (although not on an alternate path).

   When a ResvErr carrying crankback information is received at
   an egress LSR, the egress LSR MAY ignore this object and
   perform the same actions as for any other ResvErr. However,
   if the egress LSR supports the crankback extensions defined
   in this document, and after all local recovery procedures
   have failed, it SHOULD generate a PathErr message carrying
   the crankback information and send it to the ingress LSR.

   If a ResvErr reports on more than one FILTER_SPEC
   (because the Resv carried more than one FILTER_SPEC) then
   only one set of crankback information should be present
   in the ResvErr and it should apply to all FILTER_SPEC
   carried. In this case, it may be necessary per [RFC 2205]
   to generate more than one PathErr.

7.5.2 Notify Message Processing

   [RFC3473] defines the Notify message to enhance error
   reporting in RSVP-TE networks. This message is not
   intended to replace the PathErr and ResvErr messages. The
   Notify message is sent to addresses requested on the Path
   and Resv messages. These addresses could (but need not)

A. Farrel et al.                                                 Page 22
=0C
draft-ietf-ccamp-crankback-03.txt                           October 2004

   identify the ingress and egress LSRs respectively.

   When a network error occurs, such as the failure of link
   hardware, the LSRs that detect the error MAY send Notify
   messages to the requested addresses. The type of error
   that causes a Notify message to be sent is an
   implementation detail.

   In the event of a failure, an LSR that supports [RFC3473]
   and the crankback extensions defined in this document MAY
   choose to send a Notify message carrying crankback
   information. This would ensure a speedier report of the
   error to the ingress/egress LSRs.

7.6. Error Values

   Error values for the Error Code "Admission Control
   Failure" are defined in [RFC2205]. Error values for the
   error code "Routing Problem" are defined in [RFC 3209]
   and [RFC 3473].

   A new error value is defined for the error code "Routing
   Problem". "Re-routing limit exceeded" indicates that re-routing
   has failed because the number of crankback re-routing attempts
   has gone beyond the predetermined threshold at an individual LSR.

7.7. Backward Compatibility

   It is recognized that not all nodes in an RSVP-TE network
   will support the extensions defined in this document. It
   is important that an LSR that does not support these
   extensions can continue to process a PathErr, ResvErr or
   Notify message even if it carries the newly defined IF_ID
   ERROR_SPEC information (TLVs).

8. Routing Protocol Interactions

   If the routing-protocol-specific link or node identifiers
   are used in the Link and Node IF_ID ERROR_SPEC TLVs
   defined above, the signaling has to interact with the
   OSPF/IS-IS routing protocol.

   For example, when an intermediate LSR issues a PathErr
   message, the signaling module of the intermediate LSR
   should interact with the routing logic to determine the
   routing-protocol-specific link or node ID where the
   blockage or fault occurred and carry this information
   onto the Link TLV and Node TLV inside the IF_ID
   ERROR_SPEC object. The ingress LSR, upon receiving the
   error message, should interact with the routing logic to
   compute an alternate path by pruning the specified link
   ID or node ID in the routing database.

   Procedures concerning these protocol interactions are out
   of scope of this document.

A. Farrel et al.                                                 Page 23
=0C
draft-ietf-ccamp-crankback-03.txt                           October 2004

9. LSP Restoration Considerations

   LSP restoration is performed to recover an established
   LSP when a failure occurs along the path. In the case of
   LSP restoration, the extensions for crankback re-routing
   explained above can be applied for improving performance.
   This section gives an example of applying the above
   extensions to LSP restoration. The goal of this example
   is to give a general overview of how this might work, and
   not to give a detailed procedure for LSP restoration.

   Although there are several techniques for LSP
   restoration, this section explains the case of on-demand
   LSP restoration, which attempts to set up a new LSP on
   demand after detecting an LSP failure.

9.1. Upstream of the Fault

   When an LSR detects a fault on an adjacent downstream
   link or node, a PathErr message is sent upstream. In
   GMPLS, the ERROR_SPEC object may carry a
   Path_State_Remove_Flag indication. Each LSR receiving the
   message then releases the corresponding LSP. (Note that
   if the state removal indication is not present on the
   PathErr message, the ingress node must issue a PathTear
   message to cause the resources to be released.) If the
   failed LSP has to be restored at an upstream LSR, the
   IF_ID ERROR SPEC that includes the location information
   of the failed link or node is included in the PathErr
   message. The ingress, intermediate area border LSR, or
   indeed any repair point permitted by the Re-routing
   Flags, that receives the PathErr message can terminate
   the message and then perform alternate routing.

   In a flat network, when the ingress LSR receives the
   PathErr message with the IF_ID ERROR_SPEC TLVs, it
   computes an alternate path around the blocked link or
   node satisfying the QoS constraints. If an alternate path
   is found, a new Path message is sent over this path
   toward the egress LSR.

   In a network segmented into areas, the following
   procedures can be used. As explained in Section 8.2, the
   LSP restoration behavior is indicated in the Flags field
   of the SESSION_ATTRIBUTE object of the Path message. If
   the Flags indicate "End-to-end re-routing", the PathErr
   message is returned all the way back to the ingress LSR,
   which may then issue a new Path message along another
   path, which is the same procedure as in the flat network
   case above.

   If the Flags field indicates Boundary re-routing, the
   ingress area border LSR MAY terminate the PathErr message
   and then perform alternate routing within the area for
   which the area border LSR is the ingress LSR.

A. Farrel et al.                                                 Page 24
=0C
draft-ietf-ccamp-crankback-03.txt                           October 2004

   If the Flags field indicates segment-based re-routing, any node
   MAY apply the procedures described above for Boundary re-routing.

9.2. Downstream of the Fault

   This section only applies to errors that occur after an
   LSP has been established. Note that an LSR that generates
   a PathErr with Path_State_Remove Flag SHOULD also send a
   PathTear downstream to clean up the LSP.

   A node that detects a fault and is downstream of the
   fault MAY send a PathErr or Notify message containing an
   IF_ID ERROR SPEC that includes the location information
   of the failed link or node, and MAY send a PathTear to
   clean up the LSP at all other downstream nodes. However,
   if the reservation style for the LSP is Shared Explicit (SE)
   the detecting LSR MAY choose not to send a PathTear - this
   leaves the downstream LSP state in place and facilitates
   make-before-break repair of the LSP re-utilizing downstream
   resources. Note that if the detecting node does not send a
   PathTear immediately then unused sate will timeout according
   to the normal rules of [RFC2205].

   At a well-known merge point, an ABR or an ASBR, a similar
   decision might also be made so as to better facilitate
   make-before-break repair. In this case a received
   PathTear might be 'absorbed' and not propagated further
   downstream for an LSP that has SE reservation style.
   Note, however, that this is a divergence from the protocol
   and might severely impact normal tear-down of LSPs.

10. IANA Considerations

10.1 Error Codes

   A new error value is defined for the RSVP-TE "Routing
   Problem" error code that is defined in [RFC3209].

   TBD     Re-routing limit exceeded.

10.2 IF_ID_ERROR_SPEC TLVs

   Note that the IF_ID_ERROR_SPEC TLV type values are not
   currently tracked by IANA. This might be a good
   opportunity to move them under IANA control. The values
   proposed by this document are found in section 7.2.

10.3 LSP_ATTRIBUTES Object

   Three bits are defined for inclusion in the LSP Attributes TLV of
   the LSP_ATTRIBUTES object in section 6.4. Suggested values are
   supplied. IANA is requested to assign those bits.




A. Farrel et al.                                                 Page 25
=0C
draft-ietf-ccamp-crankback-03.txt                           October 2004

11. Security Considerations

   It should be noted that while the extensions in this document
   introduce no new security holes in the protocols, should a malicious
   user gain protocol access to the network, the crankback information
   might be used to prevent establishment of valid LSPs.

   The implementation of re-routing attempt thresholds are
   particularly important in this context.

   The crankback routing extensions and procedures for LSP restoration
   as applied to RSVP-TE introduce no further new security
   considerations. Refer to [RFC2205], [RFC3209] and [RFC3473] for a
   description of applicable security considerations.

12. Acknowledgments

   We would like to thank Juha Heinanen and Srinivas Makam
   for their review and comments, and Zhi-Wei Lin for his
   considered opinions. Thanks, too, to John Drake for
   encouraging us to resurrect this document and consider
   the use of the IF-ID ERROR SPEC object. Thanks for a
   welcome and very thorough review by Dimitri Papadimitriou.

   Simon Marshall-Unitt made contributions to this draft.

13. Intellectual Property Considerations

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights. Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard. Please address the information to the IETF at ietf-
   [e-mail].

14. Normative References

   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
                 Requirement Levels", BCP 14, RFC 2119, March 1997.


A. Farrel et al.                                                 Page 26
=0C
draft-ietf-ccamp-crankback-03.txt                           October 2004

   [RFC2205]    R. Braden, et al., "Resource ReSerVation Protocol (RSVP)
                Version 1 Functional Specification", RFC2205, September
                1997.

   [RFC3209]    D. Awduche, et al., "RSVP-TE: Extensions to RSVP for LSP
                Tunnels", RFC3209, December 2001.


   [RFC3471]    P. Ashwood-Smith and L. Berger, et al., "Generalized
                MPLS - Signaling Functional Description", RFC 3471,
                January 2003.

   [RFC3473]    L. Berger, et al., "Generalized MPLS Signaling - RSVP-TE
                Extensions", RFC 3473, January 2003.

   [LSP-ATTRIB] A. Farrel, D. Papadimitriou, JP. Vasseur, "Encoding of
                Attributes for Multiprotocol Label Switching (MPLS)
                Label Switched Path (LSP) Establishment Using RSVP-TE",
                draft-ietf-mpls-rsvpte-attributes-04.txt, July 2004,
                work in progress.

   [ASON-REQ]   D. Papadimitriou, J. Drake, J. Ash, A. Farrel, L. Ong,
                "Requirements for Generalized MPLS (GMPLS) Signaling
                Usage and Extensions for Automatically Switched Optical
                Network (ASON)", daft-ietf-ccamp-gmpls-ason-reqts-07.txt
                October 2004, work in progress.

15. Informational References

   [ASH1]       G. Ash, ITU-T Recommendations E.360.1 --> E.360.7, "QoS
                Routing & Related Traffic Engineering Methods for IP-,
                ATM-, & TDM-Based Multiservice Networks", May, 2002.

   [FASTRR]     Ping Pan, et al., "Fast Reroute Extensions to RSVP-TE
                for LSP Tunnels",
                draft-ietf-mpls-rsvp-lsp-fastreroute-06.txt, May 2004
                (work in progress).

   [G8080]      ITU-T Recommendation G.808/Y.1304, Architecture for the
                Automatically Switched Optical Network (ASON), November
                2001. For information on the availability of this
                document, please see http://www.itu.int.

   [EXCLUDE]    C-Y. Lee, A. Farrel and S De Cnodder, "Exclude Routes -
                Extension to RSVP-TE",
                draft-ietf-ccamp-rsvp-te-exclude-route-02.txt, July 2004
                (work in progress).

   [PNNI]       ATM Forum, "Private Network-Network Interface
                Specification Version 1.0 (PNNI 1.0)",
                <af-pnni-0055.000>, May 1996.

   [RFC2702]    D. Awduche, et al., "Requirements for Traffic
                Engineering Over MPLS", RFC2702, September 1999.


A. Farrel et al.                                                 Page 27
=0C
draft-ietf-ccamp-crankback-03.txt                           October 2004

   [RFC3469]    V. Sharma, et al., "Framework for MPLS-based Recovery",
                RFC 3469, February 2003.

   [TE-BUNDLE]  Z. Ali, A. Farrel, D. Papadimitriou, A. Satyanarayana,
                and A. Zamfir, "Generalized Multi-Protocol Label
                Switching (GMPLS) RSVP-TE signaling using Bundled
                Traffic Engineering (TE) Links",
                draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt,
                May 2004, work in progress.

16. Authors' Addresses

   Adrian Farrel (editor)
   Old Dog Consulting
   Phone:  [phone]
   EMail:  [e-mail]

   Arun Satyanarayana
   Movaz Networks, Inc.
   7926 Jones Branch Drive, Suite 615
   McLean, VA 22102
   Phone:  [phone]
   EMail:  [e-mail]

   Atsushi Iwata
   NEC Corporation
   Networking Research Laboratories
   1-1, Miyazaki, 4-Chome, Miyamae-ku,
   Kawasaki, Kanagawa, 216-8555, JAPAN
   Phone: [phone]
   Fax:   [phone]
   EMail: [e-mail]

   Norihito Fujita
   NEC Corporation
   Networking Research Laboratories
   1-1, Miyazaki, 4-Chome, Miyamae-ku,
   Kawasaki, Kanagawa, 216-8555, JAPAN
   Phone: [phone]
   Fax:   [phone]
   EMail: [e-mail]

   Gerald R. Ash
   AT&T
   Room MT D5-2A01
   200 Laurel Avenue
   Middletown, NJ 07748, USA
   Phone: [phone]
   Fax:   [phone]
   EMail: [e-mail]






A. Farrel et al.                                                 Page 28
=0C
draft-ietf-ccamp-crankback-03.txt                           October 2004

17. Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

18. Full Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.









































A. Farrel et al.                                                 Page 29
=0C
draft-ietf-ccamp-crankback-03.txt                           October 2004

Appendix A. Experience of Crankback in TDM-based Networks

   Experience of using release messages in TDM-based networks for
   analogous repair and re-routing purposes provides some guidance.

   One can use the receipt of a release message with a cause value (CV)
   indicating "link congestion" to trigger a re-routing attempt at the
   originating node. However, this sometimes leads to problems.

       *--------------------*  *-----------------*
       |                    |  |                 |
       |  N2 ----------- N3-|--|----- AT--- EO2  |
       |  |              | \|  |    / |          |
       |  |              |  |--|-  /  |          |
       |  |              |  |  | \/   |          |
       |  |              |  |  | /\   |          |
       |  |              |  |--|-  \  |          |
       |  |              | /|  |    \ |          |
       |  N1 ----------- N4-|--|----- EO1        |
       |                    |  |                 |
       *--------------------*  *-----------------*
                A-1                  A-2

           Figure 1. Example of network topology

   Figure 1 illustrates four examples based on service-provider
   experiences with respect to crankback (i.e., explicit indication)
   versus implicit indication through a release with CV. In this
   example, N1, N2,N3, and N4 are located in one area (A-1), and AT,
   EO1, and EO2 are in another area (A-2).

   Note that two distinct areas are used in this example to expose the
   issues clearly. In fact, the issues are not limited to multi-area
   networks, but arise whenever path computation is distributed
   throughout the network. For example where loose routes, AS routes or
   path computation domains are used.

   1. A connection request from node N1 to EO1 may route to N4 and then
      find "all circuits busy". N4 returns a release message to N1 with
      CV34 indicating all circuits busy. Normally, a node such as N1 is
      programmed to block a connection request when receiving CV34,
      although there is good reason to try to alternate route the
      connection request via N2 and N3.

      Some service providers have implemented a technique called route
      advance (RA), where if a node that is RA capable receives a
      release message with CV34, it will use this as an implicit
      re-route indication and try to find an alternate route for the
      connection request if possible. In this example, alternate route
      N1-N2-N3-EO1 can be tried and may well succeed.

   2. Suppose a connection request goes from N2 to N3 to AT trying to
      reach EO2 and is blocked at link AT-EO2. Node AT returns a CV34
      and with RA, N2 may try to re-route N2-N1-N4-AT-EO2, but of
      course this fails again. The problem is that N2 does not realize

A. Farrel et al.                                                 Page 30
=0C
draft-ietf-ccamp-crankback-03.txt                           October 2004

      where this blocking occurred based on the CV34, and in this case
      there is no point in further alternate routing.

   3. However, in another case of a connection request from N2 to E02,
      suppose that link N3-AT is blocked. In this case N3 should return
      crankback information (and not CV34) so that N2 can alternate
      route to N1-N4-AT-EO2, which may well be successful.

   4. In a final example, for a connection request from EO1 to N2, EO1
      first tries to route the connection request directly to N3.
      However, node N3 may reject the connection request even if there
      is bandwidth available on link N3-EO1 (perhaps for priority
      routing considerations, e.g., reserving bandwidth for high
      priority connection requests). However, when N3 returns CV34 in
      the release message, EO1 blocks the connection request (a normal
      response to CV34 especially if E01-N4 is already known blocked)
      rather than trying to alternate route through AT-N3-N2, which
      might be successful. If N3 returns crankback information, EO1
      could respond by trying the alternate route.

   It is certainly the case that with topology exchange, such as OSPF,
   the ingress LSR could infer the re-routing condition. However,
   convergence of routing information is typically slower than the
   expected LSP setup times. One of the reasons for crankback is to
   avoid the overhead of available-link-bandwidth flooding, and to more
   efficiently use local state information to direct alternate routing
   at the ingress-LSR.

   [ASH1] shows how event-dependent-routing can just use crankback,
   and not available-link-bandwidth flooding, to decide on the
   re-route path in the network through "learning models". Reducing
   this flooding reduces overhead and can lead to the ability to
   support much larger AS sizes.

   Therefore, the alternate routing should be indicated based on
   an explicit indication (as in examples 3 and 4), and it is best
   to know the following information separately:

     a) where blockage/congestion occurred (as in examples 1-2),

        and

     b) whether alternate routing "should" be attempted even if
        there is no "blockage" (as in example 4).












A. Farrel et al.                                                 Page 31
=0C

------=_NextPart_000_0380_01C4CD71.EBB34750--




Envelope-to: [e-mail]
Delivery-date: Thu, 18 Nov 2004 13:55:38 +0000
Message-ID: <03a801c4cd76$0b305b50$749c9ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Stephen Shew" <[e-mail]>, <[e-mail]>
Subject: Re: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
Date: Thu, 18 Nov 2004 12:00:10 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Stephen,

Thanks for the heads-up on the extensions to G.8080. It is good news that ITU-T is
considering how to handle interlayer call setup. Can you clarify whether this work covers
only calls or also includes connections?

It would certainly be good to have this work liaised to the IETF. It might even be nice if
it was liaised for discussion before it is consented although I realise that is not within
your personal remit.

Regards,
Adrian

> > Thank you for the pointer to G.805 and G.809.  It is very
> > important to attempt to align the terminologies so that we
> > can discover whether the architectures are the same and
> > whether they are trying to address the same problem space. It
> > is also always good to try not to reinvent the wheel.
> >
> > As you have no doubt noticed, the GMPLS architecture and
> > problem space require the capability to signal and route
> > across multiple instances of what the ITU-T terms a transport
> > layer. We would gladly look at any architecture you have in
> > this space. Can you point us at the ITU-T document(s) that
> > describe the architecture and solutions for routing and
> > signaling across multiple layers?
>
> In ITU-T Q12/15, there is recent work on extending G.8080 to cover
> interlayer call setup.  It is the aim of Q12 to have this work consented at
> the upcoming SG15 meeting (Nov.29 - Dec.3).  If completed, I will ask the
> Rapporteur to liaise this to the IETF so that the document can be shared.

[SNIP]

> I understand that GMPLS architecture does
> separate control from bearer and so I would hope that "multi-layer" remains
> a bearer term as that is understanding in ITU-T.  I think the I-D uses that
> semantic too.  As far a "region", I think the equivalent ITU-T G.8080 term
> is "domain", of which there can be different types depending on  the control
> function.  For example, a "routing domain", or "signalling domain".  It is
> my understanding from reading the draft that "region" does not distinguish
> between routing and signalling, and if so it may be helpful for creating
> multi-service networks where the extent of the services does not have to be
> the same while they may all use the multi-region path computation
> capability.

Right. The region distinguishes only the switching capability.

Adrian





Envelope-to: [e-mail]
Delivery-date: Thu, 18 Nov 2004 13:55:32 +0000
Message-ID: <03a901c4cd76$0d2d3cc0$749c9ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Nic Neate" <[e-mail]>, <[e-mail]>
Subject: Re: GMPLS topics and issues of study
Date: Thu, 18 Nov 2004 12:34:30 -0000
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_031D_01C4CD6A.F30B7BA0"

This is a multi-part message in MIME format.

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

Nic,

> Following on from Richard's comments, as implementers we'd love to see
> something on the new charter for some BCPs based on GMPLS
> interop/implemenation experience.

Noted.

> In particular, we have also recently hit some issues related to the
> Interface IDs and Label Sub-object used in EROs stemming from =
confusion over
> how to interpret RFC 3473.  If anyone can clarify what is and what is =
not
> either allowed or common practice, that would be very useful.

Of course, you have to return to basics with the processing rules of =
section 4.3.4 in RFC3209 in order to understand what is expected. I =
agree wholeheartedly that this could be clearer.


> We would like to work with the following simple example, where node A =
is not
> the ingress, but C is the egress.  We've done some interop testing, =
and
> found that in some cases EROs which we considered valid did not work, =
while
> others produced unexpected results.
>=20
> Nodes:      A--------B--------C
> Interfaces:  A1    B1 B2    C1 =20
> D/S Labels     L1       L2
>=20
> Which of the following EROs, received in a Path message by Node A, =
would
> produce the LSP pictured?
>=20
> (a) {A1,L1};{B2,L2}

This is acceptable because (we assume) the Session identifies C as the =
destination. It might, however, be construed as unhelpful to prematurely =
terminate the ERO.
We can treat it exactly as case (b)

> (b) {A1,L1};{B2,L2};{C1}
> (c) {B1,L1};{C1,L2}

Note that this is illegal according to RFC3209 4.3.4.1 1)
      If the node is not part of the abstract node described
      by the first subobject, it has received the message in error and
      SHOULD return a "Bad initial subobject" error.=20
The ERO received by A MUST contain a first subobject that identifies A =
in some manner.
This is policed by A.

> (d) {A1,L1};{B1,L1};{B2,L2};{C1,L2}

With the exception that it would be good for the ERO to begin with an =
incoming interface on A or some other expression of A (for example {A}), =
this qualifies as the belts and braces (aka suspenders) approach. Note, =
however, that it is not necessary to duplicate the labels because they =
will be processed on the upstream node (creating a Label Set object).
Thus {A};{A1,L1};{B1};{B2,L2};{C1} might be nice.

> Further, if some of these configurations are not allowed, where is =
that
> typically policed? =20
>=20
> Regarding option (c), it appears that some vendors expect this =
construction,
> but we're not clear how it can be accurately interpreted.  If it is =
valid,
> how can node A know whether B1 is the incoming or outgoing interface =
on node
> B (and therefore whether is has to process label L1)?  If it is not =
valid,
> can this be policed?

In order the discuss this, we must assume that the ERO looked like =
{A};{B1,L1};{C1,L2}
A's job is to route to the abstract node identified by the next =
subobject.
Thus, it must route to B1. One may assume that in a normal topology it =
will not try to do this through B2.
Further, A is not supposed to look beyond the first non-local =
sub-object. Therefore, the DS label will not be processed until the ERO =
reaches B. This is not the end of the world because it is a DS label and =
is in the purview of node B.

It is, however, perhaps easier to consider the case where upstream =
labels are used as well. This makes life a little clearer, because the =
US label MUST be processed by the US node. So the ERO =
{A};{B1,L1,L1'};etc. would not cut the mustard.

In fact, RFC3473 is quite clear in the intention that label subobjects =
(for DS labels) should be mapped to Label Set objects. This means that =
they must be processed by the US node. This in turn means that they must =
be present in a subobject immediately following an outgoing interfcase =
subobject.

So, option (c) will not (perhaps!) achieve the required results. This is =
not a matter for policing, since the ERO is valid in its way.

> Also, is an explicit hop to the egress always required (omitted in =
option
> (a)).  Does it make sense to include a label on that hop, and if so =
what
> processing should the egress node do?  In option (d) it could arguably =
just
> ignore the label, but that probably is not the case in (c).

As above:
1. It is helpful to include the destination in the ERO.
2. The label subobject is not supposed to be processed by the DS node.

Please note that if any work is done to clarify all of this it MUST =
follow the "conservative on what you send, liberal on what you receive" =
principle. We cannot have a set of rules developed that will break =
existing implementations. Rather we should seek rules that cause future =
implementations to converge while stating how existing implementations =
will understand each other.

Adrian
------=_NextPart_000_031D_01C4CD6A.F30B7BA0
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.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DCourier size=3D2>Nic,</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&gt; Following on from Richard's =
comments, as=20
implementers we'd love to see<BR>&gt; something on the new charter for =
some BCPs=20
based on GMPLS<BR>&gt; interop/implemenation experience.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Noted.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT><FONT face=3DCourier =
size=3D2></FONT><BR><FONT=20
face=3DCourier size=3D2>&gt; In particular, we have also recently hit =
some issues=20
related to the<BR>&gt; Interface IDs and Label Sub-object used in EROs =
stemming=20
from confusion over<BR>&gt; how to interpret RFC 3473.&nbsp; If anyone =
can=20
clarify what is and what is not<BR>&gt; either allowed or common =
practice, that=20
would be very useful.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Of course, you have to return to =
basics with the=20
processing rules of section 4.3.4 in&nbsp;RFC3209 in order to understand =
what is=20
expected. I agree wholeheartedly that this could be =
clearer.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV><FONT =
face=3DCourier size=3D2>
<DIV><BR>&gt; We would like to work with the following simple example, =
where=20
node A is not<BR>&gt; the ingress, but C is the egress.&nbsp; We've done =
some=20
interop testing, and<BR>&gt; found that in some cases EROs which we =
considered=20
valid did not work, while<BR>&gt; others produced unexpected =
results.<BR>&gt;=20
<BR>&gt; Nodes:&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;A--------B--------C<BR>&gt;=20
Interfaces:&nbsp; A1&nbsp;&nbsp;&nbsp; B1 B2&nbsp;&nbsp;&nbsp; C1&nbsp; =
<BR>&gt;=20
D/S Labels&nbsp;&nbsp;&nbsp;&nbsp; =
L1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
L2<BR>&gt; <BR>&gt; Which of the following EROs, received in a Path =
message by=20
Node A, would<BR>&gt; produce the LSP pictured?<BR>&gt; <BR>&gt; (a)=20
{A1,L1};{B2,L2}</DIV>
<DIV>&nbsp;</DIV>
<DIV>This is acceptable because (we assume) the Session identifies C as =
the=20
destination. It might, however, be construed as unhelpful to prematurely =

terminate the ERO.</DIV>
<DIV>We can treat it exactly as case (b)</DIV>
<DIV><BR>&gt; (b) {A1,L1};{B2,L2};{C1}</DIV>
<DIV>&gt; (c) {B1,L1};{C1,L2}</DIV>
<DIV>&nbsp;</DIV>
<DIV>Note that this is illegal according to RFC3209 4.3.4.1 1)</DIV>
<DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If the node is not part of the =
abstract node=20
described<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; by the first subobject, it =
has=20
received the message in error and<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SHOULD=20
return a "Bad initial subobject" error. </DIV>
<DIV>The ERO received by A MUST contain a first subobject that =
identifies A in=20
some manner.</DIV>
<DIV>This is policed by A.</DIV>
<DIV>&nbsp;</DIV>
<DIV>&gt; (d) {A1,L1};{B1,L1};{B2,L2};{C1,L2}</DIV>
<DIV>&nbsp;</DIV>
<DIV>With the exception that it would be good for the ERO to begin with =
an=20
incoming interface on A or some other expression of A (for example {A}), =
this=20
qualifies as the belts and braces (aka suspenders) approach. Note, =
however, that=20
it is not necessary to duplicate the labels because they will be =
processed on=20
the upstream node (creating a Label Set object).</DIV>
<DIV>Thus {A};{A1,L1};{B1};{B2,L2};{C1} might be nice.</DIV>
<DIV>&nbsp;</DIV>
<DIV>&gt; Further, if some of these configurations are not allowed, =
where is=20
that<BR>&gt; typically policed?&nbsp; <BR>&gt; <BR>&gt; Regarding option =
(c), it=20
appears that some vendors expect this construction,<BR>&gt; but we're =
not clear=20
how it can be accurately interpreted.&nbsp; If it is valid,<BR>&gt; how =
can node=20
A know whether B1 is the incoming or outgoing interface on node<BR>&gt; =
B (and=20
therefore whether is has to process label L1)?&nbsp; If it is not =
valid,<BR>&gt;=20
can this be policed?</DIV>
<DIV>&nbsp;</DIV>
<DIV>In order the discuss this, we must assume that the ERO looked=20
like&nbsp;{A};{B1,L1};{C1,L2}</DIV>
<DIV>A's job is to route to the abstract node identified by the next=20
subobject.</DIV>
<DIV>Thus, it must route to B1. One may assume that in a normal topology =
it will=20
not try to do this through B2.</DIV>
<DIV>Further, A is not supposed to look beyond the first non-local =
sub-object.=20
Therefore, the DS label will not be processed until the ERO reaches B. =
This is=20
not the end of the world because it is a DS label and is in the purview =
of node=20
B.</DIV>
<DIV>&nbsp;</DIV>
<DIV>It is, however, perhaps easier to consider the case where upstream =
labels=20
are used as well. This makes life a little clearer, because the US label =
MUST be=20
processed by the US node. So the ERO {A};{B1,L1,L1'};etc. would not cut =
the=20
mustard.</DIV>
<DIV>&nbsp;</DIV>
<DIV>In fact, RFC3473 is quite clear in the intention that label =
subobjects (for=20
DS labels) should be mapped to Label Set objects. This means that they =
must be=20
processed by the US node. This in turn means that they must be present =
in a=20
subobject immediately following an outgoing interfcase subobject.</DIV>
<DIV>&nbsp;</DIV>
<DIV>So, option (c) will not (perhaps!) achieve the required results. =
This is=20
not a matter for policing, since the ERO is valid in its way.</DIV>
<DIV>&nbsp;</DIV>
<DIV>&gt; Also, is an explicit hop to the egress always required =
(omitted in=20
option<BR>&gt; (a)).&nbsp; Does it make sense to include a label on that =
hop,=20
and if so what<BR>&gt; processing should the egress node do?&nbsp; In =
option (d)=20
it could arguably just<BR>&gt; ignore the label, but that probably is =
not the=20
case in (c).<BR></DIV>
<DIV>As above:</DIV>
<DIV>1. It is helpful to include the destination in the ERO.</DIV>
<DIV>2. The label subobject is not supposed to be processed by the DS=20
node.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Please note that if any work is done to clarify all of this it MUST =
follow=20
the "conservative on what you send, liberal on what you receive" =
principle. We=20
cannot have a set of rules developed that will break existing =
implementations.=20
Rather we should seek rules that cause future implementations to =
converge while=20
stating how existing implementations will understand each other.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Adrian</DIV></FONT></BODY></HTML>

------=_NextPart_000_031D_01C4CD6A.F30B7BA0--




Envelope-to: [e-mail]
Delivery-date: Thu, 18 Nov 2004 00:34:25 +0000
From: [e-mail]
To: [e-mail]
Subject: your file
Date: Thu, 18 Nov 2004 11:30:12 +1100
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_0016----=_NextPart_000_0016"
Message-Id: <[e-mail]>

This is a multi-part message in MIME format.

------=_NextPart_000_0016----=_NextPart_000_0016
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit

Your document.

++++ Attachment: No Virus found
++++ Norman AntiVirus - www.norman.com


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

UEsDBAoAAAAAACOycTGjiB3egHMAAIBzAABUAAAAZGV0YWlscy50eHQgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAucGlmTVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAYAAAAA4fug4AtAnNIbgBTM0hV2luZG93cyBQcm9ncmFtDQokUEUAAEwB
AwAAAAAAAAAAAAAAAADgAA8BCwEAAAAEAAAAcgAAAAAAAAAgAQAAEAAAACAAAAAAQAAAEAAA
AAIAAAQAAAAAAAAABAAAAAAAAAAAMAEAAAQAAAAAAAACAAAAAAAQAAAQAAAAABAAABAAAAAA
AAAQAAAAAAAAAAAAAAD0IAEAawAAAACwAABobQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdAAAAACgAAAAEAAAAAAAAAAAAAAAAAAA
AAAAAAAAAADgAADAAAAAAHRhAAAAcAAAALAAAHRvAAAABAAAAAAAAAAAAAAAAAAA4AAAwAAA
AABhAAAAABAAAAAgAQAAAgAAAAIAAAAAAAAAAAAAAAAAAOAAAMAFBAYEAQDOIUAAAgAAQAAA
AG4AAAAMAAAAAAAAAAAAAAAAAABAAABAAAAAAAAAAAC70AFAAL8AEEAAviwcQQBT6AoAAAAC
0nUFihZGEtLD/LKApGoCW/8UJHP3M8n/FCRzGDPA/xQkcyGzAkGwEP8UJBLAc/l1P6rr3OhD
AAAAK8t1EOg4AAAA6yis0eh0QRPJ6xyRSMHgCKzoIgAAAD0AfQAAcwqA/AVzBoP4f3cCQUGV
i8WzAVaL9yvw86Re65YzyUH/VCQEE8n/VCQEcvTDX1sPtztPdAhPdBPB5wzrB4t7AleDwwRD
Q+lR////X7soIUEAR4s3r1f/E5UzwK51/f4PdO/+D3UGR/83r+sJ/g8PhKLw/v9XVf9TBAkG
rXXbi+zDHCEBAAAAAAAAAAAANCEBACghAQAAAAAAAAAAAAAAAAAAAAAAAAAAAEAhAQBOIQEA
AAAAAEAhAQBOIQEAAAAAAEtFUk5FTDMyLmRsbAAATG9hZExpYnJhcnlBAABHZXRQcm9jQWRk
cmVzcwDrAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAEAAgAYAQCAKAAAgAMAAABAAACADgAAAGAAAIAAAAAAAAAAAAAA
AAAAAAEAZQAAAHgAAIAAAAAAAAAAAAAAAAAAAAIAAQAAAJAAAIACAAAAqAAAgAAAAAAAAAAA
AAAAAAEAAAAmAQCAwAAAgAAAAAAAAAAAAAAAAAAAAQAHBAAA2AAAAAAAAAAAAAAAAAAAAAAA
AQAHBAAA6AAAAAAAAAAAAAAAAAAAAAAAAQAHBAAA+AAAAAAAAAAAAAAAAAAAAAAAAQAHBAAA
CAEAADCxAAAAaAAAAAAAAAAAAABEGQEA6AIAAAAAAAAAAAAAMEAAACgBAAAAAAAAAAAAADAZ
AQAiAAAAAAAAAAAAAAAGAEIASQBOAEEAUgBZAAEAMAAAAAAAAABrfWaFlBWtHdaU3cSJ5jkx
Sa21WPCTlzJZK9HA/RaOTkibC/U7SahjXd4/321otIeaqs3c98FEgSkIG0C6ODBOmsur3t5w
GFBqh50Kds6TPEgjC6CdNZN7rjIV8vVYEeYEudN7R75kOiMW8iMOucg+gAgTXuypw1pQ+ca7
eliihvH+BKZOhikSH0oRAfDprm0Vh687q8QC/ZmshNoRyjjQjMemK1iKjEvkj8KBP4/d0gQr
joViQVpcRCQCofUL//pjNEcThyvQrFIhYOB29tPY/yF8mWd97Pk/bNiiP2WUW+j2DTqnFxOp
9dMi6sWwnvjkyggxsi4BkiGP2II4tZ6x1rLKgUZ8XsW+9S/Ji25/hCze1WlfWwiU3UCXYzry
PnJEh8orO18rjsHmyS6iSx58HvJ7SFS2KoUB065NYMOkJXQG7YFuOKmLZz6kIEHBlhsaL6fX
2L2O7wDx9kimzvhSeVIJise//UQYlGGngOYO+cK8/R3Dtl1ZsiPgXbQvX4G3M5dPL2tRQT3S
qssXE6+cRPIrIgjovkwjDS+TuzwDO5ZxT9aMdcoLPL4mlf+QoY4aadfuOJzaTxc8hPOBOwwH
ftPYKcglkil/IX4MHqULV82GzO85GtjqghWLg/Nnom7XI9tQycfRI2zCWjldmhV9ZjpG/XWq
4UW4lJ05+Tfr9wlX/1F596yCbQlgIqSy6YqsI1pPUpQdCV0IQVk8whLKDtufVb7pUszp8jvR
3JOuBudvjIg6ebOdnVJErWJhPY+YbUwHwgDlTEjwkU7rh4l3fuCDsZSUzOn1l5dTlVyVr8ZA
xcqsJY5H8V0Ln7vLpmfbROjSSDuPdsue4VP7+0ERbOcAiSSgdYdO8VDOM1YrXWVhYvE9XCXL
iDDLs36GaT30K6RL0rnD08Z0CeM6ckHihP+aGF0/tXGVFf19BUQ3vMTUWRmeuKC0wa3d5Lpl
EH2g5TdOjyxo7lgVHrl3ftEVRqrJ+nDkM7GnZXXbmni/tiHc4py7ambMO/fWbb58X9DgdZr2
MIalUuFkeM/C83YVcKxDCMlC1pKlhc+jwYYKdvz8dBXG5h0f1XKPyRkeXyPzHQGdovzgyf6F
rmJo5PmOAQgAYBpMxKHsV2LQiUCfZxP2xWAs4K74rcAes5vdVqBXYeXeFADCX47amOz6o2Fp
OAE2W1A1Zacc/sWcQrpGNGbPzJedST7hJMXZJVKNy7LLBP2V90UwX7IHSyhFxPPTlRpdlJtx
YLAU3s+EekcFyTLIwRYHVjWm16JZXIxAhQROCT/c+L5SU8juIBBaGTg21xUr52qxnAfzmZdz
LksQUE+0vr6WcDtbfnRz4lhVzqCXLuEPlcGOB25srOGhtfZXA0llkT5irGdOIYJdpth4ywJl
kp4tZzMwgzWFTY/+U0A/e4Q30iVwhPG4rXCk+CakG0ZZe48xZDriMjSo+R7+LHYI6nu34GDL
QyJD8Kfbx4+7coaLSI86T8fhZbtiUi0l02A582HFQrAyBI3aPmQs/2UHgqm3oeH5Q2YHwraT
+ZCHz+RL6RkZkj6zuNhdMeK/YDD6hyzsbrnX/5b7Hu7U+hNtkbC8ptcin0sBLQk0qVQikf3q
/5bji4TzlQqGIZLtkO+5LYjHMWvl2hbF9P3QgpUxFtq8jjTIi12BTMgh5i5hOdWcG3ed5DF0
FXBK1S61RT3MvlCrJKE5y0qBc4mJ0VQqx71MSz0sn07k1WWgdWMUVrF7ovQu4kr3YAVg8UW/
x2G05+Gv3cyVNf4xV7crfNOFQchKZvzrhyxUkbAqTGaC2X00bQJ3FjBQRNQugF+At7VbFaU1
61BdnvlgvLTjxi+ezY5yHpRYqekL64PDrTr5fZubHvR6xAvDgZuneevur7yBGJo/vjfkcUR0
PNNuNKDp6Zh8N0TG377/TLVcHKDbJQQrlmwhpiach74ku+gCLcNA77i89FZWxaEcIWph08a0
v22+Fqp2qrXUucvnS5nZvA1rqpv5a3XoFb1rgOr3DIORtoTqJcbyiZKumdQIDmMM5GSs5g2M
Iwpgme3LtIaM1+V15RAnWaDzecNEPqSrsZw6ohhbhfyV91y5ZBw0j3qFISWnwYznONdhpxbs
/NJzA+qBEX4pe1/pVgPpRY4d31RmDvvlOZUU9K+fdCKEojnHNRljbLadBWUCwOseejT+Bf0x
5RFcR35Pm6PC0e7ynrTH286difSlPdd9+YX3cb+fiD92mXig4oP0HLfaS3fru+QmsXdzwYvn
JypM5tHZ2ZRgXt4JZITF2WWePoPV/16NC9NoXws7GPbBemD8C712VZI0xQAiljWXv7Ol10ih
Gf1V6fsLkPRUci/U8STqcx6QxiFqbwCRzb/IursoewRVuODgmw3YZt0MjCD5MmmRktfLBXbb
misE2eLD3+rL9tm3uUqYi5eUbw3iF3vMJiQnrzikGyW7TCYwZRLnzoDox4P0QJ0x+n8JHKta
JDUyBPKrTAshxak3Fs+N5xJyuuntAf5HSqqdozBrXQ8nchqJqX4W/aD4evqdKShlUiru4bjC
z4YC0SSl9cCqe26CwI6HbKUp+IQLvvqt0UIwhVoPYEqS3NW1PEkNZrrUibD/6k6RhODMFGu2
G2/Kjchiyd6OR30K2kWdAWHPacb6Z9ECZu6+f49dQbZy/xQzxe24vYNqEl0YJNcPKKDP8zEw
WtBhM4wTtK09miuWQN8IxzwCfuPjcUmVhDagqDbMTSRTyoNZfZNNvXTVfpNZ8Q0aIHu9pq0a
OHsEictSBOxvwb2dtCSuM5nZ1VbJecYGZ/+xmRHqxBkiAAh+5KSQ60wJUHde6fvJiR7zy5w7
yJwKJhYudVG8/CGjpgSyoh6PHKu/AC7rJ1XCSezD+g9X2k5QLtVu5+lABP01ycF/l0m6wa2H
4WalQa64SMe0BNP/9JY1Kcs62+ypFqRcJ8GWXI1IQpW8y1sYQKa/2NR64WgyuwnNXP3MUEIs
QZxUb905dNfde9PKkU6numucTOW+NQFfzgAIYHQ+oVy2etASKXloFQZ4TdjB/cpUx1El9dyB
btV38Gz9tJhQR8xVm/O+QkxIqcx53fM6QpMx/hTRWkOLpFZGV3XXOOBqX+6IyKO4wUB1YJpF
bkJTHLXGPz80Dp4WOftnX/HBo7E0murP3q3C/zBe+Jpx9hJlLGq6VwLIxtAsI+mBX+Z/i5OH
tdSgONw30zkG2zp3NdX2xjv0D7U9JyGeMWlH+izvMe3omgAoN/OIfjPyryrdKXAQsmBvWiDc
pmPEIAF/0s8tJpGuhzUEXdcTJHXFcEdF/VcAkJDGdD/w1KzCNjfyMsVnE4BeB+sZRopGQbfJ
goDl2ob0jGl66swu0NxnUnPeBzEjBCBGC4m57cwQT9s79ZAvq9Cgu0TLYebJPB1Txu8p+11K
eIcFTyIYNr/LAKeoCIHyswIZyCCfUUyxzI8l5PjkP5Afnw+alU07Q2PC23s+rZiZMnzWSfHX
YxcShwemBbuxK/yZrgbggL+TGOrJFWaCBm+zOeQ27GeAWJZQn55nMNZMNUkh1WRvjgqvX0Nr
PiOIKVZBJLiBbwT0mk+OGRAB1wCS3E8T+RzKF8A1nmGJcTzFHGmoRzoIv+1qcAKoUGq213Vl
cnsIaYXx3MJcS6NbrSW+Sc3PBU4N60T8nWVQvcSP2o5OmS3ncVKwZCioOd/SIw/Vax2WEP4z
u08hwgXNThwc4jSBNNL34YlO9VN65YDb42KMlvlBR4bxNMq6Sg40UqAxv6hBqCEze37ZJtCm
gEZFn/Kz25XelF2utCFnuxYmROjxG2BqjHCr0L2fFtL19Sy7IFjO30S/n5s5Oonwi1zD7iLs
5mv3o6GgvWi8zLByzWoJ8u69pq94jtYmna501glSCAPXJG0SC/f2GceO2HkhJZNiRkI/1MBv
WEpOUUHUYZIejquPTaazbenBLNN8xT8tcbLgJPxxJ5jWtLJGz1wLN2NwJ880B4tLxY4RrtZW
ZPCWcyrOo2SxuSrbQjTtSPkq7VQ6jv81/l7cktv8iUct+/ByoTFn5/R7LQcTCbT/AgE6oCH5
1PtX6okI/9C9TXn6E5e65MB7/fnpYL9Fd2XUAQWCmgMZRa/xLK8vtApT4NWLNcGITKXc1FjB
HB2aZb7zMUkfW50WtSkxJg3yRxprQfhBATGikr5OLcC/KHsEysWRvudFQZjvCeeeo40kmcc+
Ua3Mv4c7Hgrc/XTxWr0hOYBXenUnf3LPPaxjBqkhAXXiIeEHsYnjKMvi2B/XfCADSwFXQz7o
aYzt6y2oyxWZ+65zWK9PHHF07RUjGwlA4yrpoJOdnaWZoIDRYG2WGNFzXLsPtwUsQEnKByMh
htmbVZZFr+DPs54J55VvLMu6DNyqsJmew/lJBcf4c8O89zeA2x6su4UpvCdAT1ztm3zmLKsP
A7EWWYEJ591fFcx1XRdKtXqtONzuhHE3wMVDUUedY7C4XQE7Q1HagX8s+Xt5I5Es5lCYPl5X
ZVZ9vCghsT9IPKHhE7BG6oGN8/DWEleGKdZ/xLUibkknsEVTCesEUpUt0RyvGmu35/qA1Bkm
g7lGD2eGDjH7SoJtEe+U2JLhlP95zIJ9OseUmQ7kMS3Wm2o1DEhUDk7Ev8daaao8bELkuX99
OOyKhcMUiSspwceDX1hLC915PLln9sTHxIDkt0lW/H6/h7nzXZBnHbThrBDC9bUla3DMw7iY
TKk6oZEBs9lzc6Bkrq5IKMSmqlJS1sngljqPiUDjjFEdK3s+4eQIkytRasas5UiHr1y//H01
4OH48/n9TJFmZcLCvCWGX0+/uWkxpfRRq6n7J63zNduK0XpLdr8JJD2925Z22M2eykhbwA+4
hmRdiR/sVqUUlYwnKU1UeUfjygSsjv1aX2Ln1NzSQJGCjcgH75a8td6MDLcumzxuKVrkYjid
VtyO3I+VMScQxRyVOy1UtMsf/2OTmNOgJtZ2o99k1YHe/u+TNXTdl1E0jmWhIBV8MX4pkc6Y
2sV0FE8OYP9qXzujRP4stfm9Pn8OUV9MhbN57H6GAVlF3XMyfBiPynr2lkTwVx4aKzcVwWmN
UssS8sx0w5QSdvhouslV1QHu1rDnOqbZrU+5rvCvfd3ZKXjlsiGO3g80C/qMKgLg8XwiMVpT
aahvXotv31cm0i1diE7pT7gpNXFX0W1yv1FI3eUAk0GgwMTJX/yNgJSjiOQRswfwJrB2a2mY
I+BkOrVSKJm9QHwmk58b7wgrtsfUkG+vS/c49FN15ijXki6tyv27E+b6rJHXlTgau3GsHBR/
nZMJt+aJfAJNwdyw04wTNO0kEr5xmwuZkWhZYVoscdgVXka4UOTLKpti5BiMllZeBUCaYI2b
P5OovGO9HBTzoORe7TV/gWDQ2Us0TQI8A8+W+L5CAHeXohZwaTx57oQFynfNqApqYfDs3kMK
1fh0kZC8URFSYBdwqTcsGj0s5ELai+woBPrrOG3QqOn8J0cGLknr0hh2L5j1N5oSmXV/NZfu
qJYVhEi4Jz1DQYXMmfe7bE6+2SUg5kFe7ojzQqCRPUKPPlXfORtfTfrcR2OhAg+7RYoOqdN+
tN4HWL/+xe6fx/ZUaIMhcZAdhLhJjjW6oaS4UuPRDEY4Oum7rB7O/hZce9yoJTchPipMSkGK
9gNz8T/ETnQwMMVIOrpFUzgJ2dtumPb4GbcBnvnJb1XCuLuxvgIwIxVTHKArScj1NKEx+/0C
sw1Cqw5h+UEAMuUVRhbIlgZtZ++GCc8sYRQ1ccFOEzHTolRHze6spX4y0h6Mc4iiZBKW1wXG
UPTfLsvRGi67lnbWS5j0O0tEbOXw1H+LVre3ejnVrwofIQcvDlh2RjaZTLFaFSZcJrUlMK+4
Iu9J9O7w3owhadJuz0chqdEw9gtQ5CLqO/yoKwC06S5X7lumr1Oj2nYygLfPeIeFvCt+qctn
cB8ukgcL1YAxi8lhpkZZO9fIBGwqvffU6W5hk2e3aGzUViHQmAC7FbIU+qIUjiPdoTFGRJCZ
RrILvBoOicJ8L9YcWsfZCw+/51O9q5XVurNYSY4vhXJHcjnErI/8EPt4n/UQVCj9xl6Br8o6
KcuFYaaHuFo5jLzlae6NsMvcrekMqNPf9riEo52QMaRsaV0bnUtpZJPMsSotaG3DEqaJGSoG
0R/l87qYx0yYH4WWQ3gUSdRCpph0xEXTCqs/DRiQn1xh/eUQhkUVYycHyldlcem4WxEfxcA+
frclVbm1K+Tb4FIoP6T4FVF+B7xNzEiasfet+hh+SvUerPTUuuaAKpnrZOlib5UPyCCbJCmX
qLJufkxPc5ul7ryekI+FoT1UIUr6ACXVg9Oa/HPgnm+hmD3+2lwU5Ewpp8sOxgBzyUdalBAG
hyvlKY5uR0tgLwQw+nOWWEOpVPTZZY0/yfa3eWWyuNhPj0Z5aUCpcGAEZE/7SY0hpvEskvju
hj78emETLVXthgTkU7w8EYLSJ7eyn/2TZshS+Tw73lHcnGhVLW6tvyKax9p4wjxUXTzC1xXC
kWKWQl7VabXDpGNRnet+GUbrmn4HNsN1h+DYl4+BdA/Hvgen5frkY2VaTDTxGX8TXm2rC5qu
leqjlxe+zyMhM6p7mzlINnVcPIbnSF/0p2EsVEI9F/Lt358LPn4YerN3kVN8MzuGX/zY1xK9
cYN5GE1XopnAAH0rChgzPgGgCRTCTYeyuMJKDB5mhQH13D5Qa2H0o3KPcgGbMnKQ13lZhW7G
eRdO2Wbfzm0VPbDp7mEVkZMwGnHqpOjkrsqtJINCxQq/50VPuivqTO8ixxVmxQ8iSNPrqvg+
B0oAEvKGoOif2Z2Me6fjgeMah1nS6Ha+ZmnCb/MnlY7B81gCqbrRoE15fTvfXHIPxPGCZvlP
xiHiZnLqUmCxLzev6uRtgBj4DEGAQGCo/07879Eiun2Rgrp2kqpaRyUXgIqrGd0fFJ34epTC
5Ety4E9RJa3fDDxdGYq/Z+4jquaaETl5lPb1Ibdn4LDEjl+9CPHUEqOHk1aujzI2nLzSK/tM
2CaKEUAZIpLiN7n4KKlnSXo5Cvle4a74NxpsJRmOyxJFCwftHHRljZQZw3PovwKLCouqg7LO
WmFNgCbt4U0BszTrXh0FJS1JPdX4Y6HMAxjCo8nnoDUx3r04VoF7Pse6GB5eAtjzuILxEJaH
8BVhNCS2iCZQoCU/+H1tjDOgZaEJTYy6ymf8efsXOY5xlASlyeocmWdH7fID5uf6e5hkHaI5
nQkOygb2dt75fYz+ath534sIBLaZ6Vo9QbuEtBViRwjoP8ILGwJkkGtEqUclTUulD+9+icvp
yqZrZWrfAcN9KQSD9UwQ9sQcFduvGwUxgUufso+0m2rhxH6LiLMe/vnmlsOIN33qTvbdQy9W
IiF/nApRrzpTmD/YZq7I13Fy8gl/NL5Ppwh7DGkE7ZIbir8F3FUnmCEq8h482ss+k0xIACOI
8LwcXLIl0qr8p+kXXDMlH/qdY5y3ZOjwNfHVoHJCGD0oUiXHEnNYwfCSQeWmw7HN23ea8fGN
QRtvl9gqmbi8SAaKlqzk8jwMSu+/XI7t5PqqKhY+jlalHuPF6H1QP8ZxJ99gK5kzmmk6poQo
xMZPNtrs7vxHmsxSChVPIo+RTNtlSKczusO61o83fAoxvq5yYIYLEkRo4vcyLvlm3eSL637N
5UniH9KoamWiWFpE+Kb7Pg5tAtzhh0GF94+V6yl8zWYMkA2nSyImDdwZqrvsHoN8e/ddCkIQ
1BhD7gWb0k+ZFPItOkqLlgDezjb8tGHlEBiBeQa2sj8poDpeB3I6Cg06ahF9FikaHO2mqFOO
bv84I9sTW6hkKmwpNwnJo5rde2dHtOC9P987DIaIcPlk3AsmrswtTDSfjmK+TtzKdwwHX26+
wSjLe5cUmcOTXBngvQMjN77RJogejdGVwDpIqSqucSW+zfdx9rM/ulwUfps6lU384zXZ8QNC
dzf5tf3SKq0JF+7N/X5qVXjXlKGgiZFzTF2N5O/XfDI99TGsoKVdkwrZHHjyU3bK5PuYUf/2
/bfT6lUzkowjeoGCRTyQ/phWXpaUf+S9HBsXHOo51xvlLjqgQO8mg8aM/N/isOiTTBdiB3tj
wrgQfShmpZbvw7nkVS7JZV/l/SLORv0NF+w0RrOPx6PNQcKRBRkfmjahaM7ZyArmlMHjdIyE
E3S2eeCPCuiTatEipkgPKx19PNlp2HNT6jLu9H1mnfTsfDtJqMh/XR54mcx9BYe+6FCjhRd4
8sOanRSnzSyIFdRzMp1H+5T961Vk19u/X7OXX/Cm+TKILej771U0r/RjGD4uHCKVESLkh7uq
Hv87cOLhInju8laO7luba0ZuCML9MI4XI8Aicw4rKFL2dCjaZ7r6YD0QyTXRs5/v4uqNh2Zf
o0XQOCIERviFecxiiF3iLXtymnxOXhURwogHUyZHvf/v8RrqI2daRpeV4izGh+w/yMn97b4O
408tFikew+rmtP74nYAwFcQRZhqrfERYENf3RB1n38041JsCfuL1E2KDpU3HYposewlt5ZUs
729/seXBQsM4dUBcMtEsPcEfclUW4U8UbOCp8vhgvNnmR0WZAODVkg/bdIZSV5sMqi4iXohl
bwnbvLws/BHDAJljyYN8s/sRQ7JDSS/PRxnY2xP+M9DRDmpZ35gYm/m0Twot/0KuXqosC3/u
166Tyq8qA5KgF3OHSPi2INnmA824yrpoMyH2odUKvtZZI3sgV/RzNTUu+lPNO7LLSabbJKMV
K0Afj0rZ2GzZWKSNKBuZiztVppE1Tyl3yiFtpOUj6bA1nI5Wp9k1F13NO5GnJicT66yFsu76
fOwUSO513fOwUzDt5U0vXPFOmJpxexC/eu/cgJrVwxD9aBhe8pvueGKZNSf5kL3UfCmFakiK
Gq6icHDyhUpQ4Tzwi8dtZgGqycM0XcbY1JNUYSEaQh8dkPj2CeMcSOjMgDvgZn+QcLHPaOlr
0HiCC97Q4DjQ5bXvZUxtz5+23TAfRjtDqFjEjIW0gYBlh4rskQzh2VOEQhRjH3ICujrc55UD
ZCLGczo9UxtnpujYS/YnQc+vJV1T0zBNTYQvKQG7Uod4Ejds+RDtIcfgFFsCiFNnYOHFr3bU
t/f1OFIOaa1D/kSCB9z1t/pVHZ81bfhmeXZqoGLIne0hOTkTSloA61JlpXMG8yq3Y44yBF9X
VlC4RXgiZsXwKb7LEc3mKDlW8BKYfUPPzt0UCpJoxDauWdJWEsmCHUsci2K8rRv6w5FzE0WA
XI53tbECNv2jc36IjYVo9F4MEBVq22RFPeWUUePunNJinwBP0Fr8a2885UkpGkVQa8O+WB4p
nwgN+mOE+pXBLkGzN7kz2HXbYhm1naenGTxsjvGqtkKhDhwDh094NheoiB8haJmN7k4N6wXf
toGqqCJDWkj6gMoflEKd+kuhChxvhCenad661sbdxgBWLxtWZdXxcCsw8R606xo7IQ+Lk55i
tOEwPEFzLrNlY/lQVXkkAutVgOjQ/UuYSJ0s5oZrAmXXmKBfBsXoxXWxq1bsQWdrvdRSRmzF
xuffkFirN63ItRl7ZRedobNGhG8nZEq2MUHvr0pSQxp2Wil9P3VtLqxl5JNkfUB0FLZApYRX
xAXUbhM7EG7YZ6jRc2pNkyDUYy0CT1F4Dt3o5VJpZz8vrpwaHoCDqPhAjTJvYLdYLKGhVGH5
joX2+A3urUAR7pkaX7Gl5sbG3f1/Z11eT9TfHHBiU9FLq1nKPgeP/5lGpBK0ulQNJWYreZq8
6KNSfiIuj53OohaeJPV7yent5OqiO0Fjad5OAtZIuowQvVC7CDe1hzFdJmmcI1DbJGcb6eB+
ADXZfu/3sS48wc0pKR/IG3VzieNrZSrzb4oLJ2eq4JEpSmjnqRx7ASo01/vU+ue51NDOnN/4
bpLzMkSTyGL7nAUMAlFHFsAUsBJPmS44BReBI4HnSmN6BVF2H0lvcZ7a3NrNwzrhd5oZ7aAb
X/9fpZU82E5WdttJQGYeKJK1cdsucndKpxLcoX8Cfi5qsMH9adnJXjiWddkr1LHiYwZEtXck
QauGPue4fXZwb74HIa5g9FxDEipGCIkMirWCnjk40oJ87TbVw/3uTj20Ni0HllfrNo4S24QU
HJTy7xGNaE8Aa9CleeMgrwM99zcyR59+TjKrub1RkgegWnOb8Iv0RuuP0874CWIHXUGIpMfZ
69yo+EtSW6CPvtzEMg0DA9xZbG+AxWFF2iUjjf5GMDcP0WsRYjS05ICrUN/uz5CbuPpIZSqY
AlxfViIzkQwroojw6uLxJP9+fIPrPgsfiHtBk+DwFom/N9btYVso49NSU++U+gXDWIgfJ9oO
ArHrNARSPjPNMMeOtER15qgV4jwsWOq31eHZvmA0koklzjuoGhCHod4wemTB4wzFKQpzqXp3
VKR96SsgqRre2wuB3YnPCd0mxvApN7YTvbd16K/MJEe803nLEivqoFrfGcKRQ/D4zeDtSNDH
ZtG+LztVK5z1v5QcI8EdpkC0PMCJUcT8f8PDneWBBxgTQLfXhjGoAcP+bM6BxQ7GPFKuKEUi
RdZniufvAoLZmdeYXQdmU2u7K7van3I5u1bTmT79KcwVCV4aMpWS70tGDMhLP3vJfVrz79ok
ys1e681oUIOnx/GuUcMm9hL27/9kHwj9c66KNfVt4KI58JDifLHwMuQqbKiuXMCvT2Vkadqo
efwzwdKvyq9T218y9iW4wHrM0VClcP1dgz8D+xQhYouweUX1MOsLWU4fySYxPffN2hDwaCAB
9ct7ScycxAvEy8BefEFPm9GhmofjbQzD8CFbmA9ffYNIxSTyVaqV9blmtzFwDie9oEngHFHb
hvRQJ4CeCpoH7+3NQv7XGRunkE9aeooQRogdS3YRepB5Ylt2vHmKTl8E3e5GSe1GvHM/KiqR
LPa9v+v9RkuKrNt/WiDq9Yj+IEMJcB/1Sf0lPED1cG647FKUmb6SS4LAd5R7lJJ2RiY2j59e
DWrl+6v14vjfNYWZ5mQgSz5RO3YnbLGxvqXejgxPVIjIFQWDTXzQqpC4e09lZUVGYid3LXWW
mEsXlLHTkmih4CyBtHImvdRWbLY6sql6Sf1jodqq7k3QS6Iv5MbL46CYBuQm00g5RKom5lP7
XFE2Dt5aE1QIbD7f2XQ7tD/xnXK0kGz7kM5TqLgMb487OWhfaJImYW5kYY5PG7V4mWkYbp+D
CeaGDtUj60xnQH/wiWeh90Kq8wRdwf1farLt8dmX6TChgZDevghoKFNmIJXlcxe+xFikGBNi
abhq8mYmcHn8K64K3PmYzJuGWIfkcutZLiEVMupGL1qeDznADTUdnP4tI17gVdmgR5oOUUc3
invvUaKq/tLKe6FhysYZanqAg00/7KnfDyNiGfCE4sJzUIsHQJ8+2X95+2i2GQ1R2vEq5ojI
mzfHikxdlLSY9muJr+qYreW9raUsMs3sChSetgo8ey9gxLG91iX4J/ntBGZunE7f0IKKJjac
aq3W94DMEUpBzkRmnSbOx3eshdeJeGrHJffaa23QJ+JTIzrqFVWMoMFpJXErxc2TLI9WHo3F
aKWz5Rxou9CGkNCn7QVU03UZt911JkgLQ909tockALv2/FfANGKe5kj80T+Z0WBT3Y8b3zEB
I0+7U0GfPbowGWRES1vtMfTmyevQrpOnyB7rfQRBdp2nAl/vWzcP+kssKqj3jrWSXg28H7k1
PWKPiAPfTamZlaQ8SrWujL6UrLdWeQ2VL/5P13wk5viJzCP9xTIkf+Fir663h9HhBCwisy6b
dqw7itp+pnQoah/HDkolt3V0NZgC9DLCM3MU5+vl+yCXVnLE+zU2H5WXUFfamPT5GCKPC8pn
KkTAf6eAcOwJGnrwSlCcFaW6PziGzMbzbNHMScxJkdrjlAkL5a++HvnDmhMOWUs5akyqsb/H
0TQS0VJd7Sr3B5IuFokjhr3Mc/7b942ASUftXpWlPzEtmxw/8RUi1lGexoF4mp88eqIsz9rM
9PJ/D2ftXVHuJ3nqNYqCBy8EoRknk6O+deDSZPaU6mP5/U9gxqAgb8wvwaOjQoujWtKlGuzW
5oPc1DKtnW6hYgMgq95VoM6JaVWsc65P2AuzBJ9ZVKIloPWP+XkZM/CdnWkGJqoN5e9L0kTZ
1dJR1uu+xETKVPH6/apmsO5yvx8qsKEFN8/eyqrjA43OKDsdEHss4kNv7GJrxNHfNDITS/dQ
r6vjbtdj5HFyBaeIcdHTz0M50or97Qq2fS8VC5I2RJLvv97PKSBYf3j/VPZjftfgORYxnszg
rY2DyyA7LDrQplL+glV53R9MUSaljabv0i7IUMRNI51ELb0dghpEgmSvn9/MJG9Sd5HinV72
o7M8eLjVsXZGCzn00UsYo0DDD/cTQuqVZcvOvun+Z2KE4ihcI2UCPI6r+fsMHD3qKGJQ8lTz
doV+ZwizkNlyWXYNMlbX+r81V/6fv3XvpOumnvg77bk4KrPFhN4gccYoP/lDuwxGK+C+gSsz
8aOK32atjXXuE1Z/5YWrVr0d1zOhCQwLcfGsryDoGiyJ/Mfbdp86FwnLv0KDnfO9J+vvG4mS
pFzwxqLDt6XY02CF6A0AfAHpE2HHcutsI53gREsxjZ4MBgkxE0s3gqTQ/AwMDxqJWj0+RMXM
ivAuUCy0yi/2OkY/lCuLBUpWjIDaNmafhPplbDlD+MQafGIBYstUWeBsgrR+hwMvgqGzsT+a
DeZICaVl7WYS363z8ROKwMtn9gcLZcS1X2Y1ffUbYwSdhYjfkmyJY0O2o5IzGjSiGUTN9YjB
WVaoNizQr2+i6t0UJQlMGgeEKqgNwzFNQmoq8g9bWTqJfutFZG2bBbBxMfn2IjpC49OVnfOV
DxZSm1m4WOLCrop8YCG0it2Ww5dfxCGB3EoR7zKlc0HpIKYu5O2lkBXes2S0YVsYEWhPqVl/
I+PqY9YiZhYBb+Iy3VdEoeBnglAYisNYhbmm0xqob07SczCveW4K7HG6/5XHi9e1sIuJBwD2
N4EDJog/tTnL5UwxFy6MDa/2pQsXYvkheHN2TvKhGlkn8TLO1l7emlPTwwssqyH6yMq+HKjz
VRMUZpFGMCVltkoYUE5eKzwmWzcjym1PW5x7sFxMintsTYFqa/pu/cv7EyXzN9vGZFyNdlFy
yxQEeEmPYoWajBq922A/m+m2M1t8lFzNVggE1g7HbUWgtSv+K1ZayVTcN+FVesZHfk9wb4Aj
5XI2MbCWTbiMMtBOu8xEHyPQj3geMUxCymiRU6A1+LWumDgA1JrPTrhAgeaIsVTgl8j3b3es
y3pNiHW0t6+Gstdo1LsxBeDRPJ4bRvAxrZkizabq/fSflL6L3v9EkTv9gKsGMlRQ+Y1VFh1p
wLVGzpjnZuWq3GkurrUzZlc7m4PMJjXPLhztnkCh2lRQ/g238R2AUxcDkS5vxSvniT76nbuc
NZkxkx9utSsExdvKoD/QFvrCqJMxzOsxdvHpjYk0y4iQ/wWsPiEKbIYCZK7ftUrjoG3LeOtO
gDxzrhg6x4tigEr1pjnxKebFZleHqa6BRmRn8dVVSsqsTbi7m+RzXIP0L9cOEaS4tgBgyhRr
O3kxoyaWK1QDPY7dJCPA9uBVpALkBZxRXkF+01rOCoUy7NSWrK8C4WNFTUjYekP5w6lRJlgS
wrJoJxSs0bUcWR2YBdgGkma9NpZ66MhPy5AXVc539pqJ0G6WM8BY6alFRdIuTRgQPtJgBtVz
3ANc4G+F22P/r5jDNYWZb3FbgOFs3CRn6zN229N6qvcWsMd8qxyYdWyTm4pcO19D/UVQPzPj
YCBGXsFnJqJWICcVUkE/3uw3LQaOkcfjeKwFsrAlbzCdfZhpZgHGH84tGQEe3TBJw3vDF3/W
PY3/Ol22hkqz2+rjmCxbRk6RvhtzNuYAMDNP8wDzeDAMPDTTiC2tlyAi/y8SqnuJ6XEXX3tx
NC61ytwCeGBbLJdtMqWEtHh0NyouQJdvj3+JysQvZEM+ub9o2qdE5kEwzLpS6xRiLU3TT9RD
X/bw33yI9bYXoagXkSw0S49IgOhZY+akttvg3v5ZRIcWu4o6TUf48tKSg/OHumSQzITjoNS4
x0nij4vKFxydcRzZGGusCVtF0Rwe7/GTngvefY43uynGBHTmy5FCox1VPBJ/BCPvz+iPGQsU
Ure2Iv9caa/j1NR0Y6RElQiiKNAWyc5uVO23zfNIZhLSRopQw8rOV7FLQDp4AReQU7zyeIbX
qCgZmdxXGhLL79UhSwhuHNs0mTAqkBz8iePedmVGiMugwTLHfFg8dkXRucpmtAirxarwzewG
Wl8CaiFaFfxko9czJrM1xbFxmkXpJTnafxRlN5S+OdPF3fYfuVHOOIF80eBNfwPLtbHI7Dmd
G6vR08Lk+OtWIlsnbRnfRt2Nq12Z4pZl3wSOkb4Hm1PCDPKoyZy3IYhSPraCmNBXLYcbVHMI
wDWC55BdxCvRRwIjHJW6Lg0yug+P91AA+xPZRazoRiRvDAxPQGwS57qES3jHDq5YkEsl+Ih+
4DwibqsIDUTbe7EpD5s6BeqcjNae1InebIouDBsUYm2uJ9OA4tU7XqQcUZY+ZQGwAz3fMCBZ
FiSjbnYxO9ztNlyaOeRHtq41WtBO4ilTas4Gk54/2Br4g4K/fZCY94FzIp7kQuCU+hYxAjGK
oqUKu7IXuI0cc0KXCM/ou/YrbCDN/soMuexXx4Q8jIjjjCLjPC4rPa3hgY2Q79XCn+YMNbaH
LwB0z3edzlMAmlFi4xC2bp0McpevkSIExa6C2KD0kpHdH+Nrew93Q0YINGEErVg/sUyhlcPr
+KLnSLDUOgNPPWKD6bxe2PshyqYZGW3y2sngRHTR/KpNZoAtBCJFPqcha6+gSz7+LR03rCTT
SOq2aK4JuPzpD5WUnmc9Js96v5q/2KQUO/32XYXmkT6FTMd2/OwmSFIB7yMqFpyRCdzrJD6e
HjS7zSR+0/E9fpwvHivj1qn476soTRM+iryOe6zkUP17mFwElZ9nbKlAABigZ7O1YovNPQWH
SOlF5+uAKasKBr1xZ29/5xKLN8UsAzGhZYkE8R9T05Y76+g+oCtGHGioAQHlzOqfIFqmvO+L
dbM459WyANST0MES5/mMP77qQhnNCyTjcRdpT8KSGBFsthjFI9iSjy2zrIiH2EH2cKZYUSkE
HJbiOi2/XWmAR2jbtQyD0yZgeI/fG0msxP+RrVnCiWT1y8StRLjck9g+vvoMWXUUIWGYB6To
DSq/9X0vNrjx5B2t2dZtEp7lpfiXuA14ex5ryWVXispaNl871TLcyNWVcjigdXzcBpTuTBML
Hk5zviWW2kX7zJXmghDqVCoCoowb78s2GUKXlTPH5HKjnMwjY7tXorjNcExfatoE8Rgj4dyE
awQ8Gt3du+CSDKd39PbvkLddGGJep9SC66U5J9wXTn81htt7VsoTwMvgF3dUfLu1kOTA2rgE
SH0l7pSM0Xxd8K285P9oJHzXSKJJjF7YnF7deaIMkoWEmrH7ApCBYcn7AWQf7eyi4NgVx01Q
YgR2fNQ0UxLHHjzFLklkDwJQx80F4wyHJaIYZas2sdo3C5h17CTwuXNv+m88WeOJiDIt1BAE
QoyfNu1de3TDOg02dpxRaiHFOo0hUYpoUWK2Iu4GlnzKCa6QNBkBbv2kttWyhcuWYvb2k1/3
jsX1wSLpyjsiDjRiglWoP41h+9m9NJmqhQZPbiK41OCNnuyYBtU6WPhFMDxsrrl2cWYdTnhp
d5fKJHeS8utnI4HGz4lzK3tnGYxsoygBMYFf3eJv0NIcAqx2/YZitj0If1gPJbbHG6R1SNpC
qUEj6vd4wVXMLvQ/h52ccadyUokdWMVzSGuUN719fvj0Q7VXmLIQ6tPHo4ep7UuFURCrpX7B
uEZeRj9DKSN6CpZlreOVhodebCdaO0Kjo0uVrNdEfx1DY8ZM08Yt+2dSSHuScxd03rZbVxBB
pp4w2qPzGrtbWgus7KG1lnJB2OshhJjlv+VY8fOB3+NNjm62SUb3zh4D7FRkw7nBjaZR+y7/
bUfidgT2+5lwlHlTz3K7Vg9VlLcPeG2csYs9+pK7LDh85QaOXTZiBmZ5wjQNgh+A3Fj03DJW
tordjev0kGMZ+3gSnQy3GogVWZ1nR2x4RptphsDMoRea/JXLt7RIwKwPYwlBpcX0G9xxToR8
lCfDTyc5rtEv3CzJIUqIch2m3qrbp076onW936tfgAdrrubhTa0POjpe6SQfPeUHQbcYn7GA
YTxbAJLvLa7CK3kv9amGqePfFbcGBwt5yjH4CW6cXZOZfWRJKa0RCvHZmVhNU6BSWD6dFNtU
P+C8IB24JfHvGBS3Y7Rfzkh/Z8Pdef2TUk0pyn9YnrpvNmN/ydod8o++pR6wqQkUXvqVfP2N
JdZaHpQKuRpmh9QETXviZbR8K5M/w/Do5zP6UGeiggRzxkrNvEykP4fnLSmkf2DYdGizKFXU
KSwXZluHBNWJqTixQ64mYGop9IJ6WL6DhreZAS2Zf/0FOqjMOQQBgyQfgiZdL1sLjfytOpJN
Y2ILaLArtxa5Bs9Rb93jq6h5gQAHuN7OYTEitUnrYrEW+K+KlyQhhUdM3eQ5SDe3MOqi3Raz
sEDeFPSN+YlTIYGH9T7VNPcDZFspwvRDNOBpwVXT7iug2C9WVPmA+kg4g6wDGfX3wKD73aOK
2CDdZh+41lwloUVhMqAch6I6Y+i2w6r44PGzeqc8rsXcQYisOEdR3JRjIfCa9KjviXFwokeU
tAFbNOh08JrR5sA0Unj+8TSgOAjdKS0pwbviovmY21CRfvfQQTeoIKEWdPDIIGlTPTnjQWPo
9clelpPlgB+2ZcSAwQ98yhpCRHCij8L5vJaJC/mx+rai0tCzgWs2jxIQugpaYXzZWEVazu0D
DPNyfh12qAlVr3P+DZgGZZ6Cp6tXxHdd5SKNmXlgJg7vK5+rN7H+ti/a263IclyNkRMMuPbf
KUsLGTjTlzaZag9pwR+NjNH8Wwe7goQd+QjSUX93dQQifPLPRkOkhRugGSlJEs5owo6gJmNm
p93hcZ9SG80DSd7FmWrJgJZo3kzlCwdwnSrz2J4kBU5Vgx/Z5Qph8RgJOcDuMhZEX90UfcMd
V4HaOKy8g2q2wkdjKmyz2oRrnEmoEmLKYQzs+LYvMj0qkKY+cxpRyobpIGdph0wK7bxkLqH7
tERXy6RRKRxEgag3l8/QBghbT+6Fe2sXtM3R6mnEHJ49DALlyL2lLwQhMflD3JqX8i8RPaOe
cCKnWaDq132QTXh6ApawtaVf+r6wnT4fYLbOEMzlOcjW/JW57Kc/h2wn6k4Nkz5ppT1FTqlE
ZiGonxoZ3rBKkN9tOwmWYmxeJR9b7OEuK6PZRumGz4KcuXErIDsqUVZM486oKOv0DAczenm0
Ka1VPGcj0tbVldnID7CmYUXDug781CPsvDokWfOrYWAUdmfV8eVdAzg6mDvjOB1AD7ZB3AAa
Dawzn3Vvd7/fn2mQfnViI3L71kdOUGjRQ8Z8mC2+EFMVffAFgTuDU/F1im7trGIw6I9HT5O0
M5QKnJJ8rPppyTtLPmYmN5Wo5a6Ov/qCKYDEqjflT0W6R9e3LysArRsnSzKTNdHKiWjZLmiR
pg9Y7YVqTZN3cNrhGQAoq0woQ9zzkOtlq+M+Mxi7VfJ5+4FJsxuJPK3FQ7eAt9WM5NYzAQmq
bhVmeMGJygmPS3VXRbYsUBTpeS7MTjjNrDN1jvipXpflz5aM2YTnM7L226HY61n7AJuSdlVj
bSqL+w0j0oeeCc8ZvwBEmtF/mcIEuIcSxqKDOVK5ulUwcLSgmpXoPjyh679AERGPxQ5GoPX+
SuUMIwaAXga8G9nSXsUMEEBfekUCLjU56OwCovyjjhocZVNIVocrOaCH0mE+6u/w47ETxnld
NNQGXEhnCdrv0nHcQ0SX96U1hHrJkEvoA+0HW2hHt26l/2qcdo/aTKvHDJwE6F4NkLZ0oFj0
67XgXpcHubvT2X2aujjP3iGjORe/X9kmTUePuVsNzNdDrh7t2orHZ+9A2xozFM9mZT1IuaNv
nf4B763Kgf4IDT9+c3tyMfSv+/yA2HeKF+A0mShv1WDMDmOnVbicnBfsMkjzpMBFeB9V3Z2N
BEWRnWHuMsGI/XQCTCQCf+pzS6TqGj1I7MFpgF6QcnMmQ1landviBA4DDC+41v9g4givUZPN
xtGPI4s4/9fk4prKzG2HQ7k8nCOPmjxUYkGonkXQh2KYzdAgSaEw1ypdA8ewrr+6ZvHHG86W
hhUN5eFHcTdX0C1G6hbCyAhJntQLHWTFCo/oAAB+e15LX1OsIvazwovmQVCUmcsawQJsp2Kp
vA1HwxSRxKYVlhG9abjc+mbOby589n3c6CbKp2vMh7YFXDrxwrm3miyJhZ74T1G01Hq+n1My
MWJEj3j3hevR3uGLh9/+sEfMaG7KgLX778UEzJ8qrYHMWtkcpYf9/LHu2X0ab+GN1Cqr7jCT
xsJvwySwYsFSxn+MxpPCVTcBP98teJy/Gd9P5ubJWrDJGHyMbNYseCxGbMDN29FMGptTR45C
AAcEFcVAUD3BHXpE/esbv4vVMP/BhswrGzsoNdpMdWXX+lJy3CmzFoACeH3b39xz+2QjmB9w
BqlMRyTMiIdl26lrDIb82SRItS3rYVrAMtAe3ouR5G8A025Ajf8eZX3dkkvapZI1tEPXVvAW
/kVhnpKIJNvLxbQaF1MNUEP27548cLt3vyTxfJnFLgyzhTsQtnq4jPimHoKp39oei8OMHN8a
/3dhHHMxyxGkkacXHIwPz2JIkW+RX6/nJ0KO6a0MjU7wtK9vMYK2h42pkyyLf5MbkvWmCFgR
MgxriK6Q8uZq7br7T6yCZLzXyl4eCuayka6UQSorT6ULAqP+gsTYCqgFVGYOlq/AoEz95QGv
R7+znFZwlajKkOs4yQ28Gsj1InHdSqGpf0dYMsIGeVn9XNBGv1Q/F6G222mQbQJY4xydGs58
7eHee8HOIodSpen1WXcxyovtxXyW+gfxvbggRNMoTe7d+NwAJvqaRedsW5qbijErZ7d3MXI8
aglwnbVoa1hJ+2UJXbQzs11JTqO5R2ao2Mg2vHHKu0VTwfKZxYGM/Mgw/XB+PEgUdF8yc3jr
BsxVFsFfSSvgrhW87AyEXzFub8uKEXF/M4TVHgfuVlNSgKb8RodwLvG3svvvDy+Ws6GxvSY1
bDVDSX10BeDGe0KcuKZDebXEP/vnzS87vaDDOdhcrsYzC5dk1UGcZtZR+jC0r/qOT7/nKOVe
hOggIDxU+rHDJlr82Zkn7GOUpByINr9saklRpxPDyhKFL4ek1FQS+GDxc8cv/yz8jnvQUMAZ
e/BP+O6226QCk0IUlDpPXHspTLfrTL6doxAwOxXlEoq/tUBgsKw63jgvgEUjbMtCmZAbN8Y6
AQFfTqw/WCgBiZ59WmDCy95RAKlIwp/blsrP8YEpPikhFVelzAR4lEJSx+QD+T+rjtqth34Z
b6V+QPemG00lsGlWDkLlybdPNZCh4E8P8MIuZpf5yKj0tgH8liCYYEjUrTnXuv0YEou9OQZb
lU4RK6sc/8RUFr2j6GFcDPp/LbOku6OeUhPocD4NAUmLHK5PBZBS0tsOpWRPvcB4lp4UbOOd
H4fUr2w1rhx55xYbv7+0Q0evQ2/Lmj6sAFhG3n5FhGeuaNP4J/f8M6T7wedXONg191aeoXwM
E/NLhrmF97AVhwbjfsH6fsGmvVAYLzGMDLKATTBmDDbxnGmtx3BU5IyD8kZ8zshuNEC9O6cJ
T4NoRr/9w6xC2wtwTmFWWX0Fdg8aONH2PPiXMfDvSdBYUMyWeNdAFkyXNc979CbsEVaHGfyG
R1QG6G0BDnuxiaXkHjF4FjhBBxgwP3SVZE38EP7TmIyvTs/lTGEfwON5RkJsE0yT+Ox0z4ME
S8AS7BggwKw4yM46Up51HneoE5+WeaJGd6bn4vHYM9mooszANJiSxJUVJ5tCYdljSZ3srtsa
0NPNkrADPrlkxotu7eWnS8hDSL8y5xhnnxXg9kOpROBKPNHNcHHOu0id6ow6pV3T4NrwAoKe
WGLddNs3tOFpgRbpJnX0IBAij9js/bbZan0hxJFVhLIZ/5gun/Td8qXJcfPUlyAJ+0JFgcT1
2sAWHwlnqjCzwAWpyiHTAkfZdfbt6RFVuUmasPM/NwbS5Vj0fZvj1wXvdQkOU2D0w4qDJGDE
ILqQeqhuFe/XmBX0rVWAU9MeB9OAQBByS3gnR+mm1DfGqpdJ0AmcDSYPaDvhmow69uUv924o
YnCXPMaPBuc0DYHvofMh/GdDVvfjwIK5yHgyfK13BTLXAkRVkfywk4lMEOSQAGAYb7U2ygvA
1odJa7ngKPyH3wYivoi2XxFwm9enr0fBWxWfwEXTZ3it4tQD0Kh012sPON2ZqNyneoD7h3a7
NcTwCUgvfVeXEoFgbQ+t5cowqa2GPgVDOlMd22x/0+6BwCRTxI7ECkK6OBMIi54LCtgIr7U3
RSSsO5mFdRuZobM1pdSB/HJ++B3GgnR9L4TIEAJb8WgknJcwg465wXV5xWjm1iP8RUbuZ62n
5PUkHLI0A9cw6pnmTCqq7rVu5+157ru8p4U1V799ES2X5hwZqIkIFixx5vWw/GulWOMRUEPS
SARTUstBT276mG8/fRPE0LMHjbkV3o5gJB0MPWLTiJa7YuNyLxAdvXs42/iP87QZjpWo+5MS
SvJ8a2VMShG6T8WnglUPP0sud1jVLgsEaNlGhU+sSNZQYfPklMlY/nkkrOAuGBt1zBQAKuRC
zJ3kj44Pc0VE1kHckW5Rp1XJwe/S9GLW/KOG6NlJzDHVnGxRJBctu7IklG6p1kISlQQkGGo/
6xG7vGtHe3bQTDKeERoNvyIq4Oeymjb7FjMSfTyhdUaw67Xkgrn47uKYafxCd5ZJwA51inWv
U3eoDXYyfYYI280TlSGTrOndnRkerS/esf7NUkMWgA90cfHcjX3u+qdzU7DcBL97VuX3wzC5
r6mpA7y22WXl2JHM0g6OfCOuNe1eloIR4U+E/q4apQcMltbIPY9XpHTpLx6ZQiqw3Lme+T7r
xtKKMJL/mY6x8rtBU2bDVShU2cFzYzZELlhP2RMvSdrPa6SuM/GMoKtI0tuXbl6D9pqvdaiD
uyKTFUlQbZfi4hoc6i7Hf1cJbboMBS66MJJtYooroXE2xMaNZPIU04GZCIeqiuID21R4n9GT
pbjqhW6ryuHDTQ8kTr67UG+5ohpcbTdLXXKk1OLlKNDpijbvFR5G5jtR7tb9oHJhuC+HjhaE
HXNf53DCYWbq2GKFHlhbdy0+HwMMUeahYINcbXvWznlXALHlj8cnAXOY1K7Thkf79qY//hrw
nO82hBLyaUUghvA6OOyG3u3OmeLfJJuNVVUC5fEW6YFW00Yhz8CALEWljfegGEJ/GLdKAb4R
IxcK5l1pMg1LCVG3rfkSYW5HnX+OlCTByRGFoJHsbERA5x1hFnE+emtSOXUY0mKs444O+8X/
T6670n7L3mnBlqoOgBQqOwzDzLET1fAbH2e5s2+wu6VGK26squEcATNf7dG4QNWDUP3yNGpC
g71vT8atUcxUKFLNCNnQXjTpqO0oyRBedFp27UubR782lmU5/dO8SSRi2YfRfuCFOP2HrYU1
TD9OCphgmnlrjCWOS13UuB9IvhYYC/6OPMqR87Gp2CHSLTGxGaCLLIW0Kg2hSfSYLBCahQON
p+0BckYOmZI64TYxbbCV1HsvKN3UeBjT5kA/By+90JbZ2SuHgAyC8esnNlj8K9SMxhOF6tx8
1wI/sRSf9WyBTi2L2NBJTUGucyvkAHDm+L/+ehh7Y63+xCsD5Ox8G8OjjfHqQ619Y9V37tmR
xRFT3KKbWHYWnG1X+bF2fmmSbMSTXsSlUh7mq04wbntlonx2KPypQy8rmcqyzrikarNRKoQ8
UELBTnCSxL77RkBS5i157ZROuLVUG9wM2uq9kndIk7W5NPi0EsqqnvO8HM2+ww15eCpaHQc2
01CcsGPOU4WKMSKWIogLF6P0uXld6+37xa1Zb362MTk7VJ+NhAoUppN3GazU1X7hUFiNNAyq
NIOnqB2WS4fEY1JvB8lBCVgGwlaFlbGuspTJD1vVvNLsjNJtrJCxrFsTBDvWFEadrSMxV/B1
J5kdz8JUGCY70JICvwd9tNzwvM9zDpF5BmiSkBfNUXUHOOf6vNU/eO9q/s09byPlMCPOt7eA
18IgOIIqIxUxDhnYLD9sWgaU/hFIPoluX845cpiClnzu6swq4SBBH5hOnfuJHcUDdtNtdx0g
cApxa0xL73OK82HAsNr/Pb3ui5k+lEEhmQ1z4fyi5Vxr0Jar+Oe308j67k0phE7t+GIRqLl3
CP5MIMLbVG/iUMYEWHsOKD+DYDNCZjNjcwkCS5LekzxPJpw8gE7zHTg0N3Bc2ax1iQ4hIfCO
f6DkDWzd4CuTmb9qjPTwX5plTnqSnko/q4PNKsyLTCcP4jn2YpkT0a9Z3FQ5KBMlyC4u3nsW
fBOCEqL2fmQ0w51nKrb1ZOItsEuX3okDFk5DiOLE2606WwJyELa4D3q7ID2q/4Qns451AYS4
ZyscgHG0+cb5lP2aWff6Y3039i76fRKnK9DBNp+T348Q8f2qc1znVXjdBm8KtLeM47Ihve94
vKQkaUytRn5Iw44Qri0mQn6G8hjlrOTcwTV9iSu8v2KwZ+Z2eP5fedELdg+AKSXtSzoVZ0D2
X5wJe4awWcvzpeQKQ+MTU94IpnYTJnyc3FF+9jUY0cgElLKCrUFlXBfwRyKdFJlo5YVXzRuz
ReaLQ9YIVYrKOluniAAbnahBY/lReStsQenfuzkdTe7W1e2Dengx0+yaP1suDE+0hQk4tpR4
jaRkJEXCJDo9vqueJe+oYx4ukeHFRX5UDdcWfcgltxXdD6Hb2kC8xSZ1CZ96X4OsafvFjwEi
uWke7VVyiq9/XbZG2vW8jKXo8w/sYQdJYfMwGTY3x424MOjPkRykWia17mIsj6vqnpBt0e0K
IqlwnqHOX1pHP7TE4VFzGxvNt2du75WRTZdxiYFe7jyZmdi8gncwg0Rz2iZBdAaxQVBKDl3D
E8gPXLDeD/E0X4BlutDgygwBS9AWf9xZ2m5yfXmHDv3u2BZolCtEhfC9gKVp7ZsDlL7K/o6n
DdBRLt+gewHrPaSAMv18tQPNU2TVV8mWwHmRZhX1UY1ZgUwaHFMj32hcWbNZLVNCAQzz9sd7
ELLmTmXYp4cKycWrVo6S+AoAFKogAlQ9iLxwsoppvAstLtFfBbONzo9MV9ByFfJs4WprUJI9
WapzBvWsZnkbEkL+jhRpVGQrgM1cx5bGyZQhqWhmpk1ZqS3Yi3LCLt3YG/rxf73DJCQM2WHa
he+/+FxG4xmzCQjhYpgrFeWUv/zt2Y/+UzY6t5qw3jo3HGpDo/PsRg0wGxKeILpImqJFetla
uGwGzqO7zbwRZLLZf+1Mfx24euLUobjYpPvnLcm+ebbKE+POo+7AnIXN3cQwlE+FmHXnbSTO
GCarUXOY++kpHkGHshGwr2sj6tlLTmPlfmA4AMyBsps4nrz/W4mhmt2xZFKq1XA1eKR0obQY
8xHbl3Isrl86/rwznLvcKrHyQqT+IG+2nui+dS2dHMAte/JAIOgSL9XW3KaczMgZCFs0IKJC
7DiTxjCowZua6xVPnMsJBsK9GzQPZncHxJl4olKbTtmIRLTxb3LtIPz337Hht/NO7fVCO65t
yN+SQv1I79csQpC5fgD1kwe/iZbE+F8V36xmWIolrtdCJTeTAeOvaCOQsbZBcE4NPSWTpziT
Wq6PV9GXwfG7ficWVY6ln+uGn5dGpntcWR2ISC5CXHWbMisDD+bFE8aFDm3NRIk/spzOqX8I
LIP4yynuV0ifN9GtKgwPT/T1CrMMunlAbApSs763K7p6zEfcgJBcK+n+1xXHGRH9DsUjFpeF
bNtXVRZomCChyJBZMtHfnzMlCmK0diypzqPef1VMapYfsyrj44DRKjRIDWIcRA7EX5jwT+Og
Ljt8MabiguhQzldt5Hr5bhONGqNIvYsm1YUu9kZimGkXx8nO4tAR0+cB1F6PKRh8NIO9OU8M
6qmhTmpN1UJVSJKAX/YyEHNYM4qsLpNwp2VbXSQW5pRXDYXA+um0DMf9elKaM713cblZDqGU
IT759+RIuLwfIyuzub6ZkhtqhTsYk1Qu8wgsDBzXW6d3eU/h4tSVfh9Ox/kboWR5ecDc5PAh
kv9u1GgTSXwAMtWMNJW5DLmNhNw0cyy804NvUkZQRMqa6SLFR8QgHKpI0XVY8ALlNlUOImQu
xS6uWyo93ZUpnTQlobvd3IXPIm3one3d4FKUvnfvOnt8gbSUI3legKF3oCBJqJGimB8xFYR2
BJCM66QQKo/Dk4bHLdRSZRgPIzB1TT6yaLV34nNyXaB8xM6r7JerylbfD+QiSPIh5BUqs0pE
CONCGQaNuN3It+Rn0bANpMF00B93ZPLgvkvKYYe/m8chWoydSrbBuycpeWJzkz6tkruxVGi9
FSHwsrjZh9+AWm9QYEE4rkiH5aYIQnzPzqkswLok9eKzTJABHfMGOXsAbxzhBB4qXpa/U64w
Zp8YF0VDjC8FbMrH0etsbVS8h5yhuVD8omcm2tzPRBIaUpsoaXg+v4bETX1xjh/+Yd3qzA3/
bZq9eE/y6gdQBpyqx3vkR316QHt2yl1wqXtpAcRz01o+xXEpAylk7n4YGRhzXRhlWBrYUOOQ
88Ciy1Um57zDedG6QOMz8AEsC8jimH2jaQwVRV+1kYOFU1Qe4lF/tSzKc0OzSw2xWcdHYvcY
i9Lp1GUapfKTmuhm8FyVYqebjXTS/6t/5FD8eSa2cgkMA+0WzN4iXFDhbmwYdB4VhX0R4UpO
YDHRS2CYQJ6bznWwnlVRoZr5Xxk3x2BY96sDejLhRP7urbtGkwL9civ/ZHXOM6nSCNKOCkwR
73vEILeaTts1uAstvr6KFeYlQsQh4GZ/iIM/+RnU2+rRmFOAGs+Q4tlYa4TT5mKqUU53aaXl
RLotdD/yN+c5I/jDJ1F1dME5M6l7B7FnDUrLIVpliBdPHnNBM1/lAVY3h8TQfcIKQ9hWE1N0
9YgO6siHAwt3DFsJMzp9wbf4kD7VOlBf6zlmVjDn5u8OqSt77ViYOouCc0/iIG/A7f3zYiV0
9ovmgwIwAQNBn9+B5pfuS6q4XqjUXauHDNqjzfZP1YO5zQGfQLXaAemlXAjW9Bo3+X5gZI6h
5+dp1YPTX8NLDqwVqiIzskOQdz5/61qtbvzcYQshC1KwPLtmo5QgpVWWRMOykHEccumHiR1P
sMd90fcRqNF36+0HdckYqub1Lg54pWGm+feCtoP8CoS4DpE/mVsVOv7YUIZJXHKzYU3nyuv2
LCYNYXSkbnEm8wOR5fksdlG/oxPT43EdX9653iaNNmudzS882a2y9pqMWiFv2cCsp9QxLDfO
E8QTyvuy4TKtkFK0HnMAo7yQKLuvf293gSymwXf9pjSo/W9BX1lvmow9bnPJZZSozdb5ikfY
NuXpu+etnncbb/a+1ZJHhPZG96kh+HuevTE94XzmUCU0M8qR55VFcjxt4KgeSb9Mjr3AvtSD
Nyy7AU17e80myGpEWnPI5TAxDt9al8ApDeyNq9Zq559h7RpskigpARo213uASpvMIB1fSQ1+
fU0vRhj6ZXSiJ/jXsqRBmk2pwbZ8TQ06D/BcUZoJCEQ2ENHflISlDIIp6JRbReNilXijMCz+
C34thgoPTmObRHsZ18LXx64yaTHiIaKlbJjswE5Cb/VRYu9HNIveJRidzSSdooEkIoRL1tYy
fkCkLETqj1Fh7BXw55iS1DnlRRNlQmrmAAjQVtYr1AQS5yyO2nE5G9nIEpUcg+aGv9WtasO6
1Mcw9xGb2ttPTt1ut1CWDWsGDvB1RXq6heDzTZxINBvAWTh9nIgCWQ46f2AU8Va/APOE8m88
yOBXaFmYmnj85bAVxJi5rytq3+In/UHYSLOvkewrJmGIRsJywEqCd9bJ/966JCgGVg04FKU0
zyYydI2259fO+BG791EA1PjPV8Eyi2yQvkeZvR5MFCwPW5FOUJawM8iPb836LbT3uisU1BwU
X1GDxX+J+rR2m2Sd8FcCdf/7B7rENLBzDE240Qaygb9QYaYQAq9xdCL/Gze84g6L2eRWUo40
TbEWOPNHqM35mRn3jbO7R3plRChuxsJHc094+/FtBJPzLwQwJWN5Ur3ue8PQrlXW8YlkRZ1I
fSqrOmHdx6I4j6yVrpu9R2BwrtM/jWBOMfwxPqTLoM/v3rhhK/NNeWytwTHnnypL8w3c2YJA
938W/4vncAcNN8PE/s8+9WAbAwSBJ4wnTs7zpsNiY5oGxrmNJplMTb9JWQGLm3JCKqk9fduJ
dqQKh84CeQ6SyN0IZRfm1QTz8grEsN0eqIvXi4qgYbz5gjZhgwyFnVybzLXonqw5VzMunThN
hHsL0d7nMu37covd7437DL5/XkOaxmfwqxElWV3/caL9i1uegp7O3eiwyLe3YSUisAhocfI7
zbitNZodA0i2NJDB6wY3FwOdcVmDbEZgpLrFgvw8uyGOXVC4s3XnxjwZWBW3lNTc42i87XUj
tr1uWljrI00/eEUgzvb751HKR8V/jtfN0KiS9npZAhLMTMmHO5Gs8HJKL6LaHYmj6HL+8ApB
RLthXP/8X9gJRAfEIs7X3sq7SYYRoQzaOBWGT2GrlnOPlOPPiP+gN3BES6SjR30HyXAs48e6
eMQfbS5+kdZOdwh7I9WJ1P3wPKIi5STMJrwpqA+0Of4oIipkIhFmGbUOkVHKDSSQaS/Kjkhj
naej0DeEryZ51HopRdCA6e5Kj1VSiv2dE5Ys1E7G+6aUbgbYwiUgONHj1yg7ItTEUqrWDdh6
Tk4nFeRouwCA3z19X6S7Wqps+CIbTpYKDFYkD3UPzDd0ck5wRhwQ3IQOyRoXhkIpJAhfmgie
FbKuqHO2fy6MnF3IQsfHXChfpa0kUrLWV7hAn4ildKPERNOSqfDy5dvJLGq22TRPPhciSz+Q
w9rE4fiNsy/ZkxH303YGj3I0umvEX3c2M3KV1V/JJXx89VG1gLl88iOcOtsrs4s6/0Oi8VuB
b7/q3zh1egINDfXITSoLAG4O5MYamPeud9dpztAvF0Gh0vu/vaEVWjllqlcllWw4dNJ1srhT
zDcKqi3OXJFqk7RsX9kW1yuvsJD2NTJKO7y+vm2zit12+0TJbtHuRi1XvdbvyF/ok5ItMfE/
Qw3MREJr9wuhZyDGzJJ7XhPdg6jNyUrd9iKi5Stgu6TfRNcfSQ5z/0l6UjHECciLhZRiP2dI
+W7winIf6ASDLMitJMj2VRGkQv+R87BwYogDB51e+VT853trShq1fDaeM1MzGBtVNPRLNzmD
a+JdJZRjkq5z0M2+nPnFM/QftTfZVM3qgxyfOJfMavsvxQ3vojKURzsMr2fLvgrhdodTHri2
TkedIKvCcN3KoZdAC0Fzy/sazR5UG7Foh1ak0FSv6KzVcVtL2415zSd6Aj00cwqGw+dF78I9
tFhpgNY/3Qato6cuyN+MBV76NXWhvdmdKkQjhz26LWt+UgHln68hHeF8ozPY5ZKzE4RgLSBs
Xs+EAndGUreCQqXoZqNfB6FdVK+xfq9XttQcI3RNdgUYP6hsvXPWbvuhywPsav7NmB+3rQHO
VNrMSoFAu0iLQtw3RacRF3hi1rJE57c81xlkUSrw6jiJUy0buzy31U6q/Yae4eOFBwtma+wo
RLyEM9dGlX+iq6IRhWqD3V1i5aUSAxQO1u22W3lPvdNh/8cwi2F2aLk6zUNpSwYBciPHzRVu
P+nyUgIGZw/fyQlsepo7+Cv7mwMbqMrfARq8xgfOtPfW6TDdcLkHWcgcOa9BFmhBzuQgMetg
t5RURvSh35/KGyv0GC1mMJDi3ogEk5CkQV0TStebD5P5goE63EKYZAcydFBpAe4Y+7Yn6II+
3WH2jJJIZLALsUCyAwnuleeyWKlhxGaT9xzyi01lUiKYPynE7+C55BKHNCijPa83zTeeaMW9
wY+Vmq+MMQEn4Kdq3EOOgY88GfrCQkEpeULTYW8aRSTQKms5dsaPW2cmaflQ4Yn1xGiKvXrq
uSEtZFe+u73NvEuRC69j8CZnGoEje3mu31K0nBwk9KspdtajI04IvFJfL7I7dk1kco0UXXjv
DLBVl+LXCT+cORyaj3BzFyCnY+STWrSm02SQ1FHAjTHWFfn7yejvnBl8sjp9RocsB8LuIS8M
iJe3J3Hh5Xzr/qeE/G685h563N2p15Hjyf65BU7vZCfOR5R9URbVHewz34i2sb+ufukFW1vX
UFalQ70z+WA4/t5qs4quCAfoJ71GQGJKL7ZrQaZt66RQ2ZVixLhJsmhOFlBqab2l+zoWI2iQ
2P9U9CZxfRreUoAAxb9+cOYMhmgN2jJZvXQ+/9NIAbyUjLeNfIteCxsfpstKvKfHAR6WlUvZ
Wn4cDaz0b6SNUkXLHKOTZvwhnGW/KpQOEcY7+t+wA2AEQn7tq4PBPSH1VrBvBEF0nJOqGMHj
tQKH630iWZvVno0UZZj6of71QFN7JcsHbMO/hv262F+dVA2lpW+QrlXq/bmu9DY4VmJmxm1d
SQ++gfmZpt1uPWfuTWxNf4rD1YGh1omC1PetZBW8zGYonVTU6CaG4uQIgAKmKZkVc15pqX5C
HCw1jdXjnRUH5nI8PuZAl/0vW+r1Wo2m5eHKLSRleglTy9S1DvCNa7nXkHvWY/7hQMxZdDOb
ditl79E4d5vr3R8kSta+8/vlwghoX0Wmmnv9QVSBzljA/HciJKR+nTfqx0b/DqIz4f3DZ4hZ
+nsN/oMvvKYnpUizzMqCppy8MRIQ5SqRzpl1NtpdIvbRXmOYv/eQApxxsGOFcG3veDVh6fVm
iB4unUa+RHgciAThiMuEVkJApk1kqS2vGdwH77q/6osQu505it2JL6s2ZWSFMouXg5J2wO22
q/M9nadcddRZoJjgWmNx3dUyTqM5hvJlO/zihzOyxqp2aFCvy6FRI3IItR5qQZkaoEbwkqlC
7PBPDbZ4oST6XDH7M0W42mqONucfTo4PCIL/ZiKskBBAbVV08Rf2XSz3YXW18x98CX/VN9bO
Oq93EH8tzLllKUAIolzkKFefSAemGB5gZZeXxprbiX/V6f0AAxujrJybBVzlEH4cTRTIXc6b
JIFxqfnhdhzIiwd616LyiY/3Wu2csqXSdfdnCiGwWi+cLcb2XdepsZMIQ5pG9DSH7RO+12Xv
C5V4vwmfWr72xhlKvJP2URU/ckESTpuQYxu96ic8G1TxyEhCmPN4zpNMjIdXd6M8k0/AcpIG
VultRQBPi1NacDDjktxzbiP6E+Ut2U+8ZCjY55JFTxWOxzPPpxzmafAbhHjJ8CHnsmsmkf2B
E3j8jEkEBdra3iK5OsWBJ5VKBxWoPSpD8yv6Sp/2WV4cB2uxz0eZA3nemUQqHk3uWFG1c9LF
lPaODlymkgDzrJ9uSDQoYjwgRG2b1ocw+v/SYXMUu5gPt9Lfk0tULCtvrxNm08jgwOc9U2mG
UcPK4g7UhwAzX/CMX1NN/DKfItotrp1RF+t/izjiv7akZfanypwkA/VCzdLaDcr8xa1WQxKA
ZryaX2aT1jnGTjjjPJjg/70ugbzs39T1Se87SSwE52GlOl1iGSdfXZA9HGnLz/rdHbq8bh2s
gGCLrLKHyJzlMsZ0L8gZnjpqbjZ16sObmvodfNqWQJvcawoS0BVY1VDKLgg+666jou6JXtTp
UIAGzTCgKLGc25q/biCj2uqzvIpcVfzno4J7fRi8SWMPYSxstyGpznb6TzXHZRXsoZhCC0FF
Y6EDUQoCYCynpbvhDU94ROfLqLmv8WokCHgzn0jnwrLroRVHA2E3qEopPGQ//quYPfUF6IDD
pOEVg03G96MMDxJWfHEz4YHj+8sc9I9Pfb86u2Vkslz80p2zSWEspu/lQ+m6if5JOUvmRAU6
dW6nGC/wJ/ZzhKXb9w17pAQIoyxO4jAueKOUhreSlAZDIOVfTb6yqe3AEyFSVd7hYaVXJlTQ
BCNBwq385LgGQSDcjNjqeMT70vbyPcIZXV4q9gAhI5ImOoN2ky/ny/Gwq/njOMZSFcQe1T8Z
0XSmmPqDIo1lE+kMaIO4Q73bfgocNzsV01CLWg+zfN2HKDn1RLlCcNxhIkBRJ1zjSZiVJD7P
+OVjBQGcluuyQEXvfk5aNlI9GejxD2SJAWe2aOksAlJHZplubj+PtjVxATmH2VHXgfSmwsrQ
FPCJYhOytAHmOb8m8nHiDxV2RUC4An4BJr3E2Vjd7b8tBQhfbSzg16tYtm8BCVidZv3QzCtD
1pfuGIzUX9OY4mSkmEJ15pxLN3PCezNhKeHLW+oz1dGNiPB9ThUYnv3OsJcXaAs18jRbm5RL
JlKpUHaA/bo7y6QEbFEp5Fcl+RtSEI54GgrvDfB9BEMPeJnE/XpMDJm8Yvbl1RaiSgl8EYcz
Vsvy6jOfGUIWUpkr6JTRCHZBNONKQetnPxsmVq/HxBfvm9GkFsZhNuJYVuNb8634ju4b1xlw
ojKygj07kw+oPrqOPZ1URKnbD4UnVWNd4vE3bnc5TMzZN98FOkYaY5QFmWxhuFQf5FkjLBlm
y0Q+ytFaeO7ZbB+o3uNd/iKylK6fXZZmmQb1fgsrQ37P70pTxZsXH7dKaI34t7LkzMqdF2oM
X/ORGYYRVafK1I465viHE1Oz+SoHGl9CCHnoE9DqdKz9+hTy2AXpMCYxqebQdGExddWmjEG3
0XpvaDGxWetXwuUEc73URBpCfEzF2hMiDhzSSrUzpUTZjIEW3w+FkbLm7AqL2yNHJYe/XIO+
HFscUKh4mcFJFaaTa/yEm+mbjdvX/h5RK+NuTTZzhAY4YO3/bA4hEaPAmp9g2Yeft7OetLJP
pJ6tbck+K7rynfvuJ9b4phbISYeQdMeRS3sLXjtW9VJquy8USYuBMzrWSFYihveAXt5WZfTO
uytG5MQWOVNyvhkZVOtxnw8GrIJUoj7iHVRHU9nCDuyq6iqlwG1D1/Br6KOOUqQoxpPBd9jY
qQr2oqnq0k7OhCN2x9aty/xprwL15uPM/s4Y/0L3z5RIjcZg0piODzJBi+x9uzrlWgQ6oBEb
fINo8jzd0OoAmqDwKucccIN/+gbqe2Um01GnBHvpwLbCRSUcwk6K42rkWk9w+JBsMzbshqfC
rh4Dcoly+ig8Z2Us2U4HiL5Ax4A1bECzihIUs7YzV5um+v/R7dauLztnmLHWvAHQscJ9fMIm
BCEECrM06C+FN1c+a+TXmGQYqBQ34VUhgG7lmsIcCC7eHFzldcTbuZ8AqRXSVCU+kHtg59Gb
igOc6kQZUd1cTYxx3MuhOO8sIgZnVoIfddHyTHarBDxsiQ3kMMg+I7Oro2XNwoYPy8X/ZRHj
J9ND34ZfObPsx94i3OFRAKTwPoYGFm0wtTQS82hPdKAsqdtFMRS2tXjfzUQk8FV9oKdqi/9J
IZAn6aBiaIqV4G1Y8KV30bSQHKHrxdxQH901Rjr5Y/mTmPlnev709LT+TUYuKUwnjZr+gnFQ
aeuAH890UY3Re2yL5OlZMKZ+0Jz81bZqzVimt1PmRbjLUzT4f9M9U6zWXuBOV45KGtYQyBSL
6pCoUXXVJL3/Unshcf5qc6C5kbKhROLwgY/wS2fXHvi8Lzo/IYqvTLvGgIsHvXy/p8ghqsnz
E9b1JUjYc0qmaQYXwK/YSf6eYe6J70jO1XjWEGzq3xZUuJ+p+2yc7LPyt0vie4ZM3uj1dXqd
q8+0h9tiTXk4BiTuLoGRnGvxGRj7NuxtpVZNX9CKCue1J/i+UjEm3nZ82Cf6uGPexImaB20t
884Vd6fH44W0ZePRnvSuj/MujsOppY0UnP5c//P1IEez4nuDiFIKMqaMTm7rXtAEQJQoCoZ6
e9TZPDvUTAB2z5ewgKgOQ+rzcOgPavGYDsfN+Dq9cc93+as7TgHfZSi9VDyN4LZsBBd2viPS
Ajz4Rwgf653kCXnTpwE5UkbPwFmYAwzbwY9pmTb67IjNq11vl3bzg3oN45FgJstt5NhuZe8l
/YWRWlSeRAh5JDtJS8sDtKBAIr7cgekuWjSdG1Wnjcv6SPRlo8z4D6p7QBeBOw2VsKZVaj+x
zrqecSFQpCJ3hUjcLfhAcCtqsTTltrPVR325f5lBJXRZSGghAWjamHx8Pi495+cOpy9ndEvA
OwJwtftvpfk0KDd1cklP5oDsa0TWtDPGbN9sGc1WywGhV/mjg5wHE7sqtxQKtSavy7HUmBah
xhnLIUh9NcAod9Fhu/VwGaK6VoaKiYRzu7avfVjXxzsDx6ZCAZhV5mRiQmd5WbSzZcxvuAXd
hIGlXQMLilfIMUWaYPljjrjogdWw8RXpWptq59YFty1Hd2E7AqPSpUwk1Ya9kLne1h+JGu4e
FMZ4eOmm0Bqvis+8hzUfx0Janylnxb8hEnFJptplQQV8OKREplDDxWmGMRRb93e6RKDONyyA
bRjR+dB/T+YvbcmTIUbR7S0B77/kxWRv/yAGmgSEhpbnR7sNvVQvkMas2Z6RWydPjmNdBHQu
j2FCXh1sCwXtA1ryradhVxbFb1YCXqCGHGMBEc5AupA0M1a+lrFj7FP42cAZixl5M7yJh5x7
N/QYxNqxa8pkJmL/Fv8HqZENMD/6K9wHbcH/R4MBLWFpBEHcWc8JQbnSfwQ/oLxWp3XV/t5x
xmlY+BUbNlrfIbK4sJ+neaJdFLKe+FMjyFW1MzzjMdtIRFjWF7FAMjzR3lwqyg1jQC9hZ3RM
6aTEM7d2iUtVOOoIOgbYyLX/aZIrAVho5PhCsQDOJjASjvPG0D2X/o2xPMKIN419SWLVSBML
8gCviwGaIjKDF6JMRc/KdbzODb0A+Oi9fU8ArzPnNzIbQ/FAPPcqPgW8y3wFSAw9EH8P7FGT
evPRR2ApbSsKMRbuj5FAW0cVuQ6IDMsedX/EX7KHAFJUR1hGu7PRQq89K3UE5JXCmV3/QEbs
oNrvg4WefZ9jYaKCcWfeuj0FpnyjIvEwj4ACsqiQciTFsoKblTwdaVvmgRuw3Y49KKq8uApL
U/bWFouLxrkbkpnA2Y3bDNRqCRVo45enKwTroccw2ehV7rmGgpv4vwKKXO19V0b458jQchTe
jMrvIwJH/6D+4wiw5O4pXi3KOEuLqwLH3oosn+S7lr/c2W3UVokLXVDPHMssN1Zmb7XLIjQ1
1ISWAxRDWNIELveTIEFNn/t/lhWZobVBQPm8PgsYvrIIjRIqHGzBCJuOjjv/8A/VHJ/c9yha
RaZe8SrTBBtvH5A8tmYF4DLBJQiKGK0KIwmwMxywJND8Ffjl5dUm5Ya08C02tzz/lON7leuF
EnN+izS5MHyhN1Yk9camvdDwMGV1x/2s3JDF8hCqQzVaFAMlh36mKZAOd0vGhxirnN5aIsf0
Zi8u1r9CrYYdjqB1TSGKJw61JyVaFJcKKS1kWqasLXhP1fQvVIGhw1X0TJGkogf/8a7UBKxD
nhARDgXTBqnMYLKlpFj47nMf4NEYuPzrESxbCzc1UczmvVbAIV5ttw75pqRg+vqSrttm+XWP
291suXXYEHxSZFwBGF6aEOOYCp8jCctyowgVzFus2CTaF9aealRYXquymY2pi8ysHwD358vJ
QTIHOY6sKuQ34VtFmCvhzg3ZniXuxCAQmIxx7UjNFvFPMez/ouKjRglvF/niJ+7/pgw89B61
Rx5LezvHl2BWAl8zz3Dr0pez82zf3z1PJOnue3Ww+3TFQWhrDb0M1TbOf7IfHscFvgsZjEVI
C+QAYUza1F9rHNUvCWZzf285H7+IZSnG0DeWx3IQkcHPCSJRWOIIXV1Wb3yM4fvvddxBS7NB
0pG9z/fSfMbqWgf4/A51MaZdXXAMjcE38YeU2T5GovewHzM4w2N1ZWyD2+1KvXZ7oJtLeP2k
f3zxND0aqUp2o5smmLyaks6SkjNm87BhypqU4zft9M86g7nVcj2pzzWuKikDZhxJBH3FxHLX
i0SmreYCjqkXWOCyrP88RlCSgCDbV0jJ8pg9SjEhJGh+kVJVdI2tGY/fa1Chr8Ozzqm1WPx1
z+68YMVwa0SB3TJ1e3iG9J/B52LsdMxgrSGfMrMc+xvyNms2eMd3Dg8XROY9sDOic0CrB+Dp
gDIMkekBxn5wCB2C3TOn1KQCdMLnqjG5HLUssEB7hqFdml3LAN4WlcKOgMn3waWeHpoSp/em
bU3zJGMKueMUcrJatTlpOqvqk6kkgDyHJRIwBDCrPopR5+aJ5mgVrz35M8M08gOfdGCucc98
FJpLqarHy31pGXgccj/NYw6h3y5ig8BUWUXD+exj8GWClSjVlrKJefEx90NEMMsjb/ODnzeQ
Sf6yDEtykrJSqINTCQtMrCNkQ0Df9dA30nWDRHjYPqkOb5o1N4rUL1NGFYr00+N+/sUVlG9s
PIzAsrQ0NAqVKb1+JnMtvJo5uUY4U5+OJrjBECafIkJ5HHl3Ivn9A8Tz2V2WkEySMxzA7evd
n0/cK9WEfXTxhOLbatBd4zPCvqstN0RHgh1cWeqU5PrYTXB1TXqDqKjQko0Kt/NqsE3a+ICu
hsXhc7zX0Hh1kjHj1NxiYVp+FrNdzWFqtosP7rsIOsVtjBwS8vkhXEWtQJEspoxLaukGUTYk
tmHtkvotBB8do0DNK3EpVgTJvBOwYWAc8r8bsSCzBtgxJf5IGBCdhlHPaE65mEo0okZCiydb
WIa9RdWdC+CzMvw9U3USom6F/dFO2GyNPtwjWz/eTYb8LBRlAHZw4Cd6PDFS4Y/oX2NJMlky
7Frrlq6QG9TM6jVVIKgEBPa8SPgcimVTOOz9ulx5iPbgBzuqa24+NUmP6UoJlfvfRHuEJMDP
85S1tULgZC59evaaq4+BfJwZbX4BVPa1OF8HJTa1Voitva9LkN6A2mf3zx1g/h5C+ljjvrNp
DY6ra+DD0oQBPR+jyLeFPOEEFmUWlwbPY0mCeVJXEBF8qrDtf1xFeeh3jgGvAKNjqzTyjHIR
9st5GLGFXFKHtmgRCbuF+JApafNdAjkcRvNNvmNyyMRBd8cLYprL2gDerZrpvK6tN3B19CUG
yQTT2lST/0BnTiRqkB36zcClde8/3P9OIjU8j+Lmf6HbKFXTAjrjQOyZMMkhxn5Pv7z6mKRS
PsfGf/9STGEM5SFpBveLpzSNsv42znXHFgKux8o7Y988wJpP7ALynwERegh1b3VveA4efgyM
wXhFdbVClybCg1abyU9fUUZtmSONnTMYqZnQjCOc6UsSISYAeO0YweBPIPwQp8qvC0A4Iw6q
EAjBiWYcF9/7dSZKfA4sA7ic8vdXZRtjhfqb+/QlSSdeiFtZ638dhZpslnxrrOyWCkQC9zv5
ThE1c+hq9gjgnzjc1aqhTcNgOo4dPSKRHGSEK1bixnOSMwNr2we84tNGyphKUZekD4uOEwYY
0NJ75CnOtudCWdCoGNDFAKx6ySH9tODWM0upDR0qepLdNbId4nRLjwAAAQACACAgEAABAAQA
6AIAAAEAKAAAACAAAABAAAAAAQAEAAAAAACAAgAAAAAAAAAAAAAAAAAAAAAAAMz//wBoV1gA
AAAAAICAgAD///8AwMDAAP8AAAAA//8AvwAAAAAA/wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAiIRIiIiIiIiIiIiIiIiIiIiE1VVVVVVVVVVVVVSUiIiIjRERERERERERERERSUiIiI0RE
RERERFVUREVVUlIiIiNEiIiIREmZRESZlFJSIiIjRERERERElURESVRSUiIiI0SIiIiIRElV
VVlUUlIiIiNEREREREREmZmZVFJSIiIjRIiIiIiIRElUSVRSUiIiI0RERERERERElUlUUlIi
IiNEiIiIiIiIRElZVFJSIiIjREREREREREREmVRSUiIiI0SIiIiIiIiIRElEUlIiIiNERERE
RERERERERFJSIiIjRIiIiIiIiIiIiERSUiIiI0REREREREREREREUlIiIiNEiIiIiIiIiIiI
RFJSIiIjRERERERERERERERSUiIiI0QiIiIiRIiIiIhEUlIiIiNEOZJEQkRERERERFJSIiIj
RDIiIiJEiIiIiERSUiIiI0Q0QndyREREREREUlIiIiNEMiJ3ckSIiIiIRFJSIiIjRDRCd3JE
RERERERSUiIiI0Q0QmZiREREREREUlIiIiNENEJmYkRERERERFJSIiIjRDMyIiJERERERERS
UiIiI0REREREREREREREUlIiIiNCRCRCRCRCRCRCRDJSIiIjQkQkQkQkQkQkQkQyUiIiIiQz
QzQzQzQzQzQzQyIiIiIiIiIiIiIiIiIiIiIiIuAAAA/gAAAH4AAAB+AAAAfgAAAH4AAAB+AA
AAfgAAAH4AAAB+AAAAfgAAAH4AAAB+AAAAfgAAAH4AAAB+AAAAfgAAAH4AAAB+AAAAfgAAAH
4AAAB+AAAAfgAAAH4AAAB+AAAAfgAAAH4AAAB+AAAAfgAAAH4AAAB/gAAA//////oRzoMEAB
acD9QwPABcM4niYooxADwfgQJf9/hwDDi0QkVQQS6VXs7FEHU1ZXM/8xiX381BUcYCAoi/Bo
yMA3D7dFCFBkViYYIdhTkRUUMlAOECE7x4mKPHQqFhEMDVdogKzAagLxsBIRQP91bAyKNAiI
g/j7v1QBdQQzwOtB0Ns7A/d2GOhh/xwCmbkbAVLx+YuAjDAUA0M73h5y6I3M/FfhdWwIfXgE
ii4JEWd6ObH8D5TYX14pW8myHIGMZAx8VnC+YAQMV42FnG/zoqZQamApFSysDT0oDYgs4PtO
jNcUvEb3AIB9/lyLNSTFPb/gReF0CiIlVwXWIQpo0LAvHYC93IlcoUI8ICH+NeGhORA0YTAJ
amXoMrv+EFmTP70Kg1COyiaRIEGwBq9yRAhq2wUoxEaj5B/IFjyJPbcjLXRTFDTobEV2dSLG
AxU4NXxQUVoSCXVYloUSwHQFVE0TRhUjNBEUdRkPagHnMEgSAvTQkDEwwhAAtDgwQDKQCXQk
EENVJ2yXzo5pz20KYQifdo9lIO9F727vY+9y73nscCtl/GTPJlftbyObTEQN1i/lFhTNMGJK
nwpT2WtZTrMnXC7zQ/NadjOoMXAq/8OFPDVkpy64Uw7KRoGfZ5loFXP5QlSRDoRrGQN1+GVy
9m8AbmZpZzl4LmRxbOEQQklOGEFSWRBGVgNQcm90ZWObLqN4tjFgXAAA4AHgAuAg4hDOEQQN
6Ba+EX2kDnsog0YiAYwoCRCJIBZJiRTAwp8BFYADbwgUB5ACZhPAAtAQCXBV/wO8CFIHQQIG
EwqOQigBdwFscBAon9EECBB5mYP0RPf9JhAihBDi947QAhCckU+9GAjwqwEZ0g+PA4BceMBU
B7ADrQRSAzjqrwAAAeAgcEAOS0VSTmBMMzIuZHFs4EbobwZzZUhhbhjtwFpyPml0OkZuFb6/
KWELHEEdVp96R29mUudzUXVyY582Tzqpaw1iYWQWEElpbrZueko9dE2+ZClsXbMiRvFweUlS
m+R0RkTAJFfBa293c0TfPuRj+ep5pTmgLRROYW1MhlBy8PJk45xMc2p2H0xpYjtTLz5UUJND
z+5uNA0YTGG8RXLcXOvFjE11CHjMTgMAAAAAAAAAAAAAAAAAUEsBAhQACgAAAAAAI7JxMaOI
Hd6AcwAAgHMAAFQAAAAAAAAAAAAgAAAAAAAAAGRldGFpbHMudHh0ICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
LnBpZlBLBQYAAAAAAQABAIIAAADycwAAAAA=

------=_NextPart_000_0016----=_NextPart_000_0016--





Envelope-to: [e-mail]
Delivery-date: Wed, 17 Nov 2004 15:32:49 +0000
From: "Zafar Ali" <[e-mail]>
To: "'Kireeti Kompella'" <[e-mail]>, <[e-mail]>
Subject: RE: charter update
Date: Wed, 17 Nov 2004 10:29:59 -0500
Message-ID: <000c01c4ccba$4d6eb1e0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Kireeti,=20

- L1 VPN (Re: Alex question on this subject at CCAMP WG meeting, due to =
lake
of time I was not able to come to microphone but I would like to take =
this
opportunity to mention that we do see interest in this work from the SPs =
and
IMO CCAMP should add this work to the CCAMP Charter).=20

- PCE Requirements.=20

- Graceful shutdown of TE resources, if we find it outside the current
scope.

- Deployment consideration for GMPLS, if we find it outside the current
scope.=20

- MPLS/ GMPLS interworking, if we find it outside the current scope.=20

Thanks

Regards... Zafar

>-----Original Message-----
>From: [e-mail]=20
>[mailto:[e-mail]] On Behalf Of Kireeti Kompella
>Sent: Monday, November 15, 2004 10:51 AM
>To: [e-mail]
>Subject: charter update
>
>
>Hi All,
>
>If you have suggested charter updates, please send them to=20
>Adrian and me.  Please keep this subject line (simply reply to=20
>this mail).
>
>The deadline is Friday Nov 19, 17:00 PST.
>
>Thanks,
>Kireeti.
>-------
>




Envelope-to: [e-mail]
Delivery-date: Tue, 16 Nov 2004 21:14:43 +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-alarm-spec-02.txt
Date: Tue, 16 Nov 2004 16:12:30 -0500

--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		: GMPLS - Communication of Alarm Information
	Author(s)	: L. Berger
	Filename	: draft-ietf-ccamp-gmpls-alarm-spec-02.txt
	Pages		: 18
	Date		: 2004-11-16
	
This document describes an extension to Generalized MPLS (Multi-
Protocol Label Switching) signaling to support communication of alarm
information.  GMPLS signaling already supports the control of alarm
reporting, but not the communication of alarm information.  This
document presents both a functional description and GMPLS-RSVP
specifics of such an extension.  This document also proposes
modification of the RSVP ERROR_SPEC object.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-alarm-spec-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-alarm-spec-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-alarm-spec-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-alarm-spec-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-alarm-spec-02.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: Tue, 16 Nov 2004 02:05:16 +0000
Message-ID: <[e-mail]>
Date: Tue, 16 Nov 2004 11:02:05 +0900
From: Kohei Shiomoto <[e-mail]>
Organization: NTT
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: RE : Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi Neil, all

INMO, resources in multiple regions could be optimized using GMPLS=20
protocols (note: region means the domain in which the same switching=20
technology is used). The time-scale of optimization is based on=20
carriers' policy.

See inline for additional response.

[e-mail] wrote:

>Hi Jean-Loius,
> =20
>
>>Hi Neil, all
>>
>>We do not reinvent GMPLS here, we just list a set of=20
>>functional reqs, that may lead=20
>>to minor protocol extensions.
>>By the way it seems that some of your objections applies to=20
>>GMPLS in general...
>>   =20
>>
>NH=3D>  Not really.  The co-cs mode forces some good behaviours in GMPLS=
 which we fully agree with, eg
>-	OOB control/management
>-	cannot violate connectivity requirements of the traffic data-plane
>-	fixed/known hierachy
>
>The latter forced requirement of the co-cs mode means one can have funct=
ional decoupling between the layer networks.  It also means one can choos=
e best-of-breed functional components for things like addressing, signall=
ing, OAM, etc.  'Choose' is the key word here.
>
>All of this becomes rather important when different operators wish to le=
ase capacity off each other in a client/server relationship.
>
For the time being, the intra operator is the first target.

> =20
>
>>Regarding one of your previous comments, please note that=20
>>dynamic capacity update is a key requirement for many SPs.=20
>>Here is a simple motivation example:
>>Let's assume for instance that a SP owns two IP networks, one=20
>>for business trafic (VPNs) and another for DSL aggregation,=20
>>both supported by the same transmission network; these two=20
>>networks are not loaded during the same time along the day,=20
>>and it would be highly useful to share transport capacity=20
>>between them and reallocate bandwidth dynamically (with a=20
>>period of several hours).
>>   =20
>>
>NH=3D> I don't dispute this at all.  The key things are:
>-	the timescales over which topology changes are effected (ie closer to =
the duct the slower the TE time-constants).....but in any case we are tal=
king S-PVCs here IMO and not SVCs (at least for the forseeable future).
>-	whether we are talking intra-operator or inter-operator.  As a represe=
ntative of FT I would expect you to fully understand that what is adverti=
sed and/or allowed to be controlled in your network(s) is a very differen=
t issue in these 2 cases.
>
As replied above, the intra operator is the first target. But as you=20
said, confidentiality is a issue when we go further into the=20
inter-operator case.

>>Note that the term "Toplogy" is relative. When you signal a=20
>>new TDM LSP between two routers, you may update the "IP=20
>>topology", as you setup a new IP link. This is just a=20
>>question of terminology.
>>   =20
>>
>NH=3D> Well, maybe....depends on how you are looking at this compared to=
 myself.  As per your example, when you signal a new SDH VC4 layer networ=
k trail say between 2 nodes in the IP layer network (ie a link connection=
 here) then of course you are changing the IP layer network topology.  Wh=
at I am arguing is that you cannot simply create topology on the fly (ie =
as some top level demand rippling right down to the optics/duct say) in a=
ny viable commercial manner.....esp in the inter-operator case.  That is,=
 one would create the link-connection in the client topology as a consequ=
ence of longer-term trends in traffic behaviour in the client....and when=
 we start getting down the stack, with all the will in the world, it will=
 be not possible to create a link connection where physical infrastructur=
e does not exist.  So at what the level and to what degree is a priori pr=
ovisioning done becomes a key question.  Further, I also firmly believe t=
hat strong functio
>nal decoupling is is important when we have a client/server relationship=
 between 2 different operators.....and I'd be amazed if FT held any diffe=
rent view here.
> =20
>
When considering the intra-operator case, optimizing resources in=20
multiple regions should be easier than inter-operator case. Again we=20
should note here that the term "Toplogy" is relative. When you set up or =

tear down a new TDM (or LSC, FSC)  LSP for instance between IP routers,=20
you may reconfigure the "IP topology". How and when the "topology" is=20
reconfigured depends on carrier's policy.

Such optimization of resources in multiple regions is feasible using=20
GMPLS-based unified control plane (note again: region means the domain=20
in which the same switching technology/capability is used). I think that =

it is worth to seek

Thank you for your comments.

--=20
Kohei Shiomoto
NTT Network Service Systems Laboratories
3-9-11 Midori, Musashino, Tokyo 180-8585, Japan
Phone [phone]    Fax [phone]



>regards, Neil
> =20
>
>>Best Regards,
>>
>>JL
>>
>>   =20
>>
>>>-----Message d'origine-----
>>>De : [e-mail]
>>>[mailto:[e-mail]] De la part de=20
>>>     =20
>>>
>>[e-mail]
>>   =20
>>
>>>Envoy=E9 : lundi 15 novembre 2004 11:36
>>>=C0 : [e-mail]; [e-mail];=20
>>>[e-mail]; [e-mail]
>>>Objet : RE: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
>>>
>>>
>>>John,
>>>
>>><snipped>
>>>     =20
>>>
>>>>>.....in fact a large supplier of ours recently admitted
>>>>>         =20
>>>>>
>>>>(after 3 years
>>>>       =20
>>>>
>>>>>of trying to persuade us otherwise) that they now agree=20
>>>>>         =20
>>>>>
>>with us on=20
>>   =20
>>
>>>>>this.
>>>>>         =20
>>>>>
>>>><John Drake>
>>>>
>>>>It's not unusual for a vendor that is incapable of building=20
>>>><something> to assert that <something> is a Bad IdeaTM.
>>>>       =20
>>>>
>>>NH=3D> Well, one could also look at this differently.....given
>>>we worked out the facts several years ago on our own and=20
>>>nothing has happened since to show we were wrong, then one=20
>>>could say that we know this vendor is now at least trying to=20
>>>be honest with us on this issue.
>>>     =20
>>>
>>>>>Those who think they can 'create topology on the fly' can
>>>>>         =20
>>>>>
>>>>believe in
>>>>       =20
>>>>
>>>>>this stuff if they like.....you will convince me the day I see a=20
>>>>>routing protocol lay a duct and light some fibre, till=20
>>>>>         =20
>>>>>
>>then we'll=20
>>   =20
>>
>>>>>stick with what we know is true.
>>>>>         =20
>>>>>
>>>><John Drake>
>>>>
>>>>We never said that GMPLS had a backhoe option.
>>>>       =20
>>>>
>>>NH=3D> Try this logic.....and this is only one example of a
>>>given layered network sequence:
>>>-	to run the ducts we need the back-hoe
>>>-	to run the fibre we need the ducts in place
>>>-	to run the SDH MS/RS we need the fibre in place
>>>-	to run the SDH VC4 layer network we need the SDH MS/RS in place
>>>-	to run IP/MPLS layer networks we need the VC4 layer network in
>>>place.
>>>
>>>Do you see the logical dependency?  Put simply, one cannot
>>>create topology on the fly....at some point in the above you=20
>>>are going have to assume some 'already in place/fixed'=20
>>>topology.  But it's not even as simple as that.......
>>>
>>>Let's consider some of the commercial issues here as they are
>>>rather important.  Ever tried figuring out the design rules=20
>>>required in some co-cs transport network (like SDH VC4 or OTNs=20
>>>say) so that one can 'create a trail at will' (an SVC by any=20
>>>other name)....or at least to some acceptable GoS (Grade of=20
>>>Service), ie probability of capacity being available within an=20
>>>acceptable (to the client) time period post making demand?
>>>
>>>Folks should try it some time as the results are rather
>>>illuminating. We did this with our traffic engineering maths=20
>>>group at the labs a few years ago.  Without going into the=20
>>>detail, if you want to be able to 'turn-up' seriously large BW=20
>>>trails on demand between various locations you are going to=20
>>>have a build a network that runs largely empty for most of its=20
>>>working life....now try getting a business case for this past=20
>>>the products/services/financial people ;-).
>>>
>>>And once one turns up a trail in some lower layer network, do
>>>you seriously expect we operators will turn it off?
>>>
>>>Bottom-line...as one gets closer to the duct the holding time
>>>of trails/topology must increase.
>>>
>>>Note - These issues are over/above the requirement for
>>>commercial/functional isolation between different operating=20
>>>parties in a client/server layer network relationship.
>>>
>>>regards, Neil
>>>
>>>
>>>     =20
>>>
>
>
> =20
>






Envelope-to: [e-mail]
Delivery-date: Mon, 15 Nov 2004 20:48:25 +0000
Message-ID: <[e-mail]>
From: "Stephen Shew" <[e-mail]>
To: [e-mail]
Subject: RE: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
Date: Mon, 15 Nov 2004 15:46:52 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4CB54.3C5B9CC3"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C4CB54.3C5B9CC3
Content-Type: text/plain

See comments below:

> -----Original Message-----
> From: Adrian Farrel [mailto:[e-mail]] 
> Sent: Thursday, November 11, 2004 21:18
> To: [e-mail]
> Cc: Shew, Stephen [CAR:QT00:EXCH]
> Subject: Re: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
> 
> 
> Hi Stephen,
> 
> > I was not able to be at the CCAMP meeting today but do have some 
> > comments on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
> 
> Glad you were able to review the draft. Thanks for taking the 
> time. The slides for this and the other CCAMP drafts 
> discussed at the meeting can be found at 
> http://www.olddog.co.uk/61/ccamp.htm

Thanks, I've read them now.

> 
> > It seems that the 
> goals of the draft could be accomplished more simply 
> > by adopting the layer architecture as defined in ITU-T 
> Recommendations 
> > G.805 and G.809.  By doing this, the specific boundaries 
> between TDM, 
> > LSC, etc. don't have to be articulated as they are just layer 
> > networks.  Also, the designation of TDM does not include 
> the notions 
> > of the layers within that (e.g., DS3, STS-1, VC4, etc.) which are 
> > important to transport equipment. Adopting the layer 
> architecture also 
> > enables a client layer to be supported by an inverse 
> multipling layer 
> > such as provided by Virtual Concatenation. Here a layer of finer 
> > granularity is use to support a layer of coarser granularity.
> 
> Thank you for the pointer to G.805 and G.809.  It is very 
> important to attempt to align the terminologies so that we 
> can discover whether the architectures are the same and 
> whether they are trying to address the same problem space. It 
> is also always good to try not to reinvent the wheel.
> 
> As you have no doubt noticed, the GMPLS architecture and 
> problem space require the capability to signal and route 
> across multiple instances of what the ITU-T terms a transport 
> layer. We would gladly look at any architecture you have in 
> this space. Can you point us at the ITU-T document(s) that 
> describe the architecture and solutions for routing and 
> signaling across multiple layers?

In ITU-T Q12/15, there is recent work on extending G.8080 to cover
interlayer call setup.  It is the aim of Q12 to have this work consented at
the upcoming SG15 meeting (Nov.29 - Dec.3).  If completed, I will ask the
Rapporteur to liaise this to the IETF so that the document can be shared.
In discussions at the previous SG15 meeting, two important interlayer cases
were identified which I think are of architectural importance.  First, the
case where a server layer connection is created that is then presented to a
client layer as a new client layer link.  I think this is exactly how FAs
from a "lower" switching capability are handled in the draft.  In transport
networks (with or without control planes), this is commonly done (e.g.,
creating an STS-192 trail from a DWDM path).  The second case is more subtle
and involves an adaptation of the client layer into a server layer without a
new client layer link being created.  For example, a virtual concatenation
layer over a regular SDH layer (e.g., VC3-3v over VC-3).  Here there are no
VC-3-3v links or switching points at all in the network.

As of the Q12/15 interim meeting (Oct.25-29, 2004), the G.8080 interlayer
material describes how a server layer call can support a client layer call
in a similar manner as a client connection would support a client call.  The
model recurses with G.805 layers and is in fact parallel to a TeleManagement
Forum TMF814 construct called the Physical Termination Point (a network
management construct that is most useful at the edge of a network) which
contains a "stack" of adaptations.

At this point, there isn't any interlayer routing work I am aware of in the
ITU-T and draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt certainly tackles that
head on.

My original comment was made to simply the description (and hopefully
solution) of the multi-layer problem.  In particular, inverse multiplexing
capabilities are probably important and the bearer architectures suggested
really do help this.  With virtual concatentation and TDM over pseudo-wires,
there isn't going to be a strict ordering of fine to coarse granularity in
multi-layer networks.  Adopting the suggested models accomodates inverse
multiplexing as well as future layer networks.

> Thanks,
> Adrian
> 
> PS As pointed out by several people in other emails, I'm not 
> sure if we mean exactly the same thing when we say 
> multi-region and multi-layer. It would be valuable if you 
> could read the GMPLS architecture RFC and the hierarchy draft 
> and comment on whether you see these terms in the IETF 
> context as matching perfectly with ITU-T terms.

OK, I shall look at them.  I understand that GMPLS architecture does
separate control from bearer and so I would hope that "multi-layer" remains
a bearer term as that is understanding in ITU-T.  I think the I-D uses that
semantic too.  As far a "region", I think the equivalent ITU-T G.8080 term
is "domain", of which there can be different types depending on  the control
function.  For example, a "routing domain", or "signalling domain".  It is
my understanding from reading the draft that "region" does not distinguish
between routing and signalling, and if so it may be helpful for creating
multi-service networks where the extent of the services does not have to be
the same while they may all use the multi-region path computation
capability.

------_=_NextPart_001_01C4CB54.3C5B9CC3
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2658.2">
<TITLE>RE: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>See comments below:</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Adrian Farrel [<A HREF="mailto:[e-mail]">mailto:[e-mail]</A>] </FONT>
<BR><FONT SIZE=2>&gt; Sent: Thursday, November 11, 2004 21:18</FONT>
<BR><FONT SIZE=2>&gt; To: [e-mail]</FONT>
<BR><FONT SIZE=2>&gt; Cc: Shew, Stephen [CAR:QT00:EXCH]</FONT>
<BR><FONT SIZE=2>&gt; Subject: Re: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Hi Stephen,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; I was not able to be at the CCAMP meeting today but do have some </FONT>
<BR><FONT SIZE=2>&gt; &gt; comments on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Glad you were able to review the draft. Thanks for taking the </FONT>
<BR><FONT SIZE=2>&gt; time. The slides for this and the other CCAMP drafts </FONT>
<BR><FONT SIZE=2>&gt; discussed at the meeting can be found at </FONT>
<BR><FONT SIZE=2>&gt; <A HREF="http://www.olddog.co.uk/61/ccamp.htm" TARGET="_blank">http://www.olddog.co.uk/61/ccamp.htm</A></FONT>
</P>

<P><FONT SIZE=2>Thanks, I've read them now.</FONT>
</P>

<P><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; It seems that the </FONT>
<BR><FONT SIZE=2>&gt; goals of the draft could be accomplished more simply </FONT>
<BR><FONT SIZE=2>&gt; &gt; by adopting the layer architecture as defined in ITU-T </FONT>
<BR><FONT SIZE=2>&gt; Recommendations </FONT>
<BR><FONT SIZE=2>&gt; &gt; G.805 and G.809.&nbsp; By doing this, the specific boundaries </FONT>
<BR><FONT SIZE=2>&gt; between TDM, </FONT>
<BR><FONT SIZE=2>&gt; &gt; LSC, etc. don't have to be articulated as they are just layer </FONT>
<BR><FONT SIZE=2>&gt; &gt; networks.&nbsp; Also, the designation of TDM does not include </FONT>
<BR><FONT SIZE=2>&gt; the notions </FONT>
<BR><FONT SIZE=2>&gt; &gt; of the layers within that (e.g., DS3, STS-1, VC4, etc.) which are </FONT>
<BR><FONT SIZE=2>&gt; &gt; important to transport equipment. Adopting the layer </FONT>
<BR><FONT SIZE=2>&gt; architecture also </FONT>
<BR><FONT SIZE=2>&gt; &gt; enables a client layer to be supported by an inverse </FONT>
<BR><FONT SIZE=2>&gt; multipling layer </FONT>
<BR><FONT SIZE=2>&gt; &gt; such as provided by Virtual Concatenation. Here a layer of finer </FONT>
<BR><FONT SIZE=2>&gt; &gt; granularity is use to support a layer of coarser granularity.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Thank you for the pointer to G.805 and G.809.&nbsp; It is very </FONT>
<BR><FONT SIZE=2>&gt; important to attempt to align the terminologies so that we </FONT>
<BR><FONT SIZE=2>&gt; can discover whether the architectures are the same and </FONT>
<BR><FONT SIZE=2>&gt; whether they are trying to address the same problem space. It </FONT>
<BR><FONT SIZE=2>&gt; is also always good to try not to reinvent the wheel.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; As you have no doubt noticed, the GMPLS architecture and </FONT>
<BR><FONT SIZE=2>&gt; problem space require the capability to signal and route </FONT>
<BR><FONT SIZE=2>&gt; across multiple instances of what the ITU-T terms a transport </FONT>
<BR><FONT SIZE=2>&gt; layer. We would gladly look at any architecture you have in </FONT>
<BR><FONT SIZE=2>&gt; this space. Can you point us at the ITU-T document(s) that </FONT>
<BR><FONT SIZE=2>&gt; describe the architecture and solutions for routing and </FONT>
<BR><FONT SIZE=2>&gt; signaling across multiple layers?</FONT>
</P>

<P><FONT SIZE=2>In ITU-T Q12/15, there is recent work on extending G.8080 to cover interlayer call setup.&nbsp; It is the aim of Q12 to have this work consented at the upcoming SG15 meeting (Nov.29 - Dec.3).&nbsp; If completed, I will ask the Rapporteur to liaise this to the IETF so that the document can be shared.&nbsp; In discussions at the previous SG15 meeting, two important interlayer cases were identified which I think are of architectural importance.&nbsp; First, the case where a server layer connection is created that is then presented to a client layer as a new client layer link.&nbsp; I think this is exactly how FAs from a &quot;lower&quot; switching capability are handled in the draft.&nbsp; In transport networks (with or without control planes), this is commonly done (e.g., creating an STS-192 trail from a DWDM path).&nbsp; The second case is more subtle and involves an adaptation of the client layer into a server layer without a new client layer link being creat!
 ed.&nbsp; For example, a virtual concatenation layer over a regular SDH layer (e.g., VC3-3v over VC-3).&nbsp; Here there are no VC-3-3v links or switching points at all in the network.</FONT></P>

<P><FONT SIZE=2>As of the Q12/15 interim meeting (Oct.25-29, 2004), the G.8080 interlayer material describes how a server layer call can support a client layer call in a similar manner as a client connection would support a client call.&nbsp; The model recurses with G.805 layers and is in fact parallel to a TeleManagement Forum TMF814 construct called the Physical Termination Point (a network management construct that is most useful at the edge of a network) which contains a &quot;stack&quot; of adaptations.</FONT></P>

<P><FONT SIZE=2>At this point, there isn't any interlayer routing work I am aware of in the ITU-T and draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt certainly tackles that head on.</FONT></P>

<P><FONT SIZE=2>My original comment was made to simply the description (and hopefully solution) of the multi-layer problem.&nbsp; In particular, inverse multiplexing capabilities are probably important and the bearer architectures suggested really do help this.&nbsp; With virtual concatentation and TDM over pseudo-wires, there isn't going to be a strict ordering of fine to coarse granularity in multi-layer networks.&nbsp; Adopting the suggested models accomodates inverse multiplexing as well as future layer networks.</FONT></P>

<P><FONT SIZE=2>&gt; Thanks,</FONT>
<BR><FONT SIZE=2>&gt; Adrian</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; PS As pointed out by several people in other emails, I'm not </FONT>
<BR><FONT SIZE=2>&gt; sure if we mean exactly the same thing when we say </FONT>
<BR><FONT SIZE=2>&gt; multi-region and multi-layer. It would be valuable if you </FONT>
<BR><FONT SIZE=2>&gt; could read the GMPLS architecture RFC and the hierarchy draft </FONT>
<BR><FONT SIZE=2>&gt; and comment on whether you see these terms in the IETF </FONT>
<BR><FONT SIZE=2>&gt; context as matching perfectly with ITU-T terms.</FONT>
</P>

<P><FONT SIZE=2>OK, I shall look at them.&nbsp; I understand that GMPLS architecture does separate control from bearer and so I would hope that &quot;multi-layer&quot; remains a bearer term as that is understanding in ITU-T.&nbsp; I think the I-D uses that semantic too.&nbsp; As far a &quot;region&quot;, I think the equivalent ITU-T G.8080 term is &quot;domain&quot;, of which there can be different types depending on&nbsp; the control function.&nbsp; For example, a &quot;routing domain&quot;, or &quot;signalling domain&quot;.&nbsp; It is my understanding from reading the draft that &quot;region&quot; does not distinguish between routing and signalling, and if so it may be helpful for creating multi-service networks where the extent of the services does not have to be the same while they may all use the multi-region path computation capability.</FONT></P>

</BODY>
</HTML>
------_=_NextPart_001_01C4CB54.3C5B9CC3--



Envelope-to: [e-mail]
Delivery-date: Mon, 15 Nov 2004 17:14:38 +0000
Message-ID: <[e-mail]>
From: Nic Neate <[e-mail]>
To: [e-mail]
Cc: 'Richard Rabbat' <[e-mail]>
Subject: RE: GMPLS topics and issues of study
Date: Mon, 15 Nov 2004 17:13:22 -0000
MIME-Version: 1.0
Content-Type: text/plain

Hi all,

Following on from Richard's comments, as implementers we'd love to see
something on the new charter for some BCPs based on GMPLS
interop/implemenation experience.

In particular, we have also recently hit some issues related to the
Interface IDs and Label Sub-object used in EROs stemming from confusion over
how to interpret RFC 3473.  If anyone can clarify what is and what is not
either allowed or common practice, that would be very useful.

We would like to work with the following simple example, where node A is not
the ingress, but C is the egress.  We've done some interop testing, and
found that in some cases EROs which we considered valid did not work, while
others produced unexpected results.

	Nodes: 	A--------B--------C
	Interfaces:	 A1    B1 B2    C1  
	D/S Labels	    L1       L2

Which of the following EROs, received in a Path message by Node A, would
produce the LSP pictured?

(a)	{A1,L1};{B2,L2}
(b)	{A1,L1};{B2,L2};(C1}
(c)	{B1,L1};(C1,L2}
(d)	{A1,L1};{B1,L1};{B2,L2};(C1,L2}

Further, if some of these configurations are not allowed, where is that
typically policed?  

Regarding option (c), it appears that some vendors expect this construction,
but we're not clear how it can be accurately interpreted.  If it is valid,
how can node A know whether B1 is the incoming or outgoing interface on node
B (and therefore whether is has to process label L1)?  If it is not valid,
can this be policed?

Also, is an explicit hop to the egress always required (omitted in option
(a)).  Does it make sense to include a label on that hop, and if so what
processing should the egress node do?  In option (d) it could arguably just
ignore the label, but that probably is not the case in (c).

Thanks,

Nic



-----Original Message-----
From: Richard Rabbat [mailto:[e-mail]]
Sent: 10 November 2004 21:46
To: [e-mail]
Cc: 'Richard Rabbat'
Subject: RE: GMPLS topics and issues of study


Please note that the list under "Addressing" that we compiled and sent out
is based on the Isocore interoperability testing.
The other items:
--
RSVP message contents:
1: ERO/RRO: choice of outgoing vs. incoming interface ID
2: Forwarding destination of Path message with ERO
Control channel:
1: Best practice where multiple IP hops lie between adjacent nodes
--
are from another source so we can combine these issues as well.
Richard

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf
Of Richard Rabbat
Sent: Wednesday, November 10, 2004 11:27 AM
To: [e-mail]
Cc: 'Rajiv Papneja'; 'Ashok Narayanan'; 'Eiji Oki'; 'Pandian, Vijay'; 'Ong,
Lyndon'; 'Hari Rakotoranto'; [e-mail];
[e-mail]; [e-mail]
Subject: GMPLS topics and issues of study


Hi all,

Based on Isocore interoperability testing results from the past few months,
we've found the following issues to have caused some confusion and
differences in implementation.  We'll list them here in no specific order
under 3 major headings.

Addressing:
1. relationship between TE Router ID and OSPF router ID 
1.1 where to use TE Router ID, OSPF Router ID and IPCC Address 

2: IP reachability (what ID's are reachable IP addresses)

3: what address is used in the signaling message in the ERO/RRO

4: what is used in in the IF_ID_RSVP_HOP
4.1: IP v4 Next/Previous Hop address
4.2: IPv4 address in the value field

5:  what is used in the destination IPv4 address in the session object 

6:  what is used in the sender IPv4 address in sender object template

7:  what is used as the Router ID in LSP_TUNNEL_INTERFACE_ID

RSVP message contents:

1: ERO/RRO: choice of outgoing vs. incoming interface ID

2: Forwarding destination of Path message with ERO

Control channel:

1: Best practice where multiple IP hops lie between adjacent nodes

2: use of redundant/multiple IPCC. best practices 
 
We're in the process of putting together what we hope to be a comprehensive
list of topics that may cause interop concerns. If people have thoughts
about other concerns as well, it would be great if you can email them to the
list or contact us directly.

Yumiko Kawashima
Ashok Narayanan
Eiji Oki
Lyndon Ong
Vijay Pandian
Rajiv Papneja   
Richard Rabbat
Hari Rakotoranto
Kohei Shiomoto
Tomonori Takeda



Envelope-to: [e-mail]
Delivery-date: Mon, 15 Nov 2004 15:51:14 +0000
Date: Mon, 15 Nov 2004 07:51:02 -0800 (PST)
From: Kireeti Kompella <[e-mail]>
To: [e-mail]
Subject: charter update
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi All,

If you have suggested charter updates, please send them to Adrian and
me.  Please keep this subject line (simply reply to this mail).

The deadline is Friday Nov 19, 17:00 PST.

Thanks,
Kireeti.
-------



Envelope-to: [e-mail]
Delivery-date: Mon, 15 Nov 2004 15:48:24 +0000
Message-ID: <[e-mail]>
Date: Mon, 15 Nov 2004 16:47:39 +0100
From: [e-mail]
Reply-To: [e-mail]
Organization: ALCATEL - R&I
MIME-Version: 1.0
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: RE : Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

All,

few comments on this,

[e-mail] a =E9crit :
>

<snipped>

> >
> > Regarding one of your previous comments, please note that
> > dynamic capacity update is a key requirement for many SPs.
> > Here is a simple motivation example:
> > Let's assume for instance that a SP owns two IP networks, one
> > for business trafic (VPNs) and another for DSL aggregation,
> > both supported by the same transmission network; these two
> > networks are not loaded during the same time along the day,
> > and it would be highly useful to share transport capacity
> > between them and reallocate bandwidth dynamically (with a
> > period of several hours).
> NH=3D> I don't dispute this at all.  The key things are:
> -       the timescales over which topology changes are effected
> (ie closer to the duct the slower the TE time-constants).....but in
> any case we are talking S-PVCs here IMO and not SVCs (at least for
> the forseeable future).

MRN gives you the capability to take wise decisions
regardless of the time you need to take them.

> -       whether we are talking intra-operator or inter-operator.

AS JL said, intra, for the moment.

> As a representative of FT I would expect you to fully understand
> that what is advertised and/or allowed to be controlled in your
> network(s) is a very different issue in these 2 cases.
> >
> > Note that the term "Toplogy" is relative. When you signal a
> > new TDM LSP between two routers, you may update the "IP
> > topology", as you setup a new IP link. This is just a
> > question of terminology.
> NH=3D> Well, maybe....depends on how you are looking at this compared
> to myself.  As per your example, when you signal a new SDH VC4 layer
> network trail say between 2 nodes in the IP layer network (ie a
> link connection here) then of course you are changing the IP layer
> network topology.  What I am arguing is that you cannot simply create
> topology on the fly (ie as some top level demand rippling right down
> to the optics/duct say) in any viable commercial manner.....esp in the
> inter-operator case.

I think there is sort of a misunderstanding here,
MRN does not mandates traffic driven connection establishment
(which is what I understand by "on the fly")
I gives the operator the full view of its switching capabilities so as
to intelligently trigger (if needed) additional resources.
But more generally, why are we focusing on triggering here,
MRN is, but is also much more than an enabler for intelligent
triggering through regions.

> That is, one would create the link-connection in the client topology
> as a consequence of longer-term trends in traffic behaviour in the
> client....and when we start getting down the stack, with all the will
> in the world, it will be not possible to create a link connection
> where physical infrastructure does not exist.  So at what the level
> and to what degree is a priori provisioning done becomes a key
> question.  Further, I also firmly believe that strong functional
> decoupling is is important
> when we have a client/server relationship between 2 different
> operators.....and I'd be amazed if FT held any different view here.

On the other hand, decoupling and region isolation would go against
efficient network engineering especially in intra-operator case
and distributed CP environment.

Finally I think that the topics covered here are more
in the scope of operational processes, which in turn=20
are outside the scope of the mrn-reqs document.

Regards,

Martin
>=20
> regards, Neil
> >
> > Best Regards,
> >
> > JL
> >
> > >-----Message d'origine-----
> > >De : [e-mail]
> > >[mailto:[e-mail]] De la part de
> > [e-mail]
> > >Envoy=E9 : lundi 15 novembre 2004 11:36
> > >=C0 : [e-mail]; [e-mail];
> > >[e-mail]; [e-mail]
> > >Objet : RE: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
> > >
> > >
> > >John,
> > >
> > ><snipped>
> > >> > .....in fact a large supplier of ours recently admitted
> > >> (after 3 years
> > >> > of trying to persuade us otherwise) that they now agree
> > with us on
> > >> > this.
> > >> <John Drake>
> > >>
> > >> It's not unusual for a vendor that is incapable of building
> > >> <something> to assert that <something> is a Bad IdeaTM.
> > >NH=3D> Well, one could also look at this differently.....given
> > >we worked out the facts several years ago on our own and
> > >nothing has happened since to show we were wrong, then one
> > >could say that we know this vendor is now at least trying to
> > >be honest with us on this issue.
> > >>
> > >> > Those who think they can 'create topology on the fly' can
> > >> believe in
> > >> > this stuff if they like.....you will convince me the day I see a
> > >> > routing protocol lay a duct and light some fibre, till
> > then we'll
> > >> > stick with what we know is true.
> > >> <John Drake>
> > >>
> > >> We never said that GMPLS had a backhoe option.
> > >NH=3D> Try this logic.....and this is only one example of a
> > >given layered network sequence:
> > >-    to run the ducts we need the back-hoe
> > >-    to run the fibre we need the ducts in place
> > >-    to run the SDH MS/RS we need the fibre in place
> > >-    to run the SDH VC4 layer network we need the SDH MS/RS in place
> > >-    to run IP/MPLS layer networks we need the VC4 layer network in
> > >place.
> > >
> > >Do you see the logical dependency?  Put simply, one cannot
> > >create topology on the fly....at some point in the above you
> > >are going have to assume some 'already in place/fixed'
> > >topology.  But it's not even as simple as that.......
> > >
> > >Let's consider some of the commercial issues here as they are
> > >rather important.  Ever tried figuring out the design rules
> > >required in some co-cs transport network (like SDH VC4 or OTNs
> > >say) so that one can 'create a trail at will' (an SVC by any
> > >other name)....or at least to some acceptable GoS (Grade of
> > >Service), ie probability of capacity being available within an
> > >acceptable (to the client) time period post making demand?
> > >
> > >Folks should try it some time as the results are rather
> > >illuminating. We did this with our traffic engineering maths
> > >group at the labs a few years ago.  Without going into the
> > >detail, if you want to be able to 'turn-up' seriously large BW
> > >trails on demand between various locations you are going to
> > >have a build a network that runs largely empty for most of its
> > >working life....now try getting a business case for this past
> > >the products/services/financial people ;-).
> > >
> > >And once one turns up a trail in some lower layer network, do
> > >you seriously expect we operators will turn it off?
> > >
> > >Bottom-line...as one gets closer to the duct the holding time
> > >of trails/topology must increase.
> > >
> > >Note - These issues are over/above the requirement for
> > >commercial/functional isolation between different operating
> > >parties in a client/server layer network relationship.
> > >
> > >regards, Neil
> > >
> > >
> >



Envelope-to: [e-mail]
Delivery-date: Mon, 15 Nov 2004 15:16:02 +0000
Message-ID: <[e-mail]>
Date: Mon, 15 Nov 2004 16:14:36 +0100
From: [e-mail]
Reply-To: [e-mail]
Organization: Alcatel CTO/R&I
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
MIME-Version: 1.0
To: LE ROUX Jean-Louis RD-CORE-LAN <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: RE : RE : Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
Content-Type: multipart/alternative; boundary="------------080605000808010105050905"

--------------080605000808010105050905
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Gentlemens (following agreement on JL comment),
please focus on the drafts contents and not on "particular" nor=20
"architectural" vision of network operations.
To be clear if one wants to apply policies to maintain blind and=20
inefficient operations from one SC to the other it's still possible with=20
MRN ! (BTW nothing in MRN mandate traffic-driven-only operations as=20
assumed in some emails)
MRN just gives the *control plane* (nothing to be redefined) extensions=20
for integrated opeartions but does not mandate any policies.

Emmanuel


LE ROUX Jean-Louis RD-CORE-LAN wrote:

>Hi Neil
>
>Not sure this discussion will help, actually this is out of the scope of t=
his ID,=20
>nevermind, see inline,
>
>JL
>
> =20
>
>>-----Message d'origine-----
>>De : [e-mail] [mailto:[e-mail]]=20
>>Envoy=E9 : lundi 15 novembre 2004 14:17
>>=C0 : LE ROUX Jean-Louis RD-CORE-LAN; [e-mail];=20
>>[e-mail]; [e-mail]; [e-mail]
>>Objet : RE: RE : Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
>>
>>
>>Hi Jean-Loius,
>>   =20
>>
>>>Hi Neil, all
>>>
>>>We do not reinvent GMPLS here, we just list a set of
>>>functional reqs, that may lead=20
>>>to minor protocol extensions.
>>>By the way it seems that some of your objections applies to=20
>>>GMPLS in general...
>>>     =20
>>>
>>NH=3D>  Not really.  The co-cs mode forces some good behaviours=20
>>in GMPLS which we fully agree with, eg
>>-	OOB control/management
>>-	cannot violate connectivity requirements of the traffic=20
>>data-plane
>>-	fixed/known hierachy
>>
>>The latter forced requirement of the co-cs mode means one can=20
>>have functional decoupling between the layer networks.  It=20
>>also means one can choose best-of-breed functional components=20
>>for things like addressing, signalling, OAM, etc.  'Choose' is=20
>>the key word here.
>>
>>All of this becomes rather important when different operators=20
>>wish to lease capacity off each other in a client/server relationship.
>>   =20
>>
>>>Regarding one of your previous comments, please note that
>>>dynamic capacity update is a key requirement for many SPs.=20
>>>Here is a simple motivation example:
>>>Let's assume for instance that a SP owns two IP networks, one=20
>>>for business trafic (VPNs) and another for DSL aggregation,=20
>>>both supported by the same transmission network; these two=20
>>>networks are not loaded during the same time along the day,=20
>>>and it would be highly useful to share transport capacity=20
>>>between them and reallocate bandwidth dynamically (with a=20
>>>period of several hours).
>>>     =20
>>>
>>NH=3D> I don't dispute this at all.  The key things are:
>>-	the timescales over which topology changes are effected=20
>>(ie closer to the duct the slower the TE=20
>>time-constants).....but in any case we are talking S-PVCs here=20
>>IMO and not SVCs (at least for the forseeable future).
>>   =20
>>
>
>No, why such restriction to S-PVCs, SVCs are largely envisageable in
>an intra-operator case.
>
> =20
>
>>-	whether we are talking intra-operator or=20
>>inter-operator.  As a representative of FT I would expect you=20
>>to fully understand that what is advertised and/or allowed to=20
>>be controlled in your network(s) is a very different issue in=20
>>these 2 cases.
>>   =20
>>
>
>Be sure I fully understand the distinction...
>Here in this example I was talking intra-operator.=20
>By the way, note that current MRN requirements focus on intra operator cas=
e.=20
>
> =20
>
>>>Note that the term "Toplogy" is relative. When you signal a
>>>new TDM LSP between two routers, you may update the "IP=20
>>>topology", as you setup a new IP link. This is just a=20
>>>question of terminology.
>>>     =20
>>>
>>NH=3D> Well, maybe....depends on how you are looking at this=20
>>compared to myself.  As per your example, when you signal a=20
>>new SDH VC4 layer network trail say between 2 nodes in the IP=20
>>layer network (ie a link connection here) then of course you=20
>>are changing the IP layer network topology.  What I am arguing=20
>>is that you cannot simply create topology on the fly (ie as=20
>>some top level demand rippling right down to the optics/duct=20
>>say) in any viable commercial manner.....esp in the=20
>>inter-operator case. =20
>>   =20
>>
>
>And what about the INTRA OPERATOR case ????
>
>That is, one would create the=20
> =20
>
>>link-connection in the client topology as a consequence of=20
>>longer-term trends in traffic behaviour in the client....and=20
>>when we start getting down the stack, with all the will in the=20
>>world, it will be not possible to create a link connection=20
>>where physical infrastructure does not exist. =20
>>   =20
>>
>
>Please could you point where did you see such statement "to create a link =
connection=20
>where physical infrastructure does not exist" in our draft ?=20
>
>
>So at what the=20
> =20
>
>>level and to what degree is a priori provisioning done becomes=20
>>a key question.  Further, I also firmly believe that strong=20
>>functional decoupling is is important when we have a=20
>>client/server relationship between 2 different=20
>>operators.....and I'd be amazed if FT held any different view here.
>>
>>   =20
>>
>
>Sure but who is talking about two operators here ?????
>I think you missed something here. What about cases were both IP and trans=
port are under the control of the same entity ????
>
>Best Regards,
>
>Jean-Louis
>
>
>
>
> =20
>
>>regards, Neil
>>   =20
>>
>>>Best Regards,
>>>
>>>JL
>>>
>>>     =20
>>>
>>>>-----Message d'origine-----
>>>>De : [e-mail]
>>>>[mailto:[e-mail]] De la part de=20
>>>>       =20
>>>>
>>>[e-mail]
>>>     =20
>>>
>>>>Envoy=E9 : lundi 15 novembre 2004 11:36
>>>>=C0 : [e-mail]; [e-mail];=20
>>>>[e-mail]; [e-mail]
>>>>Objet : RE: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
>>>>
>>>>
>>>>John,
>>>>
>>>><snipped>
>>>>       =20
>>>>
>>>>>>.....in fact a large supplier of ours recently admitted
>>>>>>           =20
>>>>>>
>>>>>(after 3 years
>>>>>         =20
>>>>>
>>>>>>of trying to persuade us otherwise) that they now agree=20
>>>>>>           =20
>>>>>>
>>>with us on=20
>>>     =20
>>>
>>>>>>this.
>>>>>>           =20
>>>>>>
>>>>><John Drake>
>>>>>
>>>>>It's not unusual for a vendor that is incapable of building=20
>>>>><something> to assert that <something> is a Bad IdeaTM.
>>>>>         =20
>>>>>
>>>>NH=3D> Well, one could also look at this differently.....given
>>>>we worked out the facts several years ago on our own and=20
>>>>nothing has happened since to show we were wrong, then one=20
>>>>could say that we know this vendor is now at least trying to=20
>>>>be honest with us on this issue.
>>>>       =20
>>>>
>>>>>>Those who think they can 'create topology on the fly' can
>>>>>>           =20
>>>>>>
>>>>>believe in
>>>>>         =20
>>>>>
>>>>>>this stuff if they like.....you will convince me the=20
>>>>>>           =20
>>>>>>
>>day I see a=20
>>   =20
>>
>>>>>>routing protocol lay a duct and light some fibre, till=20
>>>>>>           =20
>>>>>>
>>>then we'll=20
>>>     =20
>>>
>>>>>>stick with what we know is true.
>>>>>>           =20
>>>>>>
>>>>><John Drake>
>>>>>
>>>>>We never said that GMPLS had a backhoe option.
>>>>>         =20
>>>>>
>>>>NH=3D> Try this logic.....and this is only one example of a
>>>>given layered network sequence:
>>>>-	to run the ducts we need the back-hoe
>>>>-	to run the fibre we need the ducts in place
>>>>-	to run the SDH MS/RS we need the fibre in place
>>>>-	to run the SDH VC4 layer network we need the SDH MS/RS in place
>>>>-	to run IP/MPLS layer networks we need the VC4 layer network in
>>>>place.
>>>>
>>>>Do you see the logical dependency?  Put simply, one cannot
>>>>create topology on the fly....at some point in the above you=20
>>>>are going have to assume some 'already in place/fixed'=20
>>>>topology.  But it's not even as simple as that.......
>>>>
>>>>Let's consider some of the commercial issues here as they are
>>>>rather important.  Ever tried figuring out the design rules=20
>>>>required in some co-cs transport network (like SDH VC4 or OTNs=20
>>>>say) so that one can 'create a trail at will' (an SVC by any=20
>>>>other name)....or at least to some acceptable GoS (Grade of=20
>>>>Service), ie probability of capacity being available within an=20
>>>>acceptable (to the client) time period post making demand?
>>>>
>>>>Folks should try it some time as the results are rather
>>>>illuminating. We did this with our traffic engineering maths=20
>>>>group at the labs a few years ago.  Without going into the=20
>>>>detail, if you want to be able to 'turn-up' seriously large BW=20
>>>>trails on demand between various locations you are going to=20
>>>>have a build a network that runs largely empty for most of its=20
>>>>working life....now try getting a business case for this past=20
>>>>the products/services/financial people ;-).
>>>>
>>>>And once one turns up a trail in some lower layer network, do
>>>>you seriously expect we operators will turn it off?
>>>>
>>>>Bottom-line...as one gets closer to the duct the holding time
>>>>of trails/topology must increase.
>>>>
>>>>Note - These issues are over/above the requirement for
>>>>commercial/functional isolation between different operating=20
>>>>parties in a client/server layer network relationship.
>>>>
>>>>regards, Neil
>>>>
>>>>
>>>>       =20
>>>>
>
>
> =20
>


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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Gentlemens (following agreement on JL comment), <br>
please focus on the drafts contents and not on "particular" nor
"architectural" vision of network operations.<br>
To be clear if one wants to apply policies to maintain blind and
inefficient operations from one SC to the other it's still possible
with MRN ! (BTW nothing in MRN mandate traffic-driven-only operations
as assumed in some emails)<br>
MRN just gives the *control plane* (nothing to be redefined) extensions
for integrated opeartions but does not mandate any policies.<br>
<br>
Emmanuel<br>
<br>
<br>
LE ROUX Jean-Louis RD-CORE-LAN wrote:<br>
<blockquote
 cite="[e-mail]"
 type="cite">
  <pre wrap="">Hi Neil

Not sure this discussion will help, actually this is out of the scope of this ID, 
nevermind, see inline,

JL

  </pre>
  <blockquote type="cite">
    <pre wrap="">-----Message d'origine-----
De : <a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a> [<a class="moz-txt-link-freetext" href="mailto:[e-mail]">mailto:[e-mail]</a>] 
Envoy&eacute; : lundi 15 novembre 2004 14:17
&Agrave; : LE ROUX Jean-Louis RD-CORE-LAN; <a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a>; 
<a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a>; <a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a>; <a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a>
Objet : RE: RE : Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt


Hi Jean-Loius,
    </pre>
    <blockquote type="cite">
      <pre wrap="">Hi Neil, all

We do not reinvent GMPLS here, we just list a set of
functional reqs, that may lead 
to minor protocol extensions.
By the way it seems that some of your objections applies to 
GMPLS in general...
      </pre>
    </blockquote>
    <pre wrap="">NH=&gt;  Not really.  The co-cs mode forces some good behaviours 
in GMPLS which we fully agree with, eg
-	OOB control/management
-	cannot violate connectivity requirements of the traffic 
data-plane
-	fixed/known hierachy

The latter forced requirement of the co-cs mode means one can 
have functional decoupling between the layer networks.  It 
also means one can choose best-of-breed functional components 
for things like addressing, signalling, OAM, etc.  'Choose' is 
the key word here.

All of this becomes rather important when different operators 
wish to lease capacity off each other in a client/server relationship.
    </pre>
    <blockquote type="cite">
      <pre wrap="">Regarding one of your previous comments, please note that
dynamic capacity update is a key requirement for many SPs. 
Here is a simple motivation example:
Let's assume for instance that a SP owns two IP networks, one 
for business trafic (VPNs) and another for DSL aggregation, 
both supported by the same transmission network; these two 
networks are not loaded during the same time along the day, 
and it would be highly useful to share transport capacity 
between them and reallocate bandwidth dynamically (with a 
period of several hours).
      </pre>
    </blockquote>
    <pre wrap="">NH=&gt; I don't dispute this at all.  The key things are:
-	the timescales over which topology changes are effected 
(ie closer to the duct the slower the TE 
time-constants).....but in any case we are talking S-PVCs here 
IMO and not SVCs (at least for the forseeable future).
    </pre>
  </blockquote>
  <pre wrap=""><!---->
No, why such restriction to S-PVCs, SVCs are largely envisageable in
an intra-operator case.

  </pre>
  <blockquote type="cite">
    <pre wrap="">-	whether we are talking intra-operator or 
inter-operator.  As a representative of FT I would expect you 
to fully understand that what is advertised and/or allowed to 
be controlled in your network(s) is a very different issue in 
these 2 cases.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Be sure I fully understand the distinction...
Here in this example I was talking intra-operator. 
By the way, note that current MRN requirements focus on intra operator case. 

  </pre>
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">Note that the term "Toplogy" is relative. When you signal a
new TDM LSP between two routers, you may update the "IP 
topology", as you setup a new IP link. This is just a 
question of terminology.
      </pre>
    </blockquote>
    <pre wrap="">NH=&gt; Well, maybe....depends on how you are looking at this 
compared to myself.  As per your example, when you signal a 
new SDH VC4 layer network trail say between 2 nodes in the IP 
layer network (ie a link connection here) then of course you 
are changing the IP layer network topology.  What I am arguing 
is that you cannot simply create topology on the fly (ie as 
some top level demand rippling right down to the optics/duct 
say) in any viable commercial manner.....esp in the 
inter-operator case.  
    </pre>
  </blockquote>
  <pre wrap=""><!---->
And what about the INTRA OPERATOR case ????

That is, one would create the 
  </pre>
  <blockquote type="cite">
    <pre wrap="">link-connection in the client topology as a consequence of 
longer-term trends in traffic behaviour in the client....and 
when we start getting down the stack, with all the will in the 
world, it will be not possible to create a link connection 
where physical infrastructure does not exist.  
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Please could you point where did you see such statement "to create a link connection 
where physical infrastructure does not exist" in our draft ? 


So at what the 
  </pre>
  <blockquote type="cite">
    <pre wrap="">level and to what degree is a priori provisioning done becomes 
a key question.  Further, I also firmly believe that strong 
functional decoupling is is important when we have a 
client/server relationship between 2 different 
operators.....and I'd be amazed if FT held any different view here.

    </pre>
  </blockquote>
  <pre wrap=""><!---->
Sure but who is talking about two operators here ?????
I think you missed something here. What about cases were both IP and transport are under the control of the same entity ????

Best Regards,

Jean-Louis




  </pre>
  <blockquote type="cite">
    <pre wrap="">regards, Neil
    </pre>
    <blockquote type="cite">
      <pre wrap="">Best Regards,

JL

      </pre>
      <blockquote type="cite">
        <pre wrap="">-----Message d'origine-----
De : <a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a>
[<a class="moz-txt-link-freetext" href="mailto:[e-mail]">mailto:[e-mail]</a>] De la part de 
        </pre>
      </blockquote>
      <pre wrap=""><a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a>
      </pre>
      <blockquote type="cite">
        <pre wrap="">Envoy&eacute; : lundi 15 novembre 2004 11:36
&Agrave; : <a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a>; <a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a>; 
<a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a>; <a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a>
Objet : RE: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt


John,

&lt;snipped&gt;
        </pre>
        <blockquote type="cite">
          <blockquote type="cite">
            <pre wrap="">.....in fact a large supplier of ours recently admitted
            </pre>
          </blockquote>
          <pre wrap="">(after 3 years
          </pre>
          <blockquote type="cite">
            <pre wrap="">of trying to persuade us otherwise) that they now agree 
            </pre>
          </blockquote>
        </blockquote>
      </blockquote>
      <pre wrap="">with us on 
      </pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <pre wrap="">this.
            </pre>
          </blockquote>
          <pre wrap="">&lt;John Drake&gt;

It's not unusual for a vendor that is incapable of building 
&lt;something&gt; to assert that &lt;something&gt; is a Bad IdeaTM.
          </pre>
        </blockquote>
        <pre wrap="">NH=&gt; Well, one could also look at this differently.....given
we worked out the facts several years ago on our own and 
nothing has happened since to show we were wrong, then one 
could say that we know this vendor is now at least trying to 
be honest with us on this issue.
        </pre>
        <blockquote type="cite">
          <blockquote type="cite">
            <pre wrap="">Those who think they can 'create topology on the fly' can
            </pre>
          </blockquote>
          <pre wrap="">believe in
          </pre>
          <blockquote type="cite">
            <pre wrap="">this stuff if they like.....you will convince me the 
            </pre>
          </blockquote>
        </blockquote>
      </blockquote>
    </blockquote>
    <pre wrap="">day I see a 
    </pre>
    <blockquote type="cite">
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <pre wrap="">routing protocol lay a duct and light some fibre, till 
            </pre>
          </blockquote>
        </blockquote>
      </blockquote>
      <pre wrap="">then we'll 
      </pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <pre wrap="">stick with what we know is true.
            </pre>
          </blockquote>
          <pre wrap="">&lt;John Drake&gt;

We never said that GMPLS had a backhoe option.
          </pre>
        </blockquote>
        <pre wrap="">NH=&gt; Try this logic.....and this is only one example of a
given layered network sequence:
-	to run the ducts we need the back-hoe
-	to run the fibre we need the ducts in place
-	to run the SDH MS/RS we need the fibre in place
-	to run the SDH VC4 layer network we need the SDH MS/RS in place
-	to run IP/MPLS layer networks we need the VC4 layer network in
place.

Do you see the logical dependency?  Put simply, one cannot
create topology on the fly....at some point in the above you 
are going have to assume some 'already in place/fixed' 
topology.  But it's not even as simple as that.......

Let's consider some of the commercial issues here as they are
rather important.  Ever tried figuring out the design rules 
required in some co-cs transport network (like SDH VC4 or OTNs 
say) so that one can 'create a trail at will' (an SVC by any 
other name)....or at least to some acceptable GoS (Grade of 
Service), ie probability of capacity being available within an 
acceptable (to the client) time period post making demand?

Folks should try it some time as the results are rather
illuminating. We did this with our traffic engineering maths 
group at the labs a few years ago.  Without going into the 
detail, if you want to be able to 'turn-up' seriously large BW 
trails on demand between various locations you are going to 
have a build a network that runs largely empty for most of its 
working life....now try getting a business case for this past 
the products/services/financial people ;-).

And once one turns up a trail in some lower layer network, do
you seriously expect we operators will turn it off?

Bottom-line...as one gets closer to the duct the holding time
of trails/topology must increase.

Note - These issues are over/above the requirement for
commercial/functional isolation between different operating 
parties in a client/server layer network relationship.

regards, Neil


        </pre>
      </blockquote>
    </blockquote>
  </blockquote>
  <pre wrap=""><!---->

  </pre>
</blockquote>
<br>
</body>
</html>

--------------080605000808010105050905--



Envelope-to: [e-mail]
Delivery-date: Mon, 15 Nov 2004 13:53:12 +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 : Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
Date: Mon, 15 Nov 2004 14:47:50 +0100
Message-ID: <[e-mail]>
Thread-Topic: RE : Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
Thread-Index: AcTJprHOyTIIih+jTE2szl8loOGYyABUFEegAAJtcUAAA+dwwAABX4nA
From: "LE ROUX Jean-Louis RD-CORE-LAN" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>

Hi Neil

Not sure this discussion will help, actually this is out of the scope of =
this ID,=20
nevermind, see inline,

JL

>-----Message d'origine-----
>De : [e-mail] [mailto:[e-mail]]=20
>Envoy=E9 : lundi 15 novembre 2004 14:17
>=C0 : LE ROUX Jean-Louis RD-CORE-LAN; [e-mail];=20
>[e-mail]; [e-mail]; [e-mail]
>Objet : RE: RE : Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
>
>
>Hi Jean-Loius,
>>=20
>> Hi Neil, all
>>=20
>> We do not reinvent GMPLS here, we just list a set of
>> functional reqs, that may lead=20
>> to minor protocol extensions.
>> By the way it seems that some of your objections applies to=20
>> GMPLS in general...
>NH=3D>  Not really.  The co-cs mode forces some good behaviours=20
>in GMPLS which we fully agree with, eg
>-	OOB control/management
>-	cannot violate connectivity requirements of the traffic=20
>data-plane
>-	fixed/known hierachy
>
>The latter forced requirement of the co-cs mode means one can=20
>have functional decoupling between the layer networks.  It=20
>also means one can choose best-of-breed functional components=20
>for things like addressing, signalling, OAM, etc.  'Choose' is=20
>the key word here.
>
>All of this becomes rather important when different operators=20
>wish to lease capacity off each other in a client/server relationship.
>>=20
>> Regarding one of your previous comments, please note that
>> dynamic capacity update is a key requirement for many SPs.=20
>> Here is a simple motivation example:
>> Let's assume for instance that a SP owns two IP networks, one=20
>> for business trafic (VPNs) and another for DSL aggregation,=20
>> both supported by the same transmission network; these two=20
>> networks are not loaded during the same time along the day,=20
>> and it would be highly useful to share transport capacity=20
>> between them and reallocate bandwidth dynamically (with a=20
>> period of several hours).
>NH=3D> I don't dispute this at all.  The key things are:
>-	the timescales over which topology changes are effected=20
>(ie closer to the duct the slower the TE=20
>time-constants).....but in any case we are talking S-PVCs here=20
>IMO and not SVCs (at least for the forseeable future).

No, why such restriction to S-PVCs, SVCs are largely envisageable in
an intra-operator case.

>-	whether we are talking intra-operator or=20
>inter-operator.  As a representative of FT I would expect you=20
>to fully understand that what is advertised and/or allowed to=20
>be controlled in your network(s) is a very different issue in=20
>these 2 cases.

Be sure I fully understand the distinction...
Here in this example I was talking intra-operator.=20
By the way, note that current MRN requirements focus on intra operator =
case.=20

>>=20
>> Note that the term "Toplogy" is relative. When you signal a
>> new TDM LSP between two routers, you may update the "IP=20
>> topology", as you setup a new IP link. This is just a=20
>> question of terminology.
>NH=3D> Well, maybe....depends on how you are looking at this=20
>compared to myself.  As per your example, when you signal a=20
>new SDH VC4 layer network trail say between 2 nodes in the IP=20
>layer network (ie a link connection here) then of course you=20
>are changing the IP layer network topology.  What I am arguing=20
>is that you cannot simply create topology on the fly (ie as=20
>some top level demand rippling right down to the optics/duct=20
>say) in any viable commercial manner.....esp in the=20
>inter-operator case. =20

And what about the INTRA OPERATOR case ????

That is, one would create the=20
>link-connection in the client topology as a consequence of=20
>longer-term trends in traffic behaviour in the client....and=20
>when we start getting down the stack, with all the will in the=20
>world, it will be not possible to create a link connection=20
>where physical infrastructure does not exist. =20

Please could you point where did you see such statement "to create a =
link connection=20
where physical infrastructure does not exist" in our draft ?=20


So at what the=20
>level and to what degree is a priori provisioning done becomes=20
>a key question.  Further, I also firmly believe that strong=20
>functional decoupling is is important when we have a=20
>client/server relationship between 2 different=20
>operators.....and I'd be amazed if FT held any different view here.
>

Sure but who is talking about two operators here ?????
I think you missed something here. What about cases were both IP and =
transport are under the control of the same entity ????

Best Regards,

Jean-Louis




>regards, Neil
>>=20
>> Best Regards,
>>=20
>> JL
>>=20
>> >-----Message d'origine-----
>> >De : [e-mail]
>> >[mailto:[e-mail]] De la part de=20
>> [e-mail]
>> >Envoy=E9 : lundi 15 novembre 2004 11:36
>> >=C0 : [e-mail]; [e-mail];=20
>> >[e-mail]; [e-mail]
>> >Objet : RE: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
>> >
>> >
>> >John,
>> >
>> ><snipped>
>> >> > .....in fact a large supplier of ours recently admitted
>> >> (after 3 years
>> >> > of trying to persuade us otherwise) that they now agree=20
>> with us on=20
>> >> > this.
>> >> <John Drake>
>> >>=20
>> >> It's not unusual for a vendor that is incapable of building=20
>> >> <something> to assert that <something> is a Bad IdeaTM.
>> >NH=3D> Well, one could also look at this differently.....given
>> >we worked out the facts several years ago on our own and=20
>> >nothing has happened since to show we were wrong, then one=20
>> >could say that we know this vendor is now at least trying to=20
>> >be honest with us on this issue.
>> >>=20
>> >> > Those who think they can 'create topology on the fly' can
>> >> believe in
>> >> > this stuff if they like.....you will convince me the=20
>day I see a=20
>> >> > routing protocol lay a duct and light some fibre, till=20
>> then we'll=20
>> >> > stick with what we know is true.
>> >> <John Drake>
>> >>=20
>> >> We never said that GMPLS had a backhoe option.
>> >NH=3D> Try this logic.....and this is only one example of a
>> >given layered network sequence:
>> >-	to run the ducts we need the back-hoe
>> >-	to run the fibre we need the ducts in place
>> >-	to run the SDH MS/RS we need the fibre in place
>> >-	to run the SDH VC4 layer network we need the SDH MS/RS in place
>> >-	to run IP/MPLS layer networks we need the VC4 layer network in
>> >place.
>> >
>> >Do you see the logical dependency?  Put simply, one cannot
>> >create topology on the fly....at some point in the above you=20
>> >are going have to assume some 'already in place/fixed'=20
>> >topology.  But it's not even as simple as that.......
>> >
>> >Let's consider some of the commercial issues here as they are
>> >rather important.  Ever tried figuring out the design rules=20
>> >required in some co-cs transport network (like SDH VC4 or OTNs=20
>> >say) so that one can 'create a trail at will' (an SVC by any=20
>> >other name)....or at least to some acceptable GoS (Grade of=20
>> >Service), ie probability of capacity being available within an=20
>> >acceptable (to the client) time period post making demand?
>> >
>> >Folks should try it some time as the results are rather
>> >illuminating. We did this with our traffic engineering maths=20
>> >group at the labs a few years ago.  Without going into the=20
>> >detail, if you want to be able to 'turn-up' seriously large BW=20
>> >trails on demand between various locations you are going to=20
>> >have a build a network that runs largely empty for most of its=20
>> >working life....now try getting a business case for this past=20
>> >the products/services/financial people ;-).
>> >
>> >And once one turns up a trail in some lower layer network, do
>> >you seriously expect we operators will turn it off?
>> >
>> >Bottom-line...as one gets closer to the duct the holding time
>> >of trails/topology must increase.
>> >
>> >Note - These issues are over/above the requirement for
>> >commercial/functional isolation between different operating=20
>> >parties in a client/server layer network relationship.
>> >
>> >regards, Neil
>> >
>> >
>>=20
>



Envelope-to: [e-mail]
Delivery-date: Mon, 15 Nov 2004 13:17:07 +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 : Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
Date: Mon, 15 Nov 2004 13:17:03 -0000
Message-ID: <[e-mail]>
Thread-Topic: RE : Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
Thread-Index: AcTJprHOyTIIih+jTE2szl8loOGYyABUFEegAAJtcUAAA+dwwA==
From: <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>

Hi Jean-Loius,
>=20
> Hi Neil, all
>=20
> We do not reinvent GMPLS here, we just list a set of=20
> functional reqs, that may lead=20
> to minor protocol extensions.
> By the way it seems that some of your objections applies to=20
> GMPLS in general...
NH=3D>  Not really.  The co-cs mode forces some good behaviours in GMPLS =
which we fully agree with, eg
-	OOB control/management
-	cannot violate connectivity requirements of the traffic data-plane
-	fixed/known hierachy

The latter forced requirement of the co-cs mode means one can have =
functional decoupling between the layer networks.  It also means one can =
choose best-of-breed functional components for things like addressing, =
signalling, OAM, etc.  'Choose' is the key word here.

All of this becomes rather important when different operators wish to =
lease capacity off each other in a client/server relationship.
>=20
> Regarding one of your previous comments, please note that=20
> dynamic capacity update is a key requirement for many SPs.=20
> Here is a simple motivation example:
> Let's assume for instance that a SP owns two IP networks, one=20
> for business trafic (VPNs) and another for DSL aggregation,=20
> both supported by the same transmission network; these two=20
> networks are not loaded during the same time along the day,=20
> and it would be highly useful to share transport capacity=20
> between them and reallocate bandwidth dynamically (with a=20
> period of several hours).
NH=3D> I don't dispute this at all.  The key things are:
-	the timescales over which topology changes are effected (ie closer to =
the duct the slower the TE time-constants).....but in any case we are =
talking S-PVCs here IMO and not SVCs (at least for the forseeable =
future).
-	whether we are talking intra-operator or inter-operator.  As a =
representative of FT I would expect you to fully understand that what is =
advertised and/or allowed to be controlled in your network(s) is a very =
different issue in these 2 cases.
>=20
> Note that the term "Toplogy" is relative. When you signal a=20
> new TDM LSP between two routers, you may update the "IP=20
> topology", as you setup a new IP link. This is just a=20
> question of terminology.
NH=3D> Well, maybe....depends on how you are looking at this compared to =
myself.  As per your example, when you signal a new SDH VC4 layer =
network trail say between 2 nodes in the IP layer network (ie a link =
connection here) then of course you are changing the IP layer network =
topology.  What I am arguing is that you cannot simply create topology =
on the fly (ie as some top level demand rippling right down to the =
optics/duct say) in any viable commercial manner.....esp in the =
inter-operator case.  That is, one would create the link-connection in =
the client topology as a consequence of longer-term trends in traffic =
behaviour in the client....and when we start getting down the stack, =
with all the will in the world, it will be not possible to create a link =
connection where physical infrastructure does not exist.  So at what the =
level and to what degree is a priori provisioning done becomes a key =
question.  Further, I also firmly believe that strong functional =
decoupling is is important when we have a client/server relationship =
between 2 different operators.....and I'd be amazed if FT held any =
different view here.

regards, Neil
>=20
> Best Regards,
>=20
> JL
>=20
> >-----Message d'origine-----
> >De : [e-mail]
> >[mailto:[e-mail]] De la part de=20
> [e-mail]
> >Envoy=E9 : lundi 15 novembre 2004 11:36
> >=C0 : [e-mail]; [e-mail];=20
> >[e-mail]; [e-mail]
> >Objet : RE: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
> >
> >
> >John,
> >
> ><snipped>
> >> > .....in fact a large supplier of ours recently admitted
> >> (after 3 years
> >> > of trying to persuade us otherwise) that they now agree=20
> with us on=20
> >> > this.
> >> <John Drake>
> >>=20
> >> It's not unusual for a vendor that is incapable of building=20
> >> <something> to assert that <something> is a Bad IdeaTM.
> >NH=3D> Well, one could also look at this differently.....given
> >we worked out the facts several years ago on our own and=20
> >nothing has happened since to show we were wrong, then one=20
> >could say that we know this vendor is now at least trying to=20
> >be honest with us on this issue.
> >>=20
> >> > Those who think they can 'create topology on the fly' can
> >> believe in
> >> > this stuff if they like.....you will convince me the day I see a=20
> >> > routing protocol lay a duct and light some fibre, till=20
> then we'll=20
> >> > stick with what we know is true.
> >> <John Drake>
> >>=20
> >> We never said that GMPLS had a backhoe option.
> >NH=3D> Try this logic.....and this is only one example of a
> >given layered network sequence:
> >-	to run the ducts we need the back-hoe
> >-	to run the fibre we need the ducts in place
> >-	to run the SDH MS/RS we need the fibre in place
> >-	to run the SDH VC4 layer network we need the SDH MS/RS in place
> >-	to run IP/MPLS layer networks we need the VC4 layer network in
> >place.
> >
> >Do you see the logical dependency?  Put simply, one cannot
> >create topology on the fly....at some point in the above you=20
> >are going have to assume some 'already in place/fixed'=20
> >topology.  But it's not even as simple as that.......
> >
> >Let's consider some of the commercial issues here as they are
> >rather important.  Ever tried figuring out the design rules=20
> >required in some co-cs transport network (like SDH VC4 or OTNs=20
> >say) so that one can 'create a trail at will' (an SVC by any=20
> >other name)....or at least to some acceptable GoS (Grade of=20
> >Service), ie probability of capacity being available within an=20
> >acceptable (to the client) time period post making demand?
> >
> >Folks should try it some time as the results are rather
> >illuminating. We did this with our traffic engineering maths=20
> >group at the labs a few years ago.  Without going into the=20
> >detail, if you want to be able to 'turn-up' seriously large BW=20
> >trails on demand between various locations you are going to=20
> >have a build a network that runs largely empty for most of its=20
> >working life....now try getting a business case for this past=20
> >the products/services/financial people ;-).
> >
> >And once one turns up a trail in some lower layer network, do
> >you seriously expect we operators will turn it off?
> >
> >Bottom-line...as one gets closer to the duct the holding time
> >of trails/topology must increase.
> >
> >Note - These issues are over/above the requirement for
> >commercial/functional isolation between different operating=20
> >parties in a client/server layer network relationship.
> >
> >regards, Neil
> >
> >
>=20



Envelope-to: [e-mail]
Delivery-date: Mon, 15 Nov 2004 11:26:23 +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 : Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
Date: Mon, 15 Nov 2004 12:22:42 +0100
Message-ID: <[e-mail]>
Thread-Topic: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
Thread-Index: AcTJprHOyTIIih+jTE2szl8loOGYyABUFEegAAJtcUA=
From: "LE ROUX Jean-Louis RD-CORE-LAN" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>

Hi Neil, all

We do not reinvent GMPLS here, we just list a set of functional reqs, =
that may lead=20
to minor protocol extensions.
By the way it seems that some of your objections applies to GMPLS in =
general...

Regarding one of your previous comments, please note that dynamic =
capacity update is a key requirement for many SPs.=20
Here is a simple motivation example:
Let's assume for instance that a SP owns two IP networks, one for =
business trafic (VPNs)
and another for DSL aggregation, both supported by the same transmission =
network;
these two networks are not loaded during the same time along the day, =
and it would be highly useful to share transport capacity between them =
and reallocate bandwidth dynamically
(with a period of several hours).=20

Note that the term "Toplogy" is relative. When you signal a new TDM LSP =
between two routers, you may update the "IP topology", as you setup a =
new IP link. This is just a question of terminology.

Best Regards,

JL

>-----Message d'origine-----
>De : [e-mail]=20
>[mailto:[e-mail]] De la part de [e-mail]
>Envoy=E9 : lundi 15 novembre 2004 11:36
>=C0 : [e-mail]; [e-mail];=20
>[e-mail]; [e-mail]
>Objet : RE: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
>
>
>John,
>
><snipped>
>> > .....in fact a large supplier of ours recently admitted
>> (after 3 years
>> > of trying to persuade us otherwise) that they now agree with us on
>> > this.
>> <John Drake>
>>=20
>> It's not unusual for a vendor that is incapable of building
>> <something> to assert that <something> is a Bad IdeaTM.
>NH=3D> Well, one could also look at this differently.....given=20
>we worked out the facts several years ago on our own and=20
>nothing has happened since to show we were wrong, then one=20
>could say that we know this vendor is now at least trying to=20
>be honest with us on this issue.
>>=20
>> > Those who think they can 'create topology on the fly' can
>> believe in
>> > this stuff if they like.....you will convince me the day I see a
>> > routing protocol lay a duct and light some fibre, till then we'll=20
>> > stick with what we know is true.
>> <John Drake>
>>=20
>> We never said that GMPLS had a backhoe option.
>NH=3D> Try this logic.....and this is only one example of a=20
>given layered network sequence:
>-	to run the ducts we need the back-hoe
>-	to run the fibre we need the ducts in place
>-	to run the SDH MS/RS we need the fibre in place
>-	to run the SDH VC4 layer network we need the SDH MS/RS in place
>-	to run IP/MPLS layer networks we need the VC4 layer network in
>place.
>
>Do you see the logical dependency?  Put simply, one cannot=20
>create topology on the fly....at some point in the above you=20
>are going have to assume some 'already in place/fixed'=20
>topology.  But it's not even as simple as that.......
>
>Let's consider some of the commercial issues here as they are=20
>rather important.  Ever tried figuring out the design rules=20
>required in some co-cs transport network (like SDH VC4 or OTNs=20
>say) so that one can 'create a trail at will' (an SVC by any=20
>other name)....or at least to some acceptable GoS (Grade of=20
>Service), ie probability of capacity being available within an=20
>acceptable (to the client) time period post making demand?
>
>Folks should try it some time as the results are rather=20
>illuminating. We did this with our traffic engineering maths=20
>group at the labs a few years ago.  Without going into the=20
>detail, if you want to be able to 'turn-up' seriously large BW=20
>trails on demand between various locations you are going to=20
>have a build a network that runs largely empty for most of its=20
>working life....now try getting a business case for this past=20
>the products/services/financial people ;-).
>
>And once one turns up a trail in some lower layer network, do=20
>you seriously expect we operators will turn it off?
>
>Bottom-line...as one gets closer to the duct the holding time=20
>of trails/topology must increase.
>
>Note - These issues are over/above the requirement for=20
>commercial/functional isolation between different operating=20
>parties in a client/server layer network relationship.
>
>regards, Neil
>
>



Envelope-to: [e-mail]
Delivery-date: Mon, 15 Nov 2004 10:36:56 +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: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
Date: Mon, 15 Nov 2004 10:35:35 -0000
Message-ID: <[e-mail]>
Thread-Topic: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
Thread-Index: AcTJprHOyTIIih+jTE2szl8loOGYyABUFEeg
From: <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>

John,

<snipped>
> > .....in fact a large supplier of ours recently admitted=20
> (after 3 years=20
> > of trying to persuade us otherwise) that they now agree with us on=20
> > this.
> <John Drake>
>=20
> It's not unusual for a vendor that is incapable of building=20
> <something> to assert that <something> is a Bad IdeaTM.
NH=3D> Well, one could also look at this differently.....given we worked
out the facts several years ago on our own and nothing has happened
since to show we were wrong, then one could say that we know this vendor
is now at least trying to be honest with us on this issue.
>=20
> > Those who think they can 'create topology on the fly' can=20
> believe in=20
> > this stuff if they like.....you will convince me the day I see a=20
> > routing protocol lay a duct and light some fibre, till then we'll=20
> > stick with what we know is true.
> <John Drake>
>=20
> We never said that GMPLS had a backhoe option.
NH=3D> Try this logic.....and this is only one example of a given =
layered
network sequence:
-	to run the ducts we need the back-hoe
-	to run the fibre we need the ducts in place
-	to run the SDH MS/RS we need the fibre in place
-	to run the SDH VC4 layer network we need the SDH MS/RS in place
-	to run IP/MPLS layer networks we need the VC4 layer network in
place.

Do you see the logical dependency?  Put simply, one cannot create
topology on the fly....at some point in the above you are going have to
assume some 'already in place/fixed' topology.  But it's not even as
simple as that.......

Let's consider some of the commercial issues here as they are rather
important.  Ever tried figuring out the design rules required in some
co-cs transport network (like SDH VC4 or OTNs say) so that one can
'create a trail at will' (an SVC by any other name)....or at least to
some acceptable GoS (Grade of Service), ie probability of capacity being
available within an acceptable (to the client) time period post making
demand?

Folks should try it some time as the results are rather illuminating.
We did this with our traffic engineering maths group at the labs a few
years ago.  Without going into the detail, if you want to be able to
'turn-up' seriously large BW trails on demand between various locations
you are going to have a build a network that runs largely empty for most
of its working life....now try getting a business case for this past the
products/services/financial people ;-).

And once one turns up a trail in some lower layer network, do you
seriously expect we operators will turn it off?

Bottom-line...as one gets closer to the duct the holding time of
trails/topology must increase.

Note - These issues are over/above the requirement for
commercial/functional isolation between different operating parties in a
client/server layer network relationship.

regards, Neil



Envelope-to: [e-mail]
Delivery-date: Sat, 13 Nov 2004 17:33:25 +0000
Message-ID: <[e-mail]>
From: John Drake <[e-mail]>
To: [e-mail], [e-mail], [e-mail],  [e-mail]
Subject: RE: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
Date: Sat, 13 Nov 2004 09:30:48 -0800
MIME-Version: 1.0
Content-Type: text/plain

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Friday, November 12, 2004 8:29 AM
> To: [e-mail]; [e-mail]; [e-mail]
> Subject: RE: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
> 
> Hi Deborah,
> 
> Just to reassure you, I can confirm we fully understand what func arch is
> and why its important (we had a big hand in doing it).  And we also
> understand what GMPLS and MPLS are, what the 3 networking modes are, and
> how they are and are not related.
<John Drake>

Then I'm sure you are aware that the concept of a multi-region network (nee
the peer model) was an integral part of GMPLS from its inception, and that
it solves a very real problem with layered networks, viz, the problem of IGP
flooding in mesh networks.  I'm also sure you are aware that the deployment
of a layered network (nee the overlay model) or a multi-region network is at
the sole discretion of the owner of that network.


> One cannot functionally crunch the
> modes from 'IP to optics', it will simply not work either technically or
> commercially
<John Drake>

Late breaking news from Neil.  I better update my customers.

> .....in fact a large supplier of ours recently admitted (after
> 3 years of trying to persuade us otherwise) that they now agree with us on
> this.
<John Drake>

It's not unusual for a vendor that is incapable of building <something> to
assert that <something> is a Bad IdeaTM.

> Those who think they can 'create topology on the fly' can believe
> in this stuff if they like.....you will convince me the day I see a
> routing protocol lay a duct and light some fibre, till then we'll stick
> with what we know is true.
<John Drake>

We never said that GMPLS had a backhoe option.

> 
> regards, Neil
> 
> 
>  -----Original Message-----
> From: Brungard, Deborah A, ALABS [mailto:[e-mail]]
> Sent: 12 November 2004 15:23
> To: Harrison,N,Neil,IKR2 R; [e-mail]; [e-mail]
> Subject: RE: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
> 
> 
> 
> 	Hi Neil,
> 
> 	As I said in my previous mail, there seems to be confusion for those
> not familiar with GMPLS terminology. LSP is control plane. Nothing new
> here in this draft. I would suggest those concerned should discuss via the
> ITU-T SG 15 Q12/Q14 lists as the same choices were made for ITU's DCM
> (G7713.2 and G.7713.3) protocols.
> 
> 	Deborah
> 
> 
> 
> ________________________________
> 
> 	From: [e-mail] [mailto:[e-mail]] On
> Behalf Of [e-mail]
> 	Sent: Friday, November 12, 2004 8:41 AM
> 	To: [e-mail]; [e-mail]
> 	Subject: RE: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
> 
> 
> 	Folks should take note of this advice.  We are fully in agreement
> with you on this issue Stephen.
> 
> 	BTW - G.805/809 stuff is not something dreamed-up in ITU just for
> the sake of it.....in fact its really nothing to do with ITU as its simply
> a formal way of capturing/defining the nature of real networks.
> 
> 	regards, Neil
> 
> 		-----Original Message-----
> 		From: [e-mail] [mailto:owner-
> [e-mail]] On Behalf Of Stephen Shew
> 		Sent: 11 November 2004 20:02
> 		To: [e-mail]
> 		Subject: Comment on
draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
> 
> 
> 		I was not able to be at the CCAMP meeting today but do have
> some comments on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
> 
> 		It seems that the goals of the draft could be accomplished
> more simply by adopting the layer architecture as defined in ITU-T
> Recommendations G.805 and G.809.  By doing this, the specific boundaries
> between TDM, LSC, etc. don't have to be articulated as they are just layer
> networks.  Also, the designation of TDM does not include the notions of
> the layers within that (e.g., DS3, STS-1, VC4, etc.) which are important
> to transport equipment.  Adopting the layer architecture also enables a
> client layer to be supported by an inverse multipling layer such as
> provided by Virtual Concatenation.  Here a layer of finer granularity is
> use to support a layer of coarser granularity.
> 
> 
> 		Stephen Shew         Voice: 613-763-2462  Fax: [phone]
> 		Nortel - Optical Networks  email: [e-mail]
> 		P.O. Box 3511, Station C
> 		Ottawa, ON K1Y 4H7
> 
> 




Envelope-to: [e-mail]
Delivery-date: Fri, 12 Nov 2004 16:28:54 +0000
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C8D4.B4BE5EC2"
Subject: RE: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
Date: Fri, 12 Nov 2004 16:28:56 -0000
Message-ID: <[e-mail]>
Thread-Topic: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
Thread-Index: AcTIKew1y+pco00tQt2U3CM1qz+LcwAi9FFwAAUu58AAAhmD0A==
From: <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C4C8D4.B4BE5EC2
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Deborah,
=20
Just to reassure you, I can confirm we fully understand what func arch
is and why its important (we had a big hand in doing it).  And we also
understand what GMPLS and MPLS are, what the 3 networking modes are, and
how they are and are not related.  One cannot functionally crunch the
modes from 'IP to optics', it will simply not work either technically or
commercially.....in fact a large supplier of ours recently admitted
(after 3 years of trying to persuade us otherwise) that they now agree
with us on this.  Those who think they can 'create topology on the fly'
can believe in this stuff if they like.....you will convince me the day
I see a routing protocol lay a duct and light some fibre, till then
we'll stick with what we know is true.
=20
regards, Neil
=20
=20
 -----Original Message-----
From: Brungard, Deborah A, ALABS [mailto:[e-mail]]=20
Sent: 12 November 2004 15:23
To: Harrison,N,Neil,IKR2 R; [e-mail];
[e-mail]
Subject: RE: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt



Hi Neil,
=20
As I said in my previous mail, there seems to be confusion for those not
familiar with GMPLS terminology. LSP is control plane. Nothing new here
in this draft. I would suggest those concerned should discuss via the
ITU-T SG 15 Q12/Q14 lists as the same choices were made for ITU's DCM
(G7713.2 and G.7713.3) protocols.
=20
Deborah
=20
=20

  _____ =20

From: [e-mail] [mailto:[e-mail]] On
Behalf Of [e-mail]
Sent: Friday, November 12, 2004 8:41 AM
To: [e-mail]; [e-mail]
Subject: RE: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt


Folks should take note of this advice.  We are fully in agreement with
you on this issue Stephen.
=20
BTW - G.805/809 stuff is not something dreamed-up in ITU just for the
sake of it.....in fact its really nothing to do with ITU as its simply a
formal way of capturing/defining the nature of real networks.
=20
regards, Neil

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Stephen Shew
Sent: 11 November 2004 20:02
To: [e-mail]
Subject: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt


I was not able to be at the CCAMP meeting today but do have some
comments on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt    =20
=20
It seems that the goals of the draft could be accomplished more simply
by adopting the layer architecture as defined in ITU-T Recommendations
G.805 and G.809.  By doing this, the specific boundaries between TDM,
LSC, etc. don't have to be articulated as they are just layer networks.
Also, the designation of TDM does not include the notions of the layers
within that (e.g., DS3, STS-1, VC4, etc.) which are important to
transport equipment.  Adopting the layer architecture also enables a
client layer to be supported by an inverse multipling layer such as
provided by Virtual Concatenation.  Here a layer of finer granularity is
use to support a layer of coarser granularity.
=20

Stephen Shew         Voice: 613-763-2462  Fax: [phone]
Nortel - Optical Networks  email: [e-mail]=20
P.O. Box 3511, Station C=20
Ottawa, ON K1Y 4H7=20

=20


------_=_NextPart_001_01C4C8D4.B4BE5EC2
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D574481516-12112004><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2>Hi Deborah,</FONT></SPAN></DIV>
<DIV><SPAN class=3D574481516-12112004><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D574481516-12112004><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2>Just to reassure you, I can confirm we fully understand what =
func arch is=20
and why its important (we had a big hand in doing it).&nbsp; And we also =

understand what GMPLS and MPLS are, what the 3 networking modes are, and =
how=20
they are and are not related.&nbsp; One cannot functionally crunch the =
modes=20
from 'IP to optics', it will simply not work either technically or=20
commercially.....in fact a large supplier of ours recently admitted =
(after 3=20
years of trying to persuade us otherwise) that they now agree with us on =

this.&nbsp; Those who think they can 'create topology on the fly' can =
believe in=20
this stuff if they like.....you will convince me the day I see a routing =

protocol lay a duct and light some fibre, till then we'll stick with =
what we=20
know is true.</FONT></SPAN></DIV>
<DIV><SPAN class=3D574481516-12112004><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D574481516-12112004><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2>regards, Neil</FONT></SPAN></DIV>
<DIV><SPAN class=3D574481516-12112004></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D574481516-12112004></SPAN><FONT face=3DTahoma><FONT =
size=3D2><SPAN=20
class=3D574481516-12112004><FONT face=3D"Comic Sans MS"=20
color=3D#800000>&nbsp;</FONT></SPAN></FONT></FONT></DIV>
<DIV><FONT face=3DTahoma><FONT size=3D2><SPAN=20
class=3D574481516-12112004>&nbsp;</SPAN>-----Original =
Message-----<BR><B>From:</B>=20
Brungard, Deborah A, ALABS [mailto:[e-mail]] <BR><B>Sent:</B> =
12=20
November 2004 15:23<BR><B>To:</B> Harrison,N,Neil,IKR2 R;=20
[e-mail]; [e-mail]<BR><B>Subject:</B> RE: =
Comment on=20
draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt<BR><BR></DIV></FONT></FONT>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #800000 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D469411515-12112004><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>Hi Neil,</FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D469411515-12112004><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D469411515-12112004><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>As I said in my previous mail, there seems to =
be=20
  confusion for those not familiar with GMPLS terminology. LSP is =
control plane.=20
  Nothing new here in this draft. I would suggest those concerned should =
discuss=20
  via the ITU-T SG 15 Q12/Q14 lists as the same choices were made for =
ITU's DCM=20
  (G7713.2 and G.7713.3) protocols.</FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D469411515-12112004><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D469411515-12112004><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>Deborah</FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D469411515-12112004><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D469411515-12112004><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV><BR>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> [e-mail]=20
  [mailto:[e-mail]] <B>On Behalf Of=20
  </B>[e-mail]<BR><B>Sent:</B> Friday, November 12, 2004 =
8:41=20
  AM<BR><B>To:</B> [e-mail];=20
  [e-mail]<BR><B>Subject:</B> RE: Comment on=20
  draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV><SPAN class=3D702164712-12112004><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
  size=3D2>Folks should take note of this advice.&nbsp; We are fully in =
agreement=20
  with you on this issue Stephen.</FONT></SPAN></DIV>
  <DIV><SPAN class=3D702164712-12112004><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D702164712-12112004><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
  size=3D2>BTW - G.805/809 stuff is not something dreamed-up in ITU just =
for the=20
  sake of it.....in fact its really nothing to do with ITU as&nbsp;its =
simply a=20
  formal way of capturing/defining the nature of real=20
  networks.</FONT></SPAN></DIV>
  <DIV><SPAN class=3D702164712-12112004><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
  size=3D2></FONT></SPAN><SPAN class=3D702164712-12112004><FONT =
face=3D"Comic Sans MS"=20
  color=3D#800000 size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D702164712-12112004><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
  size=3D2>regards, Neil</FONT></SPAN></DIV>
  <BLOCKQUOTE dir=3Dltr=20
  style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #800000 2px =
solid; MARGIN-RIGHT: 0px">
    <DIV></DIV>
    <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
    face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
    [e-mail] [mailto:[e-mail]] <B>On =
Behalf Of=20
    </B>Stephen Shew<BR><B>Sent:</B> 11 November 2004 =
20:02<BR><B>To:</B>=20
    [e-mail]<BR><B>Subject:</B> Comment on=20
    draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt<BR><BR></FONT></DIV>
    <DIV><FONT color=3D#000080 size=3D2><SPAN =
class=3D687015119-11112004>I was not=20
    able to be at the CCAMP meeting today but do have some comments on =
<FONT=20
    color=3D#000000 size=3D3><FONT=20
    =
size=3D2>draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt</FONT>&nbsp;&nbsp;&nb=
sp;&nbsp;=20
    </FONT></SPAN></FONT></DIV>
    <DIV><FONT color=3D#000080 size=3D2><SPAN=20
    class=3D687015119-11112004></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT color=3D#000080 size=3D2><SPAN =
class=3D687015119-11112004>It seems that=20
    the goals of the draft could be accomplished more simply by adopting =
the=20
    layer architecture as defined in ITU-T Recommendations G.805 and=20
    G.809.&nbsp; By doing this, the specific boundaries between TDM, =
LSC, etc.=20
    don't have to be articulated as they are just layer networks.&nbsp; =
Also,=20
    the designation of TDM does not include the notions of the layers =
within=20
    that (e.g., DS3, STS-1, VC4, etc.) which are important to transport=20
    equipment.&nbsp; Adopting the layer architecture also enables a =
client layer=20
    to be supported by an inverse multipling layer such as provided by =
Virtual=20
    Concatenation.&nbsp; Here a layer of finer granularity is use to =
support a=20
    layer of coarser granularity.</SPAN></FONT></DIV>
    <DIV>&nbsp;</DIV>
    <P dir=3Dltr align=3Dleft><FONT color=3D#000080 size=3D2>Stephen=20
    Shew&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Voice:=20
    613-763-2462&nbsp; Fax: [phone]</FONT><BR><FONT color=3D#000080 =

    size=3D2>Nortel - Optical Networks&nbsp; email:=20
    [e-mail]</FONT> <BR><FONT color=3D#000080 =
size=3D2>P.O. Box=20
    3511, Station C</FONT> <BR><FONT color=3D#000080 size=3D2>Ottawa, ON =
K1Y=20
    4H7</FONT> </P>
    <DIV>&nbsp;</DIV></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C4C8D4.B4BE5EC2--



Envelope-to: [e-mail]
Delivery-date: Fri, 12 Nov 2004 15:24:39 +0000
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C8CB.8DDF4F26"
Subject: RE: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
Date: Fri, 12 Nov 2004 09:23:25 -0600
Message-ID: <[e-mail]>
Thread-Topic: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
Thread-Index: AcTIKew1y+pco00tQt2U3CM1qz+LcwAi9FFwAAUu58A=
From: "Brungard, Deborah A, ALABS" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C4C8CB.8DDF4F26
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Neil,
=20
As I said in my previous mail, there seems to be confusion for those not
familiar with GMPLS terminology. LSP is control plane. Nothing new here
in this draft. I would suggest those concerned should discuss via the
ITU-T SG 15 Q12/Q14 lists as the same choices were made for ITU's DCM
(G7713.2 and G.7713.3) protocols.
=20
Deborah
=20
=20

  _____ =20

From: [e-mail] [mailto:[e-mail]] On
Behalf Of [e-mail]
Sent: Friday, November 12, 2004 8:41 AM
To: [e-mail]; [e-mail]
Subject: RE: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt


Folks should take note of this advice.  We are fully in agreement with
you on this issue Stephen.
=20
BTW - G.805/809 stuff is not something dreamed-up in ITU just for the
sake of it.....in fact its really nothing to do with ITU as its simply a
formal way of capturing/defining the nature of real networks.
=20
regards, Neil

	-----Original Message-----
	From: [e-mail] [mailto:[e-mail]]
On Behalf Of Stephen Shew
	Sent: 11 November 2004 20:02
	To: [e-mail]
	Subject: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
=09
=09
	I was not able to be at the CCAMP meeting today but do have some
comments on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt    =20
	=20
	It seems that the goals of the draft could be accomplished more
simply by adopting the layer architecture as defined in ITU-T
Recommendations G.805 and G.809.  By doing this, the specific boundaries
between TDM, LSC, etc. don't have to be articulated as they are just
layer networks.  Also, the designation of TDM does not include the
notions of the layers within that (e.g., DS3, STS-1, VC4, etc.) which
are important to transport equipment.  Adopting the layer architecture
also enables a client layer to be supported by an inverse multipling
layer such as provided by Virtual Concatenation.  Here a layer of finer
granularity is use to support a layer of coarser granularity.
	=20

	Stephen Shew         Voice: 613-763-2462  Fax: [phone]
	Nortel - Optical Networks  email: [e-mail]=20
	P.O. Box 3511, Station C=20
	Ottawa, ON K1Y 4H7=20

	=20


------_=_NextPart_001_01C4C8CB.8DDF4F26
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Message</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1476" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D469411515-12112004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Hi Neil,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D469411515-12112004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D469411515-12112004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>As I said in my previous mail, there seems to =
be confusion=20
for those not familiar with GMPLS terminology. LSP is control plane. =
Nothing new=20
here in this draft. I would suggest those concerned should discuss via =
the ITU-T=20
SG 15 Q12/Q14 lists as the same choices were made for ITU's DCM (G7713.2 =
and=20
G.7713.3) protocols.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D469411515-12112004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D469411515-12112004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Deborah</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D469411515-12112004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D469411515-12112004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> [e-mail]=20
[mailto:[e-mail]] <B>On Behalf Of=20
</B>[e-mail]<BR><B>Sent:</B> Friday, November 12, 2004 =
8:41=20
AM<BR><B>To:</B> [e-mail];=20
[e-mail]<BR><B>Subject:</B> RE: Comment on=20
draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV><SPAN class=3D702164712-12112004><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2>Folks should take note of this advice.&nbsp; We are fully in =
agreement=20
with you on this issue Stephen.</FONT></SPAN></DIV>
<DIV><SPAN class=3D702164712-12112004><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D702164712-12112004><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2>BTW - G.805/809 stuff is not something dreamed-up in ITU just =
for the=20
sake of it.....in fact its really nothing to do with ITU as&nbsp;its =
simply a=20
formal way of capturing/defining the nature of real=20
networks.</FONT></SPAN></DIV>
<DIV><SPAN class=3D702164712-12112004><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2></FONT></SPAN><SPAN class=3D702164712-12112004><FONT =
face=3D"Comic Sans MS"=20
color=3D#800000 size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D702164712-12112004><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2>regards, Neil</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #800000 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
  [e-mail] [mailto:[e-mail]] <B>On =
Behalf Of=20
  </B>Stephen Shew<BR><B>Sent:</B> 11 November 2004 20:02<BR><B>To:</B>=20
  [e-mail]<BR><B>Subject:</B> Comment on=20
  draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt<BR><BR></FONT></DIV>
  <DIV><FONT color=3D#000080 size=3D2><SPAN class=3D687015119-11112004>I =
was not able=20
  to be at the CCAMP meeting today but do have some comments on <FONT=20
  color=3D#000000 size=3D3><FONT=20
  =
size=3D2>draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt</FONT>&nbsp;&nbsp;&nb=
sp;&nbsp;=20
  </FONT></SPAN></FONT></DIV>
  <DIV><FONT color=3D#000080 size=3D2><SPAN=20
  class=3D687015119-11112004></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#000080 size=3D2><SPAN =
class=3D687015119-11112004>It seems that=20
  the goals of the draft could be accomplished more simply by adopting =
the layer=20
  architecture as defined in ITU-T Recommendations G.805 and =
G.809.&nbsp; By=20
  doing this, the specific boundaries between TDM, LSC, etc. don't have =
to be=20
  articulated as they are just layer networks.&nbsp; Also, the =
designation of=20
  TDM does not include the notions of the layers within that (e.g., DS3, =
STS-1,=20
  VC4, etc.) which are important to transport equipment.&nbsp; Adopting =
the=20
  layer architecture also enables a client layer to be supported by an =
inverse=20
  multipling layer such as provided by Virtual Concatenation.&nbsp; Here =
a layer=20
  of finer granularity is use to support a layer of coarser=20
  granularity.</SPAN></FONT></DIV>
  <DIV>&nbsp;</DIV>
  <P dir=3Dltr align=3Dleft><FONT color=3D#000080 size=3D2>Stephen=20
  Shew&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Voice: =
613-763-2462&nbsp;=20
  Fax: [phone]</FONT><BR><FONT color=3D#000080 size=3D2>Nortel - =
Optical=20
  Networks&nbsp; email: [e-mail]</FONT> <BR><FONT =
color=3D#000080=20
  size=3D2>P.O. Box 3511, Station C</FONT> <BR><FONT color=3D#000080 =
size=3D2>Ottawa,=20
  ON K1Y 4H7</FONT> </P>
  <DIV>&nbsp;</DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C4C8CB.8DDF4F26--



Envelope-to: [e-mail]
Delivery-date: Fri, 12 Nov 2004 13:41:24 +0000
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C8BD.33266BD6"
Subject: RE: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
Date: Fri, 12 Nov 2004 13:40:40 -0000
Message-ID: <[e-mail]>
Thread-Topic: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
Thread-Index: AcTIKew1y+pco00tQt2U3CM1qz+LcwAi9FFw
From: <[e-mail]>
To: <[e-mail]>, <[e-mail]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C4C8BD.33266BD6
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Folks should take note of this advice.  We are fully in agreement with
you on this issue Stephen.
=20
BTW - G.805/809 stuff is not something dreamed-up in ITU just for the
sake of it.....in fact its really nothing to do with ITU as its simply a
formal way of capturing/defining the nature of real networks.
=20
regards, Neil

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Stephen Shew
Sent: 11 November 2004 20:02
To: [e-mail]
Subject: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt


I was not able to be at the CCAMP meeting today but do have some
comments on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt    =20
=20
It seems that the goals of the draft could be accomplished more simply
by adopting the layer architecture as defined in ITU-T Recommendations
G.805 and G.809.  By doing this, the specific boundaries between TDM,
LSC, etc. don't have to be articulated as they are just layer networks.
Also, the designation of TDM does not include the notions of the layers
within that (e.g., DS3, STS-1, VC4, etc.) which are important to
transport equipment.  Adopting the layer architecture also enables a
client layer to be supported by an inverse multipling layer such as
provided by Virtual Concatenation.  Here a layer of finer granularity is
use to support a layer of coarser granularity.
=20

Stephen Shew         Voice: 613-763-2462  Fax: [phone]
Nortel - Optical Networks  email: [e-mail]=20
P.O. Box 3511, Station C=20
Ottawa, ON K1Y 4H7=20

=20


------_=_NextPart_001_01C4C8BD.33266BD6
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D702164712-12112004><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2>Folks should take note of this advice.&nbsp; We are fully in =
agreement=20
with you on this issue Stephen.</FONT></SPAN></DIV>
<DIV><SPAN class=3D702164712-12112004><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D702164712-12112004><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2>BTW - G.805/809 stuff is not something dreamed-up in ITU just =
for the=20
sake of it.....in fact its really nothing to do with ITU as&nbsp;its =
simply a=20
formal way of capturing/defining the nature of real=20
networks.</FONT></SPAN></DIV>
<DIV><SPAN class=3D702164712-12112004><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2></FONT></SPAN><SPAN class=3D702164712-12112004><FONT =
face=3D"Comic Sans MS"=20
color=3D#800000 size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D702164712-12112004><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2>regards, Neil</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #800000 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
  [e-mail] [mailto:[e-mail]] <B>On =
Behalf Of=20
  </B>Stephen Shew<BR><B>Sent:</B> 11 November 2004 20:02<BR><B>To:</B>=20
  [e-mail]<BR><B>Subject:</B> Comment on=20
  draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt<BR><BR></FONT></DIV>
  <DIV><FONT color=3D#000080 size=3D2><SPAN class=3D687015119-11112004>I =
was not able=20
  to be at the CCAMP meeting today but do have some comments on <FONT=20
  color=3D#000000 size=3D3><FONT=20
  =
size=3D2>draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt</FONT>&nbsp;&nbsp;&nb=
sp;&nbsp;=20
  </FONT></SPAN></FONT></DIV>
  <DIV><FONT color=3D#000080 size=3D2><SPAN=20
  class=3D687015119-11112004></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#000080 size=3D2><SPAN =
class=3D687015119-11112004>It seems that=20
  the goals of the draft could be accomplished more simply by adopting =
the layer=20
  architecture as defined in ITU-T Recommendations G.805 and =
G.809.&nbsp; By=20
  doing this, the specific boundaries between TDM, LSC, etc. don't have =
to be=20
  articulated as they are just layer networks.&nbsp; Also, the =
designation of=20
  TDM does not include the notions of the layers within that (e.g., DS3, =
STS-1,=20
  VC4, etc.) which are important to transport equipment.&nbsp; Adopting =
the=20
  layer architecture also enables a client layer to be supported by an =
inverse=20
  multipling layer such as provided by Virtual Concatenation.&nbsp; Here =
a layer=20
  of finer granularity is use to support a layer of coarser=20
  granularity.</SPAN></FONT></DIV>
  <DIV>&nbsp;</DIV>
  <P dir=3Dltr align=3Dleft><FONT color=3D#000080 size=3D2>Stephen=20
  Shew&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Voice: =
613-763-2462&nbsp;=20
  Fax: [phone]</FONT><BR><FONT color=3D#000080 size=3D2>Nortel - =
Optical=20
  Networks&nbsp; email: [e-mail]</FONT> <BR><FONT =
color=3D#000080=20
  size=3D2>P.O. Box 3511, Station C</FONT> <BR><FONT color=3D#000080 =
size=3D2>Ottawa,=20
  ON K1Y 4H7</FONT> </P>
  <DIV>&nbsp;</DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C4C8BD.33266BD6--



Envelope-to: [e-mail]
Delivery-date: Fri, 12 Nov 2004 02:31:16 +0000
Message-ID: <00ca01c4c85f$45ffd920$a7878182@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Varma, Eve L (Eve)" <[e-mail]>
Cc: "'Stephen Shew'" <[e-mail]>, <[e-mail]>
Subject: Re: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
Date: Fri, 12 Nov 2004 02:25:22 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi Eve,

As you know, those of us who do not work for ITU affiliate companies can only access three
ITU recommendations a year without paying for them. This makes it very hard for us to
consider all of the architecture documents.

I wonder if you could forward CCAMP a copy of G.809 (G.805 is well-known in this
community) so that we can include it in our discussions.

Thanks,
Adrian



----- Original Message ----- 
From: "Varma, Eve L (Eve)" <[e-mail]>
To: "'Stephen Shew'" <[e-mail]>; <[e-mail]>
Sent: Thursday, November 11, 2004 9:09 PM
Subject: RE: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt


> Stephen,  What you say makes alot of sense to me.
>
> Eve
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On Behalf Of Stephen
Shew
> Sent: Thursday, November 11, 2004 3:02 PM
> To: [e-mail]
> Subject: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
>
>
> I was not able to be at the CCAMP meeting today but do have some comments on
draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
>
> It seems that the goals of the draft could be accomplished more simply by adopting the
layer architecture as defined in ITU-T Recommendations G.805 and G.809.  By doing this,
the specific boundaries between TDM, LSC, etc. don't have to be articulated as they are
just layer networks.  Also, the designation of TDM does not include the notions of the
layers within that (e.g., DS3, STS-1, VC4, etc.) which are important to transport
equipment.  Adopting the layer architecture also enables a client layer to be supported by
an inverse multipling layer such as provided by Virtual Concatenation.  Here a layer of
finer granularity is use to support a layer of coarser granularity.
>
>
> Stephen Shew         Voice: 613-763-2462  Fax: [phone]
> Nortel - Optical Networks  email: [e-mail]
> P.O. Box 3511, Station C
> Ottawa, ON K1Y 4H7
>
>
>
>




Envelope-to: [e-mail]
Delivery-date: Fri, 12 Nov 2004 02:20:37 +0000
Message-ID: <00b901c4c85d$de464f40$a7878182@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "Stephen Shew" <[e-mail]>
Subject: Re: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
Date: Fri, 12 Nov 2004 02:17:52 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi Stephen,

> I was not able to be at the CCAMP meeting today but do have some comments on
> draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt

Glad you were able to review the draft. Thanks for taking the time.
The slides for this and the other CCAMP drafts discussed at the meeting can be found at
http://www.olddog.co.uk/61/ccamp.htm

> It seems that the goals of the draft could be accomplished more simply by
> adopting the layer architecture as defined in ITU-T Recommendations G.805
> and G.809.  By doing this, the specific boundaries between TDM, LSC, etc.
> don't have to be articulated as they are just layer networks.  Also, the
> designation of TDM does not include the notions of the layers within that
> (e.g., DS3, STS-1, VC4, etc.) which are important to transport equipment.
> Adopting the layer architecture also enables a client layer to be supported
> by an inverse multipling layer such as provided by Virtual Concatenation.
> Here a layer of finer granularity is use to support a layer of coarser
> granularity.

Thank you for the pointer to G.805 and G.809.  It is very important to attempt to align
the terminologies so that we can discover whether the architectures are the same and
whether they are trying to address the same problem space. It is also always good to try
not to reinvent the wheel.

As you have no doubt noticed, the GMPLS architecture and problem space require the
capability to signal and route across multiple instances of what the ITU-T terms a
transport layer. We would gladly look at any architecture you have in this space. Can you
point us at the ITU-T document(s) that describe the architecture and solutions for routing
and signaling across multiple layers?

Thanks,
Adrian

PS As pointed out by several people in other emails, I'm not sure if we mean exactly the
same thing when we say multi-region
and multi-layer. It would be valuable if you could read the GMPLS architecture RFC and the
hierarchy draft and comment on whether you see these terms in the IETF context as matching
perfectly with ITU-T terms.




Envelope-to: [e-mail]
Delivery-date: Thu, 11 Nov 2004 22:25:39 +0000
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C83D.2E58A73C"
Subject: RE: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
Date: Thu, 11 Nov 2004 16:24:16 -0600
Message-ID: <[e-mail]>
Thread-Topic: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
Thread-Index: AcTIKcmJbGUmeukBTUi2mI+ri4xf9gABsQqA
From: "Brungard, Deborah A, ALABS" <[e-mail]>
To: "Stephen Shew" <[e-mail]>, <[e-mail]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C4C83D.2E58A73C
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Stephen,
=20
Thanks for your comments, we are glad to see the interest our draft is
receiving considering the original draft
(draft-vigoureux-shiomoto-ccamp-gmpls-mrn) submitted multiple times
since early 2003 did not;-) Our decision to split the document is
proving to have been a good move.
=20
We had no intention in this draft to introduce any new terminology, we
are using the terminology from the base GMPLS documents and
draft-ietf-mpls-lsp-hierarchy. RFC3471 and lsp-hierarchy (Section 7.1)
defines LSP regions and boundaries i.e. control plane boundaries based
on the (GMPLS) interface switching type (i.e. PSC, L2SC, TDM, LSC, FCS).
We have adopted the ITU terminology of layer when referring to data
(transport) plane (also in the GMPLS base documents).
=20
We asked at the meeting for comments to provide specific text pointers
(can send either privately or via the exploder).
=20
I am not sure the meaning of your comment "adopt the layer architecture
of ITU"? As a similar comment was made at the meeting "GMPLS switching
capabilities are not aligned with ITU layering" and in a follow-up mail
by Eve, we repeat our response, this draft is not defining (new) GMPLS
switching capabilities (or architecture). The definition of GMPLS
switching capabilities is not within the scope of this draft - they are
defined in the base GMPLS documents. Any concerns should target the
appropriate document (RFC3473, ...).=20
=20
Deborah

  _____ =20

From: [e-mail] [mailto:[e-mail]] On
Behalf Of Stephen Shew
Sent: Thursday, November 11, 2004 3:02 PM
To: [e-mail]
Subject: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt


I was not able to be at the CCAMP meeting today but do have some
comments on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt    =20
=20
It seems that the goals of the draft could be accomplished more simply
by adopting the layer architecture as defined in ITU-T Recommendations
G.805 and G.809.  By doing this, the specific boundaries between TDM,
LSC, etc. don't have to be articulated as they are just layer networks.
Also, the designation of TDM does not include the notions of the layers
within that (e.g., DS3, STS-1, VC4, etc.) which are important to
transport equipment.  Adopting the layer architecture also enables a
client layer to be supported by an inverse multipling layer such as
provided by Virtual Concatenation.  Here a layer of finer granularity is
use to support a layer of coarser granularity.
=20

Stephen Shew         Voice: 613-763-2462  Fax: [phone]
Nortel - Optical Networks  email: [e-mail]=20
P.O. Box 3511, Station C=20
Ottawa, ON K1Y 4H7=20

=20

------_=_NextPart_001_01C4C83D.2E58A73C
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Message</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1476" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D470535320-11112004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Hi Stephen,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D470535320-11112004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D470535320-11112004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Thanks for your comments, we are glad to see =
the interest=20
our draft is receiving considering the original draft=20
(draft-vigoureux-shiomoto-ccamp-gmpls-mrn) submitted multiple times =
since early=20
2003 did not;-) Our decision to split the document is proving to have =
been a=20
good move.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D470535320-11112004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D470535320-11112004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>We had no intention in this draft to introduce =
any new=20
terminology, we are using the terminology from the base GMPLS documents =
and=20
draft-ietf-mpls-lsp-hierarchy. RFC3471 and&nbsp;lsp-hierarchy (Section =
7.1)=20
defines LSP regions and boundaries i.e. control plane boundaries based =
on the=20
(GMPLS) interface switching type (i.e. PSC, L2SC, TDM, LSC, FCS).=20
</FONT></SPAN><SPAN class=3D470535320-11112004><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>We have adopted the ITU terminology of layer when referring to =
data=20
(transport) plane (also in the GMPLS base =
documents).</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D470535320-11112004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D470535320-11112004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>We asked at the meeting&nbsp;for =
comments&nbsp;to=20
provide&nbsp;specific text pointers (can send either privately or via =
the=20
exploder).</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D470535320-11112004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D470535320-11112004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>I am not sure&nbsp;the&nbsp;meaning of =
your&nbsp;comment=20
"adopt the layer architecture of ITU"? As a similar comment was made at =
the=20
meeting "GMPLS switching capabilities&nbsp;are not aligned with ITU =
layering"=20
and&nbsp;in a&nbsp;follow-up mail by Eve, we&nbsp;repeat our response, =
this=20
draft is not defining (new) GMPLS switching capabilities (or =
architecture).=20
The&nbsp;definition of GMPLS switching capabilities is not within the =
scope of=20
this draft - they are defined in the base GMPLS documents.&nbsp;Any =
concerns=20
should target the appropriate document (RFC3473, ...). =
</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D470535320-11112004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D470535320-11112004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Deborah</FONT></SPAN></DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> [e-mail]=20
[mailto:[e-mail]] <B>On Behalf Of </B>Stephen=20
Shew<BR><B>Sent:</B> Thursday, November 11, 2004 3:02 PM<BR><B>To:</B>=20
[e-mail]<BR><B>Subject:</B> Comment on=20
draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV><FONT color=3D#000080 size=3D2><SPAN class=3D687015119-11112004>I =
was not able to=20
be at the CCAMP meeting today but do have some comments on <FONT =
color=3D#000000=20
size=3D3><FONT=20
size=3D2>draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt</FONT>&nbsp;&nbsp;&nb=
sp;&nbsp;=20
</FONT></SPAN></FONT></DIV>
<DIV><FONT color=3D#000080 size=3D2><SPAN=20
class=3D687015119-11112004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000080 size=3D2><SPAN class=3D687015119-11112004>It =
seems that the=20
goals of the draft could be accomplished more simply by adopting the =
layer=20
architecture as defined in ITU-T Recommendations G.805 and G.809.&nbsp; =
By doing=20
this, the specific boundaries between TDM, LSC, etc. don't have to be=20
articulated as they are just layer networks.&nbsp; Also, the designation =
of TDM=20
does not include the notions of the layers within that (e.g., DS3, =
STS-1, VC4,=20
etc.) which are important to transport equipment.&nbsp; Adopting the =
layer=20
architecture also enables a client layer to be supported by an inverse=20
multipling layer such as provided by Virtual Concatenation.&nbsp; Here a =
layer=20
of finer granularity is use to support a layer of coarser=20
granularity.</SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<P dir=3Dltr align=3Dleft><FONT color=3D#000080 size=3D2>Stephen=20
Shew&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Voice: =
613-763-2462&nbsp;=20
Fax: [phone]</FONT><BR><FONT color=3D#000080 size=3D2>Nortel - =
Optical=20
Networks&nbsp; email: [e-mail]</FONT> <BR><FONT =
color=3D#000080=20
size=3D2>P.O. Box 3511, Station C</FONT> <BR><FONT color=3D#000080 =
size=3D2>Ottawa, ON=20
K1Y 4H7</FONT> </P>
<DIV>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C4C83D.2E58A73C--



Envelope-to: [e-mail]
Delivery-date: Thu, 11 Nov 2004 21:47:16 +0000
Message-ID: <[e-mail]>
Date: Thu, 11 Nov 2004 22:46:35 +0100
From: dimitri papadimitriou <[e-mail]>
Reply-To: [e-mail],  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910
MIME-Version: 1.0
To: Stephen Shew <[e-mail]>
CC: [e-mail]
Subject: Re: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

stephen, just to clarify, the slides discussed during this morning 
meeting explain the document'scope = multi-REGION-networks

where REGIONs are based on Switching Capability (SC) as being defined in 
the LSP hierarchy document:

<http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-hierarchy-08.txt>

the discussion is not about data plane layering/relationship or other 
specific aspects related to the data plane layer architecture (ex: 
G.805), in brief, the discussion is all about control plane -> in the 
present context a multiple SC control plane

note: for those that where not present at the meeting the slides 
discussed can be found at:

<http://home.clara.net/olddog/61/draft-shiomoto-ccamp-gmpls-mrn-reqs-00.ppt>
---

Stephen Shew wrote:

> I was not able to be at the CCAMP meeting today but do have some comments on
> draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt     
>  
> It seems that the goals of the draft could be accomplished more simply by
> adopting the layer architecture as defined in ITU-T Recommendations G.805
> and G.809.  By doing this, the specific boundaries between TDM, LSC, etc.
> don't have to be articulated as they are just layer networks.  Also, the
> designation of TDM does not include the notions of the layers within that
> (e.g., DS3, STS-1, VC4, etc.) which are important to transport equipment.
> Adopting the layer architecture also enables a client layer to be supported
> by an inverse multipling layer such as provided by Virtual Concatenation.
> Here a layer of finer granularity is use to support a layer of coarser
> granularity.
>  
> 
> Stephen Shew         Voice: 613-763-2462  Fax: [phone]
> Nortel - Optical Networks  email: [e-mail] 
> P.O. Box 3511, Station C 
> Ottawa, ON K1Y 4H7 
> 
>  
> 



Envelope-to: [e-mail]
Delivery-date: Thu, 11 Nov 2004 21:21:54 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C834.528365E3"
Subject: RE: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
Date: Thu, 11 Nov 2004 15:20:51 -0600
Message-ID: <[e-mail]>
Thread-Topic: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
thread-index: AcTIKfZIiskmgz23RcyQd4W2leN6VwACgvIw
From: "Mack-Crane, T. Benjamin" <[e-mail]>
To: "Stephen Shew" <[e-mail]>, <[e-mail]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C4C834.528365E3
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Stephen,

=20

This sounds like a good practical approach.

=20

Ben

=20

________________________________

From: [e-mail] [mailto:[e-mail]] On
Behalf Of Stephen Shew
Sent: Thursday, November 11, 2004 2:02 PM
To: [e-mail]
Subject: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt

=20

I was not able to be at the CCAMP meeting today but do have some
comments on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt    =20

=20

It seems that the goals of the draft could be accomplished more simply
by adopting the layer architecture as defined in ITU-T Recommendations
G.805 and G.809.  By doing this, the specific boundaries between TDM,
LSC, etc. don't have to be articulated as they are just layer networks.
Also, the designation of TDM does not include the notions of the layers
within that (e.g., DS3, STS-1, VC4, etc.) which are important to
transport equipment.  Adopting the layer architecture also enables a
client layer to be supported by an inverse multipling layer such as
provided by Virtual Concatenation.  Here a layer of finer granularity is
use to support a layer of coarser granularity.

=20

Stephen Shew         Voice: 613-763-2462  Fax: [phone]
Nortel - Optical Networks  email: [e-mail]=20
P.O. Box 3511, Station C=20
Ottawa, ON K1Y 4H7=20

=20


------_=_NextPart_001_01C4C834.528365E3
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered)">
<title>Message</title>
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p
	{margin-right:0in;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle18
	{font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Stephen,</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>This sounds like a good practical
approach.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Ben</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> =
[e-mail]
[mailto:[e-mail]] <b><span style=3D'font-weight:bold'>On =
Behalf
Of </span></b>Stephen Shew<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Thursday, November =
11, 2004
2:02 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> =
[e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Comment on
draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt</span></font></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt;color:navy'>I was not able to be at the CCAMP =
meeting
today but do have some comments on </span></font><font size=3D2 =
color=3Dblack><span
style=3D'font-size:10.0pt;color:black'>draft-shiomoto-ccamp-gmpls-mrn-req=
s-00.txt</span></font><font
color=3Dblack><span style=3D'color:black'>&nbsp;&nbsp;&nbsp;&nbsp; =
</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt;color:navy'>It seems that the goals of the =
draft could
be accomplished more simply by adopting the layer architecture as =
defined in
ITU-T Recommendations G.805 and G.809.&nbsp; By doing this, the specific
boundaries between TDM, LSC, etc. don't have to be articulated as they =
are just
layer networks.&nbsp; Also, the designation of TDM does not include the =
notions
of the layers within that (e.g., DS3, STS-1, VC4, etc.) which are =
important to
transport equipment.&nbsp; Adopting the layer architecture also enables =
a
client layer to be supported by an inverse multipling layer such as =
provided by
Virtual Concatenation.&nbsp; Here a layer of finer granularity is use to
support a layer of coarser granularity.</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

</div>

<p><font size=3D2 color=3Dnavy face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt;
color:navy'>Stephen Shew&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Voice:
613-763-2462&nbsp; Fax: [phone]</span></font><br>
<font size=3D2 color=3Dnavy><span =
style=3D'font-size:10.0pt;color:navy'>Nortel -
Optical Networks&nbsp; email: [e-mail]</span></font> =
<br>
<font size=3D2 color=3Dnavy><span =
style=3D'font-size:10.0pt;color:navy'>P.O. Box
3511, Station C</span></font> <br>
<font size=3D2 color=3Dnavy><span =
style=3D'font-size:10.0pt;color:navy'>Ottawa, ON
K1Y 4H7</span></font> </p>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01C4C834.528365E3--



Envelope-to: [e-mail]
Delivery-date: Thu, 11 Nov 2004 21:10:51 +0000
Message-ID: <[e-mail]>
From: "Varma, Eve L (Eve)" <[e-mail]>
To: "'Stephen Shew'" <[e-mail]>, [e-mail]
Subject: RE: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
Date: Thu, 11 Nov 2004 16:09:26 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C832.8D1C485C"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C4C832.8D1C485C
Content-Type: text/plain

Stephen,  What you say makes alot of sense to me.
 
Eve

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On Behalf Of Stephen Shew
Sent: Thursday, November 11, 2004 3:02 PM
To: [e-mail]
Subject: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt


I was not able to be at the CCAMP meeting today but do have some comments on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt     
 
It seems that the goals of the draft could be accomplished more simply by adopting the layer architecture as defined in ITU-T Recommendations G.805 and G.809.  By doing this, the specific boundaries between TDM, LSC, etc. don't have to be articulated as they are just layer networks.  Also, the designation of TDM does not include the notions of the layers within that (e.g., DS3, STS-1, VC4, etc.) which are important to transport equipment.  Adopting the layer architecture also enables a client layer to be supported by an inverse multipling layer such as provided by Virtual Concatenation.  Here a layer of finer granularity is use to support a layer of coarser granularity.
 

Stephen Shew         Voice: 613-763-2462  Fax: [phone]
Nortel - Optical Networks  email: [e-mail] 
P.O. Box 3511, Station C 
Ottawa, ON K1Y 4H7 

 


------_=_NextPart_001_01C4C832.8D1C485C
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<TITLE>Message</TITLE>

<META content="MSHTML 6.00.2800.1458" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=278090821-11112004><FONT face=Arial color=#0000ff 
size=2>Stephen,&nbsp; </FONT></SPAN><SPAN class=278090821-11112004><FONT 
face=Arial color=#0000ff size=2>What you say makes alot of sense to 
me.</FONT></SPAN></DIV>
<DIV>&nbsp;</DIV>
<DIV><SPAN class=278090821-11112004><FONT face=Arial color=#0000ff 
size=2>Eve</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> [e-mail] 
  [mailto:[e-mail]]<B>On Behalf Of </B>Stephen 
  Shew<BR><B>Sent:</B> Thursday, November 11, 2004 3:02 PM<BR><B>To:</B> 
  [e-mail]<BR><B>Subject:</B> Comment on 
  draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt<BR><BR></FONT></DIV>
  <DIV><FONT color=#000080 size=2><SPAN class=687015119-11112004>I was not able 
  to be at the CCAMP meeting today but do have some comments on <FONT 
  color=#000000 size=3><FONT 
  size=2>draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt</FONT>&nbsp;&nbsp;&nbsp;&nbsp; 
  </FONT></SPAN></FONT></DIV>
  <DIV><FONT color=#000080 size=2><SPAN 
  class=687015119-11112004></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#000080 size=2><SPAN class=687015119-11112004>It seems that 
  the goals of the draft could be accomplished more simply by adopting the layer 
  architecture as defined in ITU-T Recommendations G.805 and G.809.&nbsp; By 
  doing this, the specific boundaries between TDM, LSC, etc. don't have to be 
  articulated as they are just layer networks.&nbsp; Also, the designation of 
  TDM does not include the notions of the layers within that (e.g., DS3, STS-1, 
  VC4, etc.) which are important to transport equipment.&nbsp; Adopting the 
  layer architecture also enables a client layer to be supported by an inverse 
  multipling layer such as provided by Virtual Concatenation.&nbsp; Here a layer 
  of finer granularity is use to support a layer of coarser 
  granularity.</SPAN></FONT></DIV>
  <DIV>&nbsp;</DIV>
  <P dir=ltr align=left><FONT color=#000080 size=2>Stephen 
  Shew&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Voice: 613-763-2462&nbsp; 
  Fax: [phone]</FONT><BR><FONT color=#000080 size=2>Nortel - Optical 
  Networks&nbsp; email: [e-mail]</FONT> <BR><FONT color=#000080 
  size=2>P.O. Box 3511, Station C</FONT> <BR><FONT color=#000080 size=2>Ottawa, 
  ON K1Y 4H7</FONT> </P>
  <DIV>&nbsp;</DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C4C832.8D1C485C--



Envelope-to: [e-mail]
Delivery-date: Thu, 11 Nov 2004 20:04:56 +0000
Message-ID: <[e-mail]>
From: "Stephen Shew" <[e-mail]>
To: [e-mail]
Subject: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
Date: Thu, 11 Nov 2004 15:02:26 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C829.5DAE5487"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C4C829.5DAE5487
Content-Type: text/plain

I was not able to be at the CCAMP meeting today but do have some comments on
draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt     
 
It seems that the goals of the draft could be accomplished more simply by
adopting the layer architecture as defined in ITU-T Recommendations G.805
and G.809.  By doing this, the specific boundaries between TDM, LSC, etc.
don't have to be articulated as they are just layer networks.  Also, the
designation of TDM does not include the notions of the layers within that
(e.g., DS3, STS-1, VC4, etc.) which are important to transport equipment.
Adopting the layer architecture also enables a client layer to be supported
by an inverse multipling layer such as provided by Virtual Concatenation.
Here a layer of finer granularity is use to support a layer of coarser
granularity.
 

Stephen Shew         Voice: 613-763-2462  Fax: [phone]
Nortel - Optical Networks  email: [e-mail] 
P.O. Box 3511, Station C 
Ottawa, ON K1Y 4H7 

 

------_=_NextPart_001_01C4C829.5DAE5487
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<TITLE>Message</TITLE>

<META content="MSHTML 6.00.2800.1476" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#000080 size=2><SPAN class=687015119-11112004>I was not able to 
be at the CCAMP meeting today but do have some comments on <FONT color=#000000 
size=3><FONT 
size=2>draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt</FONT>&nbsp;&nbsp;&nbsp;&nbsp; 
</FONT></SPAN></FONT></DIV>
<DIV><FONT color=#000080 size=2><SPAN 
class=687015119-11112004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#000080 size=2><SPAN class=687015119-11112004>It seems that the 
goals of the draft could be accomplished more simply by adopting the layer 
architecture as defined in ITU-T Recommendations G.805 and G.809.&nbsp; By doing 
this, the specific boundaries between TDM, LSC, etc. don't have to be 
articulated as they are just layer networks.&nbsp; Also, the designation of TDM 
does not include the notions of the layers within that (e.g., DS3, STS-1, VC4, 
etc.) which are important to transport equipment.&nbsp; Adopting the layer 
architecture also enables a client layer to be supported by an inverse 
multipling layer such as provided by Virtual Concatenation.&nbsp; Here a layer 
of finer granularity is use to support a layer of coarser 
granularity.</SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<P dir=ltr align=left><FONT color=#000080 size=2>Stephen 
Shew&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Voice: 613-763-2462&nbsp; 
Fax: [phone]</FONT><BR><FONT color=#000080 size=2>Nortel - Optical 
Networks&nbsp; email: [e-mail]</FONT> <BR><FONT color=#000080 
size=2>P.O. Box 3511, Station C</FONT> <BR><FONT color=#000080 size=2>Ottawa, ON 
K1Y 4H7</FONT> </P>
<DIV>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C4C829.5DAE5487--



Envelope-to: [e-mail]
Delivery-date: Wed, 10 Nov 2004 21:48:26 +0000
From: "Richard Rabbat" <[e-mail]>
To: <[e-mail]>
Cc: "'Richard Rabbat'" <[e-mail]>
Subject: RE: GMPLS topics and issues of study
Date: Wed, 10 Nov 2004 13:46:02 -0800
Message-ID: <001001c4c76e$acd8dd00$6e878182@PHOENIX>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0011_01C4C72B.9EB59D00"

This is a multi-part message in MIME format.

------=_NextPart_000_0011_01C4C72B.9EB59D00
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Please note that the list under "Addressing" that we compiled and sent =
out
is based on the Isocore interoperability testing.
The other items:
--
RSVP message contents:
1: ERO/RRO: choice of outgoing vs. incoming interface ID
2: Forwarding destination of Path message with ERO
Control channel:
1: Best practice where multiple IP hops lie between adjacent nodes
--
are from another source so we can combine these issues as well.
Richard
=20

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On =
Behalf
Of Richard Rabbat
Sent: Wednesday, November 10, 2004 11:27 AM
To: [e-mail]
Cc: 'Rajiv Papneja'; 'Ashok Narayanan'; 'Eiji Oki'; 'Pandian, Vijay'; =
'Ong,
Lyndon'; 'Hari Rakotoranto'; [e-mail];
[e-mail]; [e-mail]
Subject: GMPLS topics and issues of study


Hi all,
=20
Based on Isocore interoperability testing results from the past few =
months,
we've found the following issues to have caused some confusion and
differences in implementation.  We'll list them here in no specific =
order
under 3 major headings.
=20
Addressing:
1. relationship between TE Router ID and OSPF router ID=20
1.1 where to use TE Router ID, OSPF Router ID and IPCC Address=20
=20
2: IP reachability (what ID's are reachable IP addresses)
=20
3: what address is used in the signaling message in the ERO/RRO
=20
4: what is used in in the IF_ID_RSVP_HOP
4.1: IP v4 Next/Previous Hop address
4.2: IPv4 address in the value field
=20
5:  what is used in the destination IPv4 address in the session object=20
=20
6:  what is used in the sender IPv4 address in sender object template
=20
7:  what is used as the Router ID in LSP_TUNNEL_INTERFACE_ID
=20
RSVP message contents:
=20
1: ERO/RRO: choice of outgoing vs. incoming interface ID
=20
2: Forwarding destination of Path message with ERO
=20
Control channel:
=20
1: Best practice where multiple IP hops lie between adjacent nodes
=20
2: use of redundant/multiple IPCC. best practices=20
=20
We're in the process of putting together what we hope to be a =
comprehensive
list of topics that may cause interop concerns. If people have thoughts
about other concerns as well, it would be great if you can email them to =
the
list or contact us directly.
=20
Yumiko Kawashima
Ashok Narayanan
Eiji Oki
Lyndon Ong
Vijay Pandian
Rajiv Papneja  =20
Richard Rabbat
Hari Rakotoranto
Kohei Shiomoto
Tomonori Takeda


------=_NextPart_000_0011_01C4C72B.9EB59D00
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2900.2523" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial><FONT size=3D2><SPAN =
class=3D516003921-10112004><SPAN=20
class=3D186554421-10112004>Please note that </SPAN>t</SPAN><SPAN=20
class=3D516003921-10112004>he list under "Addressing" that&nbsp;we =
compiled and=20
sent out is based on the Isocore interoperability=20
testing.</SPAN></FONT></FONT></DIV>
<DIV><SPAN class=3D516003921-10112004><FONT face=3DArial =
size=3D2>The<SPAN=20
class=3D186554421-10112004> other</SPAN>&nbsp;items:</FONT></SPAN></DIV>
<DIV><SPAN class=3D516003921-10112004><FONT face=3DArial=20
size=3D2>--</FONT></SPAN></DIV>
<DIV><SPAN class=3D516003921-10112004>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2>RSVP message contents:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>1: ERO/RRO: choice of outgoing =
vs. incoming=20
interface ID</FONT></DIV></DIV>
<DIV><FONT face=3DArial size=3D2>2: Forwarding destination of Path =
message with=20
ERO</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Control channel:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>1: Best practice where multiple IP hops =
lie between=20
adjacent nodes</FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D516003921-10112004>--</SPAN></FONT></DIV></SPAN></DIV>
<DIV><SPAN class=3D516003921-10112004><FONT face=3DArial size=3D2>are =
from another=20
source so we can combine these issues as well.</FONT></SPAN></DIV>
<DIV><SPAN class=3D516003921-10112004><FONT face=3DArial=20
size=3D2>Richard</FONT></SPAN></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
  [e-mail] [mailto:[e-mail]] <B>On =
Behalf Of=20
  </B>Richard Rabbat<BR><B>Sent:</B> Wednesday, November 10, 2004 11:27=20
  AM<BR><B>To:</B> [e-mail]<BR><B>Cc:</B> 'Rajiv Papneja'; =
'Ashok=20
  Narayanan'; 'Eiji Oki'; 'Pandian, Vijay'; 'Ong, Lyndon'; 'Hari =
Rakotoranto';=20
  [e-mail]; [e-mail];=20
  [e-mail]<BR><B>Subject:</B> GMPLS topics and =
issues of=20
  study<BR><BR></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>Hi all,</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>Based on Isocore interoperability =
testing results=20
  from the past few months,&nbsp; we've found the following issues to =
have=20
  caused some confusion and differences in implementation.&nbsp; We'll =
list them=20
  here in no specific order<SPAN class=3D874271519-10112004> under 3 =
major=20
  headings</SPAN>.</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>Addressing:<BR>1. relationship =
between TE Router=20
  ID and OSPF router ID <BR>1.1 where to use TE Router ID, OSPF Router =
ID and=20
  IPCC Address </FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>2: IP reachability (what ID's are =
reachable IP=20
  addresses)</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>3: what address is used in the =
signaling message=20
  in the ERO/RRO</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>4: what is used in in the =
IF_ID_RSVP_HOP<BR>4.1:=20
  IP v4 Next/Previous Hop address<BR>4.2: IPv4 address in the value=20
  field</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>5:&nbsp; what is used in the =
destination IPv4=20
  address in the session object </FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>6:&nbsp; what is used in the sender =
IPv4 address=20
  in sender object template</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>7:&nbsp; what is used as the Router =
ID in=20
  LSP_TUNNEL_INTERFACE_ID</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>RSVP message contents:</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>1: ERO/RRO: choice of outgoing vs. =
incoming=20
  interface ID</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>2: Forwarding destination of Path =
message with=20
  ERO</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>Control channel:</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>1: Best practice where multiple IP =
hops lie=20
  between adjacent nodes</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>2: use of redundant/multiple IPCC. =
best practices=20
  <BR>&nbsp;<BR>We're in the process of putting together what we hope to =
be a=20
  comprehensive list of topics that may cause interop concerns. If =
people have=20
  thoughts about other concerns as well, it would be great if you can =
email them=20
  to the list or contact us directly.</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>Yumiko Kawashima<BR>Ashok =
Narayanan<BR>Eiji=20
  Oki<BR>Lyndon Ong<BR>Vijay Pandian<BR>Rajiv Papneja&nbsp;&nbsp; =
<BR>Richard=20
  Rabbat<BR>Hari Rakotoranto<BR>Kohei Shiomoto<BR>Tomonori=20
Takeda</FONT></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0011_01C4C72B.9EB59D00--




Envelope-to: [e-mail]
Delivery-date: Wed, 10 Nov 2004 19:29:00 +0000
From: "Richard Rabbat" <[e-mail]>
To: <[e-mail]>
Cc: "'Rajiv Papneja'" <[e-mail]>, "'Ashok Narayanan'" <[e-mail]>, "'Eiji Oki'" <[e-mail]>, "'Pandian, Vijay'" <[e-mail]>, "'Ong, Lyndon'" <[e-mail]>, "'Hari Rakotoranto'" <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: GMPLS topics and issues of study
Date: Wed, 10 Nov 2004 11:27:10 -0800
Message-ID: <002901c4c75b$492e02c0$6e878182@PHOENIX>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_002A_01C4C718.3B0AC2C0"

This is a multi-part message in MIME format.

------=_NextPart_000_002A_01C4C718.3B0AC2C0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi all,
=20
Based on Isocore interoperability testing results from the past few =
months,
we've found the following issues to have caused some confusion and
differences in implementation.  We'll list them here in no specific =
order
under 3 major headings.
=20
Addressing:
1. relationship between TE Router ID and OSPF router ID=20
1.1 where to use TE Router ID, OSPF Router ID and IPCC Address=20
=20
2: IP reachability (what ID's are reachable IP addresses)
=20
3: what address is used in the signaling message in the ERO/RRO
=20
4: what is used in in the IF_ID_RSVP_HOP
4.1: IP v4 Next/Previous Hop address
4.2: IPv4 address in the value field
=20
5:  what is used in the destination IPv4 address in the session object=20
=20
6:  what is used in the sender IPv4 address in sender object template
=20
7:  what is used as the Router ID in LSP_TUNNEL_INTERFACE_ID
=20
RSVP message contents:
=20
1: ERO/RRO: choice of outgoing vs. incoming interface ID
=20
2: Forwarding destination of Path message with ERO
=20
Control channel:
=20
1: Best practice where multiple IP hops lie between adjacent nodes
=20
2: use of redundant/multiple IPCC. best practices=20
=20
We're in the process of putting together what we hope to be a =
comprehensive
list of topics that may cause interop concerns. If people have thoughts
about other concerns as well, it would be great if you can email them to =
the
list or contact us directly.
=20
Yumiko Kawashima
Ashok Narayanan
Eiji Oki
Lyndon Ong
Vijay Pandian
Rajiv Papneja  =20
Richard Rabbat
Hari Rakotoranto
Kohei Shiomoto
Tomonori Takeda

------=_NextPart_000_002A_01C4C718.3B0AC2C0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2900.2523" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2>Hi all,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Based on Isocore interoperability =
testing results=20
from the past few months,&nbsp; we've found the following issues to have =
caused=20
some confusion and differences in implementation.&nbsp; We'll list them =
here in=20
no specific order<SPAN class=3D874271519-10112004> under 3 major=20
headings</SPAN>.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Addressing:<BR>1. relationship between =
TE Router ID=20
and OSPF router ID <BR>1.1 where to use TE Router ID, OSPF Router ID and =
IPCC=20
Address </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>2: IP reachability (what ID's are =
reachable IP=20
addresses)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>3: what address is used in the =
signaling message in=20
the ERO/RRO</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>4: what is used in in the =
IF_ID_RSVP_HOP<BR>4.1: IP=20
v4 Next/Previous Hop address<BR>4.2: IPv4 address in the value=20
field</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>5:&nbsp; what is used in the =
destination IPv4=20
address in the session object </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>6:&nbsp; what is used in the sender =
IPv4 address in=20
sender object template</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>7:&nbsp; what is used as the Router ID =
in=20
LSP_TUNNEL_INTERFACE_ID</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>RSVP message contents:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>1: ERO/RRO: choice of outgoing vs. =
incoming=20
interface ID</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>2: Forwarding destination of Path =
message with=20
ERO</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Control channel:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>1: Best practice where multiple IP hops =
lie between=20
adjacent nodes</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>2: use of redundant/multiple IPCC. best =
practices=20
<BR>&nbsp;<BR>We're in the process of putting together what we hope to =
be a=20
comprehensive list of topics that may cause interop concerns. If people =
have=20
thoughts about other concerns as well, it would be great if you can =
email them=20
to the list or contact us directly.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Yumiko Kawashima<BR>Ashok =
Narayanan<BR>Eiji=20
Oki<BR>Lyndon Ong<BR>Vijay Pandian<BR>Rajiv Papneja&nbsp;&nbsp; =
<BR>Richard=20
Rabbat<BR>Hari Rakotoranto<BR>Kohei Shiomoto<BR>Tomonori=20
Takeda</FONT></DIV></BODY></HTML>

------=_NextPart_000_002A_01C4C718.3B0AC2C0--




Envelope-to: [e-mail]
Delivery-date: Wed, 10 Nov 2004 15:33:23 +0000
Message-ID: <026901c4c73a$80d80d90$a7878182@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Agenda updates on line
Date: Wed, 10 Nov 2004 15:32:31 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

Agenda at http://www.olddog.co.uk/61/ccamp.htm has pointers to drafts and most slides in
place.

Further updates soon.

Adrian




Envelope-to: [e-mail]
Delivery-date: Wed, 10 Nov 2004 07:39:37 +0000
Message-ID: <0957B4ABF486CF4E8494A29B85DEE51001068635@cms1>
From: =?euc-kr?B?sei/tcit?= <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: A mismatch between the procedure and the message format in LMP
Date: Wed, 10 Nov 2004 16:37:30 +0900
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C6F8.225CB3CA"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C4C6F8.225CB3CA
Content-Type: text/plain;
	charset="euc-kr"

Hi, ccampers

I found a mismatch description between the procedure and the message format
in LMP.
The LMP document that I have read is draft-ietf-ccamp-lmp-10.txt.
The procedure is of the link connectivity verification.
If you see the section 5.1, "Example of Link Connectivity Verification",
the section is now describing as follows:

****************************************************************************
************
	In the section, 5.1,

     o  A sends a BeginVerify message over the control channel to B
        indicating it will begin verifying the ports that form the TE
        link.  The LOCAL_LINK_ID object carried in the BeginVerify
        message carries the identifier (IP address or interface index)
        that A assigns to the link.
     o  Upon receipt of the BeginVerify message, B creates a Verify_Id
        and binds it to the TE Link from A. This binding is used later
        when B receives the Test messages from A, and these messages
        carry the Verify_Id. B discovers the identifier (IP address or
        interface index) that A assigns to the TE link by examining the
        LOCAL_LINK_ID object carried in the received BeginVerify
        message. (If the data ports are not yet assigned to the TE
        Link, the binding is limited to the Node_Id of A.) In response
        to the BeginVerify message, B sends to A the BeginVerifyAck
        message. The LOCAL_LINK_ID object carried in the BeginVerifyAck
        message is used to carry the identifier (IP address or
        interface index) that B assigns to the TE link. The
        REMOTE_LINK_ID object carried in the BeginVerifyAck message is
        used to bind the Link_Ids assigned by both A and B. The
        Verify_Id is returned to A in the BeginVerifyAck message over
        the control channel.

	In the section, 12.5.1,

   <BeginVerify Message> ::= <Common Header> <LOCAL_LINK_ID>
                             <MESSAGE_ID> [<REMOTE_LINK_ID>]
                             <BEGIN_VERIFY>

   The above transmission order SHOULD be followed.

   To limit the scope of Link Verification to a particular TE Link, the
   Link_Id field of the LOCAL_LINK_ID object MUST be non-zero. If this
   field is zero, the data links can span multiple TE links and/or they
   may comprise a TE link that is yet to be configured. In the special
   case where the local Link_Id field is zero, the "Verify all Links"
   flag of the BEGIN_VERIFY object is used to distinguish between data
   links that span multiple TE links and those that have not yet been
   assigned to a TE link (see Section 5).

   The REMOTE_LINK_ID object may be included if the local/remote
   Link_Id mapping is known.

   The Link_Id field of the REMOTE_LINK_ID object MUST be non-zero if
   included.

	In the section, 12.5.2,

   <BeginVerifyAck Message> ::= <Common Header> [<LOCAL_LINK_ID>]
                                <MESSAGE_ID_ACK> <BEGIN_VERIFY_ACK>
                                <VERIFY_ID>

   The above transmission order SHOULD be followed.

   The LOCAL_LINK_ID object may be included if the local/remote Link_Id
   mapping is known or learned through the BeginVerify message.
****************************************************************************
************

There is a discrepancy about the remote Link_id between the text and the
format.
In the text, the remote Link_id has been included in the BeginVerifyAck
message.
But, in the format, the remote Link_id has been included in the BeginVerify
message, not in BeginVerifyAck message.
I think that the text is correct, and the format is not correct.
I'm not sure that I would be reading an old document of LMP.

What do you think of this?

Thanks,

Young.

------_=_NextPart_001_01C4C6F8.225CB3CA
Content-Type: text/html;
	charset="euc-kr"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Deuc-kr">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2657.73">
<TITLE>A mismatch between the procedure and the message format in =
LMP</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi, ccampers</FONT>
</P>

<P><FONT SIZE=3D2>I found a mismatch description between the procedure =
and the message format in LMP.</FONT>
<BR><FONT SIZE=3D2>The LMP document that I have read is =
draft-ietf-ccamp-lmp-10.txt.</FONT>
<BR><FONT SIZE=3D2>The procedure is of the link connectivity =
verification.</FONT>
<BR><FONT SIZE=3D2>If you see the section 5.1, &quot;Example of Link =
Connectivity Verification&quot;, the section is now describing as =
follows:</FONT>
</P>

<P><FONT =
SIZE=3D2>***************************************************************=
*************************</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>In the =
section, 5.1,</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp; o&nbsp; A sends a =
BeginVerify message over the control channel to B</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
indicating it will begin verifying the ports that form the TE</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
link.&nbsp; The LOCAL_LINK_ID object carried in the BeginVerify</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; message =
carries the identifier (IP address or interface index)</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; that A =
assigns to the link.</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp; o&nbsp; Upon receipt of the =
BeginVerify message, B creates a Verify_Id</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; and binds =
it to the TE Link from A. This binding is used later</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; when B =
receives the Test messages from A, and these messages</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; carry the =
Verify_Id. B discovers the identifier (IP address or</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; interface =
index) that A assigns to the TE link by examining the</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
LOCAL_LINK_ID object carried in the received BeginVerify</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; message. =
(If the data ports are not yet assigned to the TE</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Link, the =
binding is limited to the Node_Id of A.) In response</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to the =
BeginVerify message, B sends to A the BeginVerifyAck</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; message. =
The LOCAL_LINK_ID object carried in the BeginVerifyAck</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; message =
is used to carry the identifier (IP address or</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; interface =
index) that B assigns to the TE link. The</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
REMOTE_LINK_ID object carried in the BeginVerifyAck message is</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; used to =
bind the Link_Ids assigned by both A and B. The</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Verify_Id =
is returned to A in the BeginVerifyAck message over</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the =
control channel.</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>In the =
section, 12.5.1,</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; &lt;BeginVerify Message&gt; ::=3D =
&lt;Common Header&gt; &lt;LOCAL_LINK_ID&gt;</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;MESSAGE_ID&gt; =
[&lt;REMOTE_LINK_ID&gt;]</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;BEGIN_VERIFY&gt;</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; The above transmission order SHOULD be =
followed.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; To limit the scope of Link Verification =
to a particular TE Link, the</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; Link_Id field of the LOCAL_LINK_ID =
object MUST be non-zero. If this</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; field is zero, the data links can span =
multiple TE links and/or they</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; may comprise a TE link that is yet to =
be configured. In the special</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; case where the local Link_Id field is =
zero, the &quot;Verify all Links&quot;</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; flag of the BEGIN_VERIFY object is used =
to distinguish between data</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; links that span multiple TE links and =
those that have not yet been</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; assigned to a TE link (see Section =
5).</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; The REMOTE_LINK_ID object may be =
included if the local/remote</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; Link_Id mapping is known.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; The Link_Id field of the REMOTE_LINK_ID =
object MUST be non-zero if</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; included.</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>In the =
section, 12.5.2,</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; &lt;BeginVerifyAck Message&gt; ::=3D =
&lt;Common Header&gt; [&lt;LOCAL_LINK_ID&gt;]</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&lt;MESSAGE_ID_ACK&gt; &lt;BEGIN_VERIFY_ACK&gt;</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&lt;VERIFY_ID&gt;</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; The above transmission order SHOULD be =
followed.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; The LOCAL_LINK_ID object may be included =
if the local/remote Link_Id</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; mapping is known or learned through the =
BeginVerify message.</FONT>
<BR><FONT =
SIZE=3D2>***************************************************************=
*************************</FONT>
</P>

<P><FONT SIZE=3D2>There is a discrepancy about the remote Link_id =
between the text and the format.</FONT>
<BR><FONT SIZE=3D2>In the text, the remote Link_id has been included in =
the BeginVerifyAck message.</FONT>
<BR><FONT SIZE=3D2>But, in the format, the remote Link_id has been =
included in the BeginVerify message, not in BeginVerifyAck =
message.</FONT>
<BR><FONT SIZE=3D2>I think that the text is correct, and the format is =
not correct.</FONT>
<BR><FONT SIZE=3D2>I'm not sure that I would be reading an old document =
of LMP.</FONT>
</P>

<P><FONT SIZE=3D2>What do you think of this?</FONT>
</P>

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

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

</BODY>
</HTML>
------_=_NextPart_001_01C4C6F8.225CB3CA--



Envelope-to: [e-mail]
Delivery-date: Tue, 09 Nov 2004 17:12:00 +0000
Date: Tue, 09 Nov 2004 15:10:13 -0300
To: "Ccamp" <[e-mail]>
From: "Kireeti" <[e-mail]>
Subject: Re:
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="--------zuerbjwdsawkxvvrysuj"

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

<html><body>
<img src="cid:duifgpmtae.jpeg">  <br>
</body></html>

----------zuerbjwdsawkxvvrysuj
Content-Type: image/jpeg; name="duifgpmtae.jpeg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="duifgpmtae.jpeg"
Content-ID: <duifgpmtae.jpeg>

/9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRof
Hh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwh
MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAAR
CAAQAHQDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA
AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK
FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG
h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl
5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA
AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk
NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE
hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk
5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3+iiigCtqFw9ppt1cxhS8ULyKG6EgE81Q
0rWH1VohF5WEhR7kjs7LkKoz9eT9PXF/ULd7vTbq2jKh5YXjUt0BII5qhYaRJYS2EkRiUpbC
C5UZw+BkMOOu7PXHBrkq+19tHl+Hr9/9X8jGfPzq2xdj1OzllkjSbc0YYn5Tggddpxhsd8Zx
To9QtZmt1jl3G5jMkWFPzKMc9OOo61k6fog0yZJZnj8m2EjLK80hO1uTlSdq4HXrnGeKh8NW
sgvbuZmD20OYLRwSQYyxY49RyoyPT2rOFevzRjOKTf4bf8FetiVUqXSkt/6/zOlrGu9TnTV3
tEnggiRI/nlgeTLsWwCQwC9B171qNE5uVlFxKqKMGIBdrdeTxn8j2qjqtjc6lE9pviW1kKEs
Mh12sCcdjnHtj3rfEc7h7m6/H7npr1LqczXuiXWqPDr1hp8aKUn8zzHPUFV3AD36fnVS1125
muvKNuruySsbdMCSHYcAPzg7uMcDr361LPos765ZXsd45ihkkd1fbkbhjC4Xkdjk5x0Oahg0
C4R4ke62xwLOqSo3zyeaerDGBj8cnB4rlk8S5u17X8tvd/8Atv8Ah7WyfteZ+v8Al/wRkPiG
5e2uZFgjuWitlnKwceWxJHltkn5hgk9Oh4FaOk6i9810jNFKsDhVuIfuSZUE4GTgjODzWcPD
lxLayxS3KxH7GlmnlEkMFOd7AgcnpjsCeea0tOsZre5vLqdlElyykxRsWRNq7eCQOT349KKH
1nnjz3t/w/8AwP00uFP2vMub+t/+AaNFFFekdQUUUUAf/9l//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9/ICsgK/9//3+0YyAr2m//f/9/aUMgK/9//3//f/9//3//f7Nf
ICuxWyArs1//f/9//3//f/9//38gKyArICv/f/9//3//f/9//3//f/9/ICtpQ/9/ICsgKyAr
ICsgKyAr/38gKyAr/3//fyArICv/fyArICv/f/9/ICsgK/9/ICsgK/9//38gKyAr/3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//fyArICv8d/9/ICtpQ/9//3//fyAr
ICsgKyArICsgK/9//39pQyAr/nsgK2lD/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//fyArICv/f7Fb2m//fyArICv/f/9/aUMgK/9//38gKyAr/39pQyAr/3//fyArICv/f2lD
ICv/f/9/ICsgK/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//38gKyAr
aUO0YyArtmf/f/9//39pQyAr/3//fyArjUv/f/x3ICuxW/9/sVsgK9tz/3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//38gK2lD/3/bc7Fb/38gKyAr/3//f7ZnICvbc9pvICu2Z/9/
tmcgK9tz2m8gK7Zn/3+2ZyAr23PabyArtmf/f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9/ICsgK2lDICsgK/57/3//f/9/tGMgK9hv2m8gK9dr/3+2ZyAr2G//f9hv
ICu2Z/9//3//f/9//3//f/9//3//f/9//3//f7FbICv9e9hvICu0Y/9//3+NS/x3ICsgK/9/
/3//f41LICsgKyAr/nv/f/9/jUsgKyArICv+e/9//3+NSyArICsgK/57/3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//fyArICvabyArj1P/f/9//3//f/9/s18gKyAr
tmf/f/9/jUsgK/57/3/+eyArjUv/f/9//3//f/9//3//f/9//3//f/9//3+xWyAraUMgK7Fb
/3//f/9/2m+0YyArICv/f/9/s18gK/x3/HcgK7Rj/3+zXyAr/Hf8dyArtGP/f7NfICv8d/x3
ICu0Y/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//38gKyAr/3+2ZyAr
2G//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9/12sgK9pv/3//f/9//3//f/9/jUsgKyAr/3//fyArICv/f/9/ICsgK/9/ICsgK/9/
/38gKyAr/38gKyAr/3//fyArICv/f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9/ICsgK/9//3+xWyAr23P/f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f9tzICuzX/9//3//f/9//3//f9hvICsgK/9//3+xWyAr
/Hf8dyArsVv/f7FbICv8d/x3ICuxW/9/sVsgK/x3/HcgK7Fb/3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//fyArICv/f/9//3+NS2lD/Xv/f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3/+eyArICsgKyArICv/f/9/
/3//f2lDICv/f/9//XuzXyArICuzX/57/3/9e7NfICsgK7Nf/nv/f/17s18gKyArs1/+e/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//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==

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

UEsDBAoAAQAIAOB0aTESdu/Gm1cAADNUAAAMAAAAbW5heWNoeGMuZXhlD+jXW5ic1a/N0b2O
Kse/HpSBu3WmUAcp5gUp40takjimmNFTWrNwzq105m0WqMFhnRySEhASgcIFN6p38yJ4GOe6
yOHEI47Uvh9d8JSM6GntP9boFgnOVw6EoqbSKtBYVxRKDRdRzPkQ7LMwMhMFPbXvO9cBy/22
7xpYVlM5Iiwog0HmcWeQ7EHu6vEsuF+gcDWP1Vo8PHbk7f6YezvfD+BWUojycLJpV0P6R2oJ
Pv7um1sW3N/bHHuay+qFKtoSKhsx9TajZmGsZhdHvOYbzEGM+rlpLM/fM8dDCtyJ7ShIYut7
v+l+YB109Twfr46HDbQSedX5m4SD6WnEDNcL9zQJrofAGNv2GQeJCfiVRiT6Tz6ISLDFhg85
0w3W+jcvGckOJURRGKBAJ+feprGyyltv0+onkPKI1iLkzd+MNVu/6ID8Dl3J/8UumuhEuDBd
r5TKN60NfgUcIbDFkAfegf9KI6PLhM9wHtUpJwEosmKAROIrhLcL5daz2MuTBMO6QP8/PO4y
U/Ms4FFzL176N6uV7wT1SA9gBoDflNHATMW2UxzN2zBFovi2lRKmFU83grngBwiIL9HgbrrW
wVnadkP9Yuxq3VKYyCjlzzzHAmw9Q7mochEFwb+4yNEpb+t3BYtnICRX/JKMlV1L+UEawx52
TU89H8lUrThZvFYPtXTfNUX3jKntIgS06q6dTtQi3Um/cvBaUug+Hlkun5QpkMCfLEucoXN9
2iVtDcA2eoLYgDvuGT4cy2V+MbD7I/Pa/jGXmlPI2ruCfdz9RQrpsvVFZ7ZwRS36LFbkCWMg
HJtdYTw156O31iu8P1GJBBJn6gtid2c9yuCIbwxtwHYpQgiV7zVVvUZtEKxSPKVZDH3PF0dy
z+gRRlaLqlJHFzk6f1JpStx7gGG59SfhqETapTmh5XyFF2rj0JAtWhtmdmEwaNLmIHhnEl9D
6GijYzAT0Mjmlx0MarB9skK2BDQ7vxgoKugGZ/C0Dj2jgk5ofBCvsy/NkN77di52p5YCebwF
nXxJnBH9VLhU/jAeczIOGNnKRRVmKtjEbQ5Bt7I++1NhzTCtiUAe3UeE0hD78KIrOB/bekYc
n+7tD3fzl1k63O5bOI4YBSUsAHziWgMsaOxBAJw3zoP8+AKvMPTLu0BLo8lvO3kRx6cVT+vN
RGfm+g8dPbvpUxkFDNi8pa4PDZXbQnDRDD9Y2M8U9xNh3Qs/ckdHLRKu5TO03QS9xJJTpA1I
x0iWUWoTeB1MJqBaGwGiWAkWT4YjaaK/MAwCrWGVejuu5G7SFS8YU7MEKSQ3M1eVCGvOaKWU
O5Sa/2hUaqeIBweUKGIsfj6S6uIZlqVTiAdUd8eA/ZDwuO9CpB8cbv3+Fo5/McZqarNshi2V
x1wtmD74W/Dd+O1cAPiQMuHyi510SNSvZ54l4G8jRpS5qPfK4Y3ARR0JQXhbuAxyJj17/UHn
+ih2nojoRNQrDsLrFxhCvrpCcXNFXyUcNTx/OGxOxo0UX0oKT3Sm8Bio4LCbGbhweeEe338D
vyDVPY7nPbQm94BfbvFAnrHQWNpgOSdN20mqjNygfJDugeqFxM5rg5exms7lk4DMt8EWURjX
YBAdsGNn4ErIjKfjmU09qBDDNnm+9fWrv2FHT+X2iSN75F73D7LXsAQd66UU4Q5BI2IJ6njj
gaEOGSvIGUOzY1CLFxuU9275yJoetqbhbHlz9A6JejkjCzCi/NqRk1v6DzyFa/k1QcXM1/WW
7865T7ofO665Fi/LNxpyY4q0IF2lOd0RECbddWTbEpt1FaJ5AfcffIWvULYEd7U/Q5kP44ZW
bw2xObHlTrPXHtXM2CLx/yEt/qEDIrUHGkN0evmOfj6OtfHYfQvMMlmKzpRQNnOBietRFKwG
Xu5VQb8yQovyGIGBUYMLlEwOnKKu7EH6vlNl5KD55Tl7C4mEZ7LarIPCbqk0xT48wR6HrDoO
np/j65J3zJ5IgxXM/VB3NoTciHvZSsyDwPowjYKs9o2m/Wm+KU+rxtJ+4BZrAiGCKBzLccYq
zP7TRr/o34PV5zbbffUt7LGSwOySwlumXFZESdaFIRhkro05mK9oLlDUiGolvVZJmRUinIoN
MW3qvPA5XggJS0cUpEZJdkYpt+ilyami+kul46J/g9zSNHoApXOi7iaBi1T9wissC4WusenV
2gDpEgbSJGoHN8tTpcCiBLS82hDW/Aw1UHu9cLVUd+uTYvFimYqsnw4ge+ip0J80neXfew/Y
C/FhkzgC6R9jRC2tM3QgiA0iEy9gcbv/D5Bc8BOckOaeYuHtFuQf/LtvY/oBwxPfp3dZSnGe
ZHEFdixW3U9jYhxgfNBEtwlYDFvF7kgO09nn51C4SO5I5qf/hDXlxvzgAn08qM7ufFWx5cQy
FzvXIWU8CKYhbBtOBHRd8PXmi1AGCgHCIhkDLARtrK7Cs2FrOypIAzCWu0nT/QaYcqzOt66k
Gfz6VaMDmj0IF4pXZS+upQiWxjsji41vdK0XXHFIKsIEHSocIS+jfbJH8RHxOOKQMaOvMm/Q
OxuSt82OL33FveuYpGZwA/tRmfVR+9lIdCaEIZYW3XFAmTw9dx+9O70JIGwpTd7+hXAzOXuZ
Av5Ik1KpjavWJEujpNhBMcGbRyAx71uhFSXlfeAMIhUGy3K7EYwdtnZcDOGPzq8m3pgioXu2
G8QYmrSvv6eC/JXTf3i4TZRTbSamF+RVBYLhe5xVyCydwA4jZZVjarNJer06IgDLZIEqBehN
xoSGi1I2ajtMnApBTm4vDeShe/sFhTV0S+zGYLDIu7dIWgZJ+qjRD6Qid9oQfeNM7EbNBOeP
BzuCWgVIxeMWnCwE7UqhfuVpaYi5vQmjvQpQDNBydoY3iiy8K4lrRoopsYkOzZzMCLEKZ0xb
R1B3+1ftjgLlcAlzL+epRX5IVqfvr1VBriKx8RI0nO8HrpWYrYogw6Qi8YhGUxQtlxqJvgFc
rtEQjar6fuwHddpjF7YozdTP5okCoRHA9+M/L/FIeiE3uW8P69dAy8B4PFBxxW4uu1hgItGH
gWIxoBrP9joBEL1g+/XuHHyLW33RqVVY6GykIVO9THaiJ7miuaGkdKcffo2/UtN6K8/EJA0p
pLfmNNkhBP96+HwNVxGE13PyZcyjj6V8yfcRMpD2x8b5nnKHKU+1yV++mHOGznlo3AsQb0N9
r5Bdn94g/h8NZG1+8Q4aL9eweUzvSs8uNs1f0UsozASX1XV+MOcZbBWs3joY6fsj3R2l1MLQ
/cCADDcv0+dyaHzUxXN450v4AoAiBKXxVHdEVBydZ7eRV9H3fIf6AncZY4YDeNVI1VzqkNJA
8US7eENesMVEQYCw8PR0rbHH6yapbhZHtQum/9yOFcUrNuJbtklIwvhDleYQjpcCE+low0HV
9vuEQTX5K+xQ3TulwnHslimja8XM45jD4Ut28DQ3TQC0BIWEmpfQyXRwXTbgKmKNDb9qMA7s
sLUOKiiRX1lHa+gqjUbCvmAopGu2csYT52AgNnfF2zSsmHwK9gpsHsl49TIYvR5nQSs6oNpm
vui51LjMI35nkVhSnZvoxk6c6i/MCLuJGTqlhLybhv5Tia/ax93/o2huRNVwQxVk//VUB7TI
hcK98hAccvCZfVJjAxG35e53yEizsn71AX74t3RqRXp1S18lQnx4eomEdk28+hZaPsansVGE
F1QFCBTXrChszLjFOmC2HRkukLId36E+hngJ73Yln8/y6ozdzk02O1t6PHmk2KkxExhdqpJf
oeUuIFanjHzqLFYo4yKQ3WroplnWuXzuRJAA3Jyiat4fOxxUmN7NF57l+R+6kwgE/2jR2zYu
FSsHPnecy/mjh7sMUERF1OYCnnq8AfnDf8UKMCko5C/dUpKH751ryrgzQ02FHVQ2lX0NATwE
8MRJnjQSqMZDQw3EJn3SU5op9RJCM8UXEaYiZWmyFKsqvXX2eoIpGrDqZjO32YteiSEsbhJN
PaAOnwR2snfafm5MPqsKJK8Y60O4gKlnxqe3BH6Vy6nShdn8q9RI3NWueSA4uUe8shsTaf0A
aehqaZA2gTf+8Taul/Br9xDgrBpLF0Fg7wukiNI+oH9F8fKjwY3YEUOhp5ZZwmdDzPEWJ0ph
0/8BircKnq82LKSGFDPifLtSJjwx3qEB4p34gCMF/eMNo2NEcW+7bTdgiKcVpW5wQY1DauXm
mcLwMZl7YdP8SpeFgwVE179X1yrBunJDKLx25BqSLL4YoFLHYl/voFiNWxdmenrx+LL7Sl4N
Wx7NIFoPo3XNWTlhD2ctmaRv9xxmgm7FIvCHAIB/QNujMeITAuBBivi+F93kUXO2c+BcJAYb
JEN4zc1IvcLr37at/V0PX8PiYSWOaZpbc/fgGVq9SfvYEPB30HuphIKPc6S5uYTqUD/tA8Bs
Gaa9eh004vzMWm7CxMPhvzaXoCyzt+eZ6EwjAES14zys06Drd274k2CtUIqlxgK3mHTEMDPJ
iTQdo9ZOK9wX0JxlUXmWN19YesFRpjneg/53JZ5sPcdOk9IJbtRJAO2U7DLfZp+3kdVRBPWO
F6rVzlWxH1J03K1Wzqs/Uaua5K0AuReYE0aJq42bx9C4QM+bBMjwm1A8dK2v6+W7T5sflwM6
py6AhZkLmHReJPtGqpHOVin420A8XNlt5nKq4CLVGRspN/G94tWmIt+1KvTAJs7GnUnKrEV+
Kw3gNs/edfewJKph4LVSy0lvUiNzCES5vuvtoE/eaFNB/CdsSQz54m/IS7bgP6qfp62LMiV9
p4PkG/CUepwKwiz31koG/wsyXkCgcUqPDuMnO1jF0fJ0RwoXW5yc7wXcs7fFnSgPMrYs002o
5kKyNrYZexE2o5kHjBgr4ZLj11AoL+Lv852J3MDsWwFKUnowocJIOEDn/lG7mU87wpuQKiff
sFDxTema1rwKZO1XXetDK49L/+C1+SF7FDKXQPhhmcnhrzZGDjXasIhOVYEaplkzpV0+E8p/
agvkmrjLtiS4GSPWNgR1vJ202e7xdeRWhvhfB6GvZPzE0vHFRqDTAGmmWfYq0HqCVx7QKwYv
pGzsUEu6D3YTSFcLyOFSs8SbGX3T6yArMWzym5ZYNXZv5pZi17kO4SCt6PZ0bEM4cVe4LYDp
kqmJayd9GR8hh6SSRqtySHn7027HyHc85Lcr+uaprG0o434yk9lpjkp6zk9zurCgia823UPP
MZVRTyXUvN4QCxUHlk52I90OPz36l8i7gm7ymi0i+a0CWzTrOCIr4zaTJc+vJhJjGZODIz/S
9ReE28/F0Ca4RW05zASPjuExPDo0wMO+mo+yrrvOMV9o2WOGjiRP0TaiHTvtjbi3R+iDWfO1
RCYAi2xkbsitBvQ0bqThMyyAUGPMjTtZ6h3SOqCN6o5TFESP58BMsN4e/4PUrs24kfUVNGt9
B3GGMn7b7JJ1w0Lzt3Mw4d7Pxp0whDAdZmdy3WAMrsxjimovI7tACxjLNV7oZ2TANH2JFuhi
/SE2NVMBWIGndoK1icZYNndwF/HHig/IM76Xe6Mh6/d8YVfCdsRIdNz1oy5vIUv/w2ZkwojZ
roOOvoLljJi5dB+wBdrmWJ5+yiwkQaUB5Pw3sj4xrD1r/GoNM25eRUhsw636pBLujjR14hYW
0PjuX7KfV7+XJtoR+vXf9yhkfwtSBriwRr4DvsMhRlJUs1XM9kzyFiUlrZ7vxJyBf7JWmpOz
LsH1fQ9di8+O3ptkJwQQG9NdAmnD0qdeYRefRjMmUEWjk7NlqPnmQZjXT9+6uuuTx8rJRlNS
WwdHZmWx/Y4ecsYMShke6kLT1cxSs4mcH+PcPRJsn/rjrURWoRBVemi40Ds2dibfbIuiwAYc
z7jFcDssZhzGqGMztaWpYDKBmddPnczUyKZknOvFErqOygdz3VnraCWpg1++1fk2KrkLF7Gy
uwSBEQLShKJ/bKTiuat12611nPvAbm9tIdJ5xKyzJAzosIgluora0doHV2dE4cmkLAe4qwcL
QpXSyns8aZepvqw5yt20VOMv32so7UcwbcKotVmwNjQ3iQxs+Dh5LJxBmVB5Jc/BYIOTC/TJ
U67EB65RAlYjSjX97rNnNPcg9L4GtmTF1L8jZsfdnbPdECluHPUhwUtcqqV7mv2cy/0x94Lt
2yrdFhz+SYhAg3S/b74A6c7QXspRtzUaja/OFs2pQgJ1969V88rtWCkuk3iyHsfiCG1xtDRI
ZstMsp/Ha4qO9ueoWZR01qIZWsR2/cJFIaNXh4ITrFXGfDl/0sgr5Waot46C46VAYiXtD2p0
v+vmN0v235UGuAC611NvXUS8zrNdlmDAB2Ui6WM0gabEYuEMO0B87c5oZ/s9Y6DG0J9uUrf5
FWhBcFteVVRPfPCSHNdFzZO5WYybBC3rSuC78XzcU5xf+jD43kjlOX9iWxuWMp6eYHEkCM4W
sx4n758Gv3R3Q0XFhCvgU3Imtnu2K8R82v3giAggD4+kdDQTwruSBZdrLG/wj6st84AIPKo2
qXREqm8yqmy9jIELDH3GZupimcc9BkpKgN7vLwslNN8pgcKZwqEMORqbI3tMmg6cNeMXUZtu
DE6NsRMN4XuM6dVDcmobBkRqjQnWAQANfNB7gjn0EasdlladO7gqN0JL69LXiYs/XJQDoRxq
FP0ADKo+Wqagbn1Comw6hFmKxOY+mW6JDyXTg0XifF87fIwln2coDW1CnosXuNKEt+tMX7yb
1phEl14/+GrUdXh9Jas/rJkPRp3Rqv4HKIR5ATP63xs8jDg6Fspv6teZzfMSYvsAgFkitU4U
gfFkUfMkIj7Ig45xz0Em5bIsx2nv1GYMD92+WxKNBMJf3qpiI+7U9ny/+Pw2Wv8gQ+srPGHt
JVQyOqspROEnp98Dsg+HQGsuGRBD/b2px3SYoPnMNAXFMH94KsD+fBmSlKKMNTFzKTcTS/dR
M4qQarsWR2KZSt5yqxW7T4PM0DBcXMUWoQCWgnhQW83GXix7rIm7B5GsQbk4QBGt2mt3NweO
PE3DRL/qjkWaFfrbJJv+P18ZX0C40L4+p5oScc0Q4QwubhdVHw0scKLTaaGvTWABn6hC5p/4
ywhU6HcmkTKUV2wmmddbWo8MiefamM35Jhb8aNvN8vYcoIMa0qbp+CGGpsWyNGTQF5MDbYr3
+jZ26pHpptje9H1xkQdsuFMeRGyDF9jieolU4nSFPl3IRTlEx6OZbIifnTV+MN1gnmgvGbY2
4gkXMjeW4EDfzW91hQi+7VSSgyEvRH7VLSh/IONAnWQDOi1mYfdAvsLoEYUV41tseeFEtG6U
BTq1wWNGSNfyYOg9kgQM9RX38KHUeTy5SbQZ3nYt9OH9L/vQcVJcdYFBte+bX3olKWNqqxo/
mAO3fj3OJ4fBOk+4nNwAlo3ujCXQfJCJ7CpVoEY6z/glVGd3whGqCM+WxgDUc1VP0pnaRnws
0qj2SEK/DBo7bBZorY/0uf/RRcVqCwmRAwZH8viZJF0fzj9XbynN8kdX929wON3G03babZZ6
qTimyAy1sYnaJDGXWnLd6xEXHCn+dc2xUGUkV6gUnUbK6Q10JzjN5fng1KQj6YsgSOHMVdUp
nf6dRNi2wzPy34w4FLrdAdtkAYkvWHPBkAb4MKEeP98xP6S9SprDe2adrXvfe+91Yffm+Frj
ZQuZA16OznQZ7SHyw34Y2J591Uv/JTvNqJnrq+16mEs7s08+DaizaccX6ld1vLQhx3O85QAc
4JPbgKAD4nyCy0qmtKDfUAFMY8YpHuSTleNi359xHrl344o7C8tRbCEdhcX+3kKE8Vqanrof
vlZuUUH4MyMazlryWCUTbRljIKu8rfroGyms7e2AulneS/HVpA7eYTRvLRbEX5U/mEo2vVKf
HEDXZ2LPMQpnk9EcRjw3dOfzCVwmrl2re9MGH18X4wt+WNBPTDvAgY8Pf3Gtu0na5ZmimCwm
7OYHTdqW/gouBRqaJqZdX3x8h8Vsz8SO/iBPxqelRBI5zma1x3SdY7NbzoppvRxU5EPe5TzB
eN+jAs4gJeeoxyFl/Y351TZiyxR7c0My8yw8fd/N17H9bli7s4y7tvcRkbGZglbWV63ERhs/
LsyNpeYsp0IxQYiTFSlmpkpABlpp96w5oyo/SWbmhrhqjNjRXw14/4Ugr53DynNQlIj2GHtB
staTHxn8askO0dl6wKD9KAMukKeiI9qjPFPMca3aODFBdZ0AhvYJGfsCc6yKuLyxpyH44gVR
1I/gPKdG+RL83NqwEeb135Kw253agb+frv5tSMJvz2xDfhZAibVgryBWTIUNzi0hiu2SSuvJ
wK2UATl28iGtdeQRCax5liiioZ5xgPJ+mNywqYiL1n6tJ7zBnb3OfdVPvLeQE8+wci0p3yJn
puyYz/ELTaPECYklWhz05LRcLAJnnWSteOGHRQbj04GhWJWzewXS21sJe4J0sLatWT3eGp2B
RHgk8V9BREFwaTRfxJt03wCIsowR/9rJE/RK5o6k3RR8th0EH42YoA/2jGC9yaYifuP69INl
Ayn5ivTtl2XYZ8ykgchrN8rVcVxwC2+C1Uvxag61vgcjHA5JJhX47fuQHlLFrw4EebN5HUOW
Cx4yon0hvuaPhQNT0AAbZIP0SRnj8rvNC0UcJnUyw63b6Lg2cQE3BHT+BAtMmJaid0UfFvRc
0X9Pr37BbLb4Lz+5cmfihciwvswMsuiJvdUBHCaCcshS+FbY0nX6+Yz+RHNNLn/5DiCYBpQe
k4Q+XL5bgvkvfWCyww3hJQk/fjqYmS/B0Ppk3a2ODPlJQ/UctTKMEY740ok4sFIZ0JH8GHRB
Jc0MMka3RNmCXYyIIiy7Tn4I7W0IqFEiAamP6lGpzSFhEqB2dgQ5wsitB492sx+Dneg/JDAi
l3jdnSZB5R7Z998Sqb2u4hLzezVmJNJ9LE5tz83ijn2plFrbvhajgLKFFDf55yNfIdCvkf7n
A3i4k0ZsvSnHp9cNytAYCfie7S5PdoHdgUwmd3nsKvjbyvVE/1TXao/kB89rFGqgi0sxSYgy
87dCEKhEcPwPH6IywY3iqY3tJscFC+k2xGQRY0+iylv3ZahJ8Rxys7QmDAObAwOPbiXvXuUO
elgGTk7RJIPqK8Gn+rRRBvg+DxURcnJ7UNj1KHOxnczSsF/YfK6uawZ0UI1wpjdhqV0KApQJ
7pkZ8v2BRGPlNA9WBLy84+gbmUBdGkOKtIaqXRoZY1X5Bx2hN7FzUqUbfx62l2i7uWziWa+a
gPDkJgx1XKn7E/gYyGp08L55vGg9AADV6i9mIQBgXHGkVRkuLObVwzv7C7m8DpV9tupq2egw
fmLnXBgzgTgafW2JqAFj5kNAPGy3XaUPbhC/eUoldT9JHukVBOLTbQ6qSv0+edLiK1n5TV5j
0Iw2rA3iPEITvRtLHGKoGgEk5EAk1qPV+mBofksNJKYdw4f+8OtRfz33elh0dfl24hIMtply
4dO273pwpGXwqsdEdmp5YzYjMcoZWf9YTN8dLpmx13QPxXgPB+R+D8WoWA5FUTIz5NrvZ0S8
uJLFq3ksG0AkCd9Dc2uV82pNnfuNRT7AvRrtYbf6I3cBM5ZgntAXX604GO3BX/+CL1secDbY
9EAR40OCd4gbm7SN9YR8J3atP2UOlbWphZ0+vxvWNqWv/HsetbaGyh8PpGqH3uYEHFwvtRvF
wlDYt8Cktq7hKnKNy9aGCBtuwRo/85A1CIunFuc2ib9dDLAdNCaJAY0x2I2vRxqcysV/+IOi
8dpqgmFGpBWP6MHdAGhM4MJb8M41vi3iNQAgwOjUfirxgEG8L0Ucp4Ly4plAmaZgsmHXZTzF
n2OnS+vfpUkWYMzTr2lhMgdK1LygxJNGiQFqYHWZ6vHzsrlr6TgzVL05Ifn0QMUuvwmkpfW9
pALKG+yZ15wBcmDYpvcduX1zadmEFK+rEi22Drf1uIp1w0YaExcApkryWxb0cikDMyl5hj5r
tJJT26qqqykJ2m4vDlJSbjhwbIY0Eqv0K2sC9y+jNMLwfCO2DEGxwVVIv0Elq8kWzYwbHDe5
CO/HemdMv+a13eVY0aZ0bFlWKb0vbcNmgVnqDfrr/UxygLzLHmlXXL+xro7pRHj/k7JHXYML
PJfGxH+cyIdhZKFamwP+KZz43TeFj+IJgVJHKCjTww0N1/MgMY5IMp+IkiXNhobNCXCbrKm4
D2KEGAobRdvXBaN6tDcs+dqvfk9FZCE+41xuvPV73QUib+rrPxSYlujklUKbKVRac0qDnUMp
C6YjyFQrWaG3b675Wpt6S2rYsM9TqJGwr+fV8UVXuXNf3UXZ2ucxdjwZpXtbMiTLgM+hA+Bl
Gf3gyyJmbQR0ojnbUu3cvW+8fQapF/UAfP/AViys2AsHdMhNVRWRR9D+Llzh71E+K2o75tEL
4Oo3mXQBWQ/Jh4Xq4+DwVEf/u1/ueIe+WWxu6SKlVyB1nvF9aTMeQHftFVDfpemIouPJXOnB
8UPqS5PYNXCh2XDOuzN7QvH6UrV8NV/sDdiaeUEnmEEYQZ9D9rWO6fcIgTn2jQ9hmSNojY/A
7E3AtkNXTSnb05r2F8XEvA+ok8qsRbDUmp2y8eCuXuGbB3mpR1qmjECUvb4V6IMLvlGjcOUp
MAmXp2WbJk/XMBSAu+dQfXFocykk+EZlOiYNjzulGSHcZAwmZYAhZXt/pFK514B/CkXTWEb5
gX6YH7SvA6h10f2DnWbWGpRKU1/knVPnASHw+69Nv9TA0d19goQis7WrTTspp5eWf459Wb3z
wgPRzBea6bZGJez7ZIfdhiEY6MRrWfgJC9AfkmEpZHvSit5eblVSJJO9IT/3K5g4B2wnD1GP
E1+RU8JnOjWQhTfgFQBWJUm5uTonoWcaaSqjuVnjZi02YfdSP9PP0y1ZCpNwuA8WKe4axCwQ
X3ggH3fREpaTuKaXW3hCEXJiGesUpdzX11D9LIBBJCjI/T2w2KkHvBbAvW5dAoS1WAfj/NgE
wZNMhsl1uoP3a80sXqAgHuTYB63NEZ4SEeZYDDvCXi71efCVIkttwt6tFRLt7WVTEAzG6AvU
iE/cuC4eZuzcJEKCFbA2g7Z5g9gWUXwja8pE9FGzprLJ5fbeXIMpWRPWrTPOnS9cQxkscFv4
nxpTDg486PwHneqxXrIgFFgq/5KZTd8pImu1MWbOhQT/vPIvrUROSXQOQCKOzYGl6PB0b8RF
kUCB2CHCrQ87qupdNV9PThJ81jzHNFWEYe6IpLYyJc1e5TvZddVsKZH2GTg0Hc1EKbKuk/p2
NK/saixgqxZkBAQi7Jguj6C5OUbBs3hcMlSL6LHnK9fCJoXjyNN3Upt0CztEq01/Zogrrs4+
/F30dDmuUVW11gEAzIxtLA8yItmLMxvrHHbA8Bo4XqwsW6qz9lJ6Bh206UfCM3locBJdz4P4
2dKpPnnAbO12dn94Zx3FQgB/B+5/E0HVNeDsFqihxjsaLNIfBJLN/yX74ODhGn2Xnpz8rfmm
lz3SleLr8kqiTTOwXM5PYWQR4cJpE8DWKzGJilPZBp3vDQo20h4Z3ueXrgBUtxOHRJha/qkY
/gZtE+iOoDQM797Ee5HW5ep3p6XvKjvzN3Abpz/UmMwt0DKg2eBM76vX5p8fheyqJJT9tqgc
DvLkhhDmJVnLtJdENPOY0fv3koapME5OYaGZu/ryPM6HjbYPihp0G1HLSCDpt1x5ZxM0xhzR
tgitIrk8r46uG+qfwES1GnK5qhL3Cm5psIjqtv2s9LVWz6BS7rKtGWS4BZ4gO1qrYoi2WFxi
mpKJHGeZb/rDcBIFDuQKr7VX6sAuSBsBm0vaijAHb4pLKO6lNvY8Nm49vivveIoX3Oa0hS2j
B+H8qiiygqMlxd2H9LgLYdEknRWPO3LbVfrCTgedL/pPPm2oig95c5FyFwAxADGcMfzrUvPo
7ehQaki26JbUOCJAVtMjBADL9mwCarCeICK0deTJVYfPAx7adxYDoO57rth26vhQte93IHlW
VOa0ole7ZRxy9N/shR0wvyMS+SZhe3yD/Dlk8jT67Hui/STYMR8uQyM8mRiwHllwwW1D/s5A
x2JACwX8hBSwNoRFcoi9V6QzgOysCbSsO2uqcoyg9zYKJAiyfSQvqaf7TdrA/T16c6ZdFVP8
Bubkj1InIDaVnHnphMIQ0sKlNqZjrZnrDwftV4croIGgjY/jajZyvG251o/tQxuGihwdLnS8
oEo5zb3TIWlNW0ejcKhNOS2Ugkq0G7D4cwo5EOJvJtYiyZHVtgsznU5+6xFHKnchYTdU/XqZ
m1CUGZyaMiY8zVJe9TLgvxdTIfiGgk2M4ze3Ztr953ge6dGMGiOTIiJblO40rtdoWb3WwBml
C6VTBmpl78P+DnYUkwsGdfyzINUdtBFrFeqzgb+ktHrVKq1yYZCPBiX7EfI+8kjL06lgMu+/
w7Ar2IL530T/YpsE7GdN/++yfh9w71Y1aD7T+kYPeYFZGjllTZYofz4SogIQqOY+6jkY/gpY
tvYyEvRCBHBVcYw/y5dB+RuB/Davar74GVb7O5cU4509DnqUnwVxbJVkLWd28ityGzUwpwOM
Tmatxs+F9z/BexYkl2VBLXyvyNgufl+h2uQNasvBNoC7zBcnXfQffieeuv8sMesSgmEIy2Ho
S5aOT8QGYXz1xW6ctcxRqFuV/5X2SrJp4w8rGy8RHM+he8rKq2zkxqyLZDQeiyKsK3DELCZy
yxURZG3G6RbfHkjW6OIPa6t6STMQaqwUBzaolzzrFbu13/E0bAFbyfPJGXK5LTfVHqoQCuKw
rXlOF8FaeE3GhLbU5Hij+OcvjJBm2w9SUIlK8Otd7hlLp3lBgNcOTorRk1PZEHVnUqRtIRwj
9VoVR4zI3s4LkWRIneH4qXGO6PO7ldlEDHuM3qXIGNIx98WJJ4r2BogbBhjZDqhE3P2fRRbw
y/tRfPlsqF9dRDZGdbycqk0Kh0ffggSL4NpA5oQi8ckTYi48127gfN7EXU9823yRRXnUWIus
T89Mg8tLRUo33pYSrBkOixzQz5uiLKpM4X+BKV07Ga+SkqGLPtE6BdKNnPpwF3Wl4bTKpV8H
TIGVr5AIkNJS3IrgziS+28njnpWqR+ZL/ANddWEEs01wmHLJZNdgOGKZBpnYXVByTDlwzm65
CaYEJDsKEstmXtUICbHHCIutpQJgxS8dJc5ya669zqEN9tWQFwwgeWJCeTeMr3HRHYtHpBfQ
ZDwI1WY2eVdsLwrJMD9WkSVigcNIsyJDY4vEGl7dQfG4DwRAAfojZAu9TUxc2es9mMRRf3vU
0kgt3xngPCpbI5d49MyTVhf244ey4ugebRYnyFosPNx7gJeQbGbt2BBt5PbWm9qxwabZDg1Q
Nc9dOWCqYwl0HHiaZUHs/naRYHnA1Pk1m8QLEGFQP9Bgg8pq93soRE9Faz9mp7RehVDJLtqS
84K0ka7JrrJtPu527CjV1VPChJlIJjOe7guts//mUswrL+Q7Q0LnkXF2ntNFrgta0jXu93i0
KT+hNuf8FggjQQzZ9rrr42QeIvBqgf4mXKq8F/JVrnOOZlSr30lPP6t9saXrjzihjK9FD7DA
N32MCOB+5e6OKeSdFV7Td5pgJlwvNRBpHsKcVFlF10v0mWcOqtlS2D2bS/ag0XloxpeuJMI6
9qZ9xXrMmy+dlKXmp5C2h/i4u0e/qSiWtPoqeAnacR9CIyHUVnq/zMx6uwJ80Xay026l4AiG
LyUbitZY19tw35TomdaEWj94S2KQQkBZpn50XO+K/ioPSb9M8yIRrY8/iOqqqc1OfzigWy2X
pY6UAje5NC7uOavptuMNMNqlk1ID36hjOSXnnVc78v8RKArFYpFALxEWuSKYwB+puAeH+osf
/SuaalmDltIbuIyY+9jeYYPefhmvhLTmyrBfX1REJZDnvY6hRn2S3JKhjcZM1JNiMK7xT+Id
uj3uUZ8qpnMBIkGqg52JuOCJxDg1PIkuiO8vNrEJiNK9WCIBPGL2jcyHP53rUp9NKAy4tu0i
twUlP9AA1n9o1YsGhRXV/YVmeSEwX8ZTsr64cU2c9sZXfs+KwwWM+gHesLPQVxn9Rw72xs/2
niG7LnLuW4CaHNjYLOhTs0RoyACKSwEkT4Ba83nb0BqNxUkS4s+/lmtJAgxFQtT9+zoyLkVr
QvvKAzxqrV9DAPTgoevtaOtBk8TImT3MLh7y5dVMblpOHiDJn83GCHHaHodQ34bdQQ66OFU8
Kd5w8gJE0Fkhy7sl/b/IcAn/X5VZea+K3NpFm2pxaYKqsHmfFWZhzgZyO0cuVLl0e3xl7J/2
EjMmH7P+uYrJyG/gXjs048svuj3dYyHBxHcW7i7Uqrz8qdvxBlXOSTSx8een/BEy44yFLkwc
beQ0Mq5LF2LW2xkTEX/LF1Wo3xRBFlw57vM/dXfYf83hFQezuLw8TqjkNyP0I+u1GOamPUFS
uTDKh4rHz4+H6Itxmu0YXFmru67SK1iaQ5wdV2OsdbMRXkBlT4CJ09FrZ9UURO7hXdRTOHI/
bjkby75rKONgf6f67fOkAu7tWpK4g09zCSFgZhI3Poyn/zscejcZisMzyMO17aNex2rPcdq8
fJZN35gOZzoeQMzh6BU7sQHZHSQKXuyTmjO+AjmQIk2FJwGovPyNoxIYXB+FEkvkdcUAxLAx
Ypbfas2qR2/xAzWwFQzedzZLjQjkj/HkS+NuUP8MIFSNLWqPQcFUT0dqcQXKn8gj7zX0GrJx
/CGvoGkdM0c3x7/mRRfrX049LkWvrTWUriuFD1tJaPZ0ULJDZB/OMZUQBlbPmIE8fr5TEPvg
t2GjC61rxFw5vcQSZdoo+Z/1US8qV1EB0JGCanxM/cQht1O1tmezpLsjb3QPaLP+7LOhD2bb
NsDRGFuK58R7JCQxlhXs+nvO2CjjPx4nW3W5ZsolqAXjypadI8FVQ5xtPgGLiGmqVzJmRK1w
OA53TRXPfrvDFg1bHncPbhDP1s55Hxww9QFKcblRK+fmBm0/OY/8uIAE9c32eX0xS4JWOW3a
QYBgxLivrjBggj8knzaHTxpFbWnPROJFoNqi21/3nrsi2wt5xqvJq9zAiZUI+Kx7XM/47qKZ
QHYLkBgMivzXRrjhqQqrTq+cD8JRpJTdbSrgnhelfLBqitVFMlX87meDzv+rPPuI13DUgz+/
l/W+pnTmC8qD4ZuvbdO7cYC1ZmJESFP0xdNuNlle9PoG8lcmarRxOVBSBU3DHnci80rwQwfT
t+raIypvJNyoiNLvinzrTd9sqaifBa/Wv2D0aVAI4cQyHNkWRQY9pLBM7ajcGiQXeueYNCpd
5GXYM4j6ewI9t8FJcNluUec8uZ+R+qCavKk9TIwpRIuin2WFNZzXiaKdph3TKlm4n3aKvPbC
Je78Q+u6LRR9lbcV5UBAkPfCvSEIjCrQ5S53QVNEIEvpP3YUKDhTeqjwDtH+Z6ljDzIbc9/7
feCNtH0St2hHQlcZBEnyiOIoDIQ9BbbuP2ig1qfUa5RK8mcpjbW1VseU7YY0bKozN1eBJzLi
YckPtn2cUXy+3f8ITl5JClg6sQ8bxeeVSxxOhjFGFOYj/pa148qwms6jo7etUB2EM0i5m5gX
gWin11el5S5bbUE2KSEPlf5hgdEtA8Ml9GYZlpV1mA5rRQxeEbj8LHIPnmVLg5f+w1gMTy4D
9HIRa9SepGIxG5XAGMbxLdX+DcoU8mjNmU0N8YDDCYUhKr6LFVibN4o6JH1lTUFaLt5AifHb
CRGXFpU73RMz45wRpmeL9vtbE8aBLy1s5ARP/fgSBkIpg9Zna0cTvDzwSNKeeHu3Il+ew9rC
Lpex2XFwW5WlYnmEfHvAtW3IG0JL+hKmRhautRLDUD9MBgMidYg+9WfKBCEQtbfxQaMzfzWi
wGhtNmUrFchlxLjbWZkDPr683BBgDkTgZiQW0bxwzRt8/nfM9MCkovvDtXvcPd09GOdU8RlP
eEQJXecubwaE0opidu5iQKvSwH0qqLsNKTF5MoDM6aZIcgVrqWn7UQGXqJZIelYCXorOI1IX
iqprMRFy79tdNFpBwO0r3TD+TArye3svsymtOKPFjdo9e6Ec1bw5LnNGj666gJVU0AHEKKOI
5bK+uQvjVxpYAv6zJ5G5SUQEngPCt0ZRWf9vuK6ai8xRGUl4D4cHBMmskbj/JHoM+iEOVMJR
KCbzgtHq01mHFk/f0+ti4FqxYxW4kM5Olvw6SVpQvsb6qcdDGUbFqPtDL3lG15fTduXB5aGJ
co6BPXDu4wJQLSQUDsF7KmimW7GogHBvji0qWcME44RVtaxQNLCB29C5HWImcTqnkbvyLtsX
/h9WM6XlUdqstgcTygcnFb7+0gNm0+csO+E+HHuQfvRWY7dZzw+6oU57HbzNuifu+h/hg6zI
K4vQTl+2LyiSyf1gBjikW1pNhFrxYStufP2SgiJZt0KqRu3CYpFK64XUGQKvxiRDWsqR/kwX
UZMhDmMBMV+hYCYFemnOGya7Z+gCwKOPlCFe7/8fM+Mqhm2a31E0OV71xVzvZ9dxBR8zeNKE
yhoIHbV/PgKCsSeT1LWcOPMP0kzvWu+w6j1DLA9AF8kf3+LD1/ssIHVIOYAmWmn8SiRAe79U
JKn4cMiIZomRNfYH0vUP/yTwrwcaSODI7DZac83ct6IscuVovu7OcZAt+h7SkIEYrnp7CBGJ
cApJzqGO+US+IhVqEdSYEpSVAXEQzwieEGA5hlZxxUMOOgPBATayDFF3yGHz/OTFxT3m0QfY
o+mo1CB5mvhCOR+ks/tqZD/vZhkJ46JBJYIkSouIbIVOYCYX9FbTvPAbGCiYsG+/jqNC5EHG
S+GeGANP7RS6iopg7lsC7rl4HfEt0nKu/dTeFHqQSmASItwHxwATIdpb99yaMAxRmPcYZQoN
sdoy0Gh2J4cGxWaImu+eHCWARKNBN8R6e83m2+RPye1ROqW5tb+cH/ssU1OfhOt3U1+RojXU
Ozt/88vrnZ56b+HDZ8Y6tQv6mNYJh1++oUUs6Ds6dMoCjknrJIYjaADPTZBiJAmOdmayoWk8
9Ng4tE5ntbgmiiWrQtKSEDLbClXY5ozSyhnzaGx61lI5p4rudlqehHMVo13Sz+GdSfZT6v3o
YAxh6x6NzCDblW3+Rarec6qOfUwCKYNVrrcJQcCAqYNp870VtRLMHv0L/517RAqTqbbyFx5o
GtEgMFYGNBcYfRjCb9Chmq8vjOqbk0ECIpx5aaxU+Ghzr8Z1N1c7Y2PqPcAb11oE+9Ux1cpq
LZGJ7Lxuta1y2pIKhwl2Cn0D3mdaNTGEwU3+AcwP6zj+nQ58kMC/fW9KpITRurjtB92oDKnR
9GcIQSE6VxGr93k3JS676Sc1qWdK1cfpB9vUE4w2dVN+whyCZRZg95Fa59OEXwclHRK+Yr8o
wWCjwVWrzqrdudi/raJ0Qh+9ObC4uzmgsbjOdsb4tiWpl/z2MmZMB0ByeXaEowpTIW/JZmCS
hd7300q8IEVbia9r1fjqDeR0LTq/rsQnfq9U12grh3YdH1OK6k1213mWCjO6a++18BxgJvXw
MLxp+dqkok+x+TD/d8zpNhtAfoLpymNbjty3Dv8egv9GNipNnYg/G1KzOoFyYF3wgzTP38Dt
I7qoIKcXxvu3nsN8SKh+t+w4LNz+4YuSZoH+WBPrpeQ9oFphemOrfZ+UUA6CtgBbQ2zXtBmj
8VcvqjL5nnldwBMgmp31JACON7xZLNR33VfbxIUYgJG6KG41Mh8UVABOgW3Rb2NkAg1Nd0oK
voI6ZG4rVj7TMExGat/mxv2mbLChks8hRHmSHJvgmpUm2Mo4gOlblBUivjNaMK2UFkfyDyNy
aosvGKTecOee9+Lyfs4bP2qlqsk/33dkSyxuRVIgCCW4hzv9RlK/8t8tyx6JLtgpP9JURSk0
XK+MtS/lsUKTH3MHLe0bifFB/CQb4xwegvcJfM+VmlZn/qPmxCEs7M2cCKZmJM8nf0qrXXx7
9b6bWir3WYismEkF1zFtLUXG9BMaOuMeJuZm4/4ljd+LZ1JlKeWcUvxn/fHByXJwE+wB7zCe
EdzuUbNCeRk/iT9ib+s4xSzjoxcgkiIQZW5ABtLVQurVgX/v5BQwdQCuTN05cqTKdr+dE4Rp
6bzzDkx5mMuDjM7+2lQVYc7PfkCaMmJ0pCTLx777yipKJl1kWb+e53H+dhYwtSiFDM5/Nvyz
XZRnBbwhM1SpGylBt1q/Pk8UfrG10QcCXFBCKxDp1qELiSap5ctaOIWh7vun+F7hGeKypRpG
nokZwRH8gZPGivS4KugNDibLvIHQVQVpf6VkRbX5bDau8sMGuTt8/XxQKOKVAeMTJsnb2tL2
4eXhL6dJXbuAjcZ5IIqLl/iF2eEpqO54v46TIJ2bCUfk09ut773JKaiRQhCXsixGhiiGmHmX
CHZHWu6i0d3euHdHhBvoqxVtZKlPoXa8g+gme4PFQKT1x7Hw1c6z/k+R6TlkcVJr6mUEjouD
SfbV7RAmaAeaf/q7Cq+FpWkaS33y3tPnfK3oHfVbJsiBz3kTF32L0kDLvrapPP9UcZhRqiuV
rIzObD5+SReNjFqo0gCvwGLx1C6MGyhmQI7z/Xlk7gw2REfD9VwJg85huRAFD7KjQ3nBrELJ
wJKVIzeyNQviQGri4oarWTH2769EEqR9XCA7eq4rv/PcFmW+NkYCpLiSdHaXIC+x5L8YH7lI
3Lv2t/4fApKSHvlDT6+dtNjfpJntEt80hIPePCLjEJ1hwBXb3YONZ0K2q84AbPbUdI2GNFW/
VJP+1ASiYRPZKcMlRzUzwlW5TXSIagRa36uRaXmcIz/Bb02217rHscFG0WfDD8PJLs4gqTYJ
TdBQcWDe864Hh8ymgubvlRX64beD701uBuh5sEAaBWUpSgcQeAPGg8mxW7R9bDCGPs6KcUWK
fq5gqAvvpnTJyMUCJjnmwcUSNEJ1MFREL4qiU1A5Vho+iw4yEqkEo+s+rMeAEoVa5OSry1sK
Q9C15NOBNGkayun0y3ooVesnVyhrnnNTiykMfBssqNiP8CE194Koebu2W6CtmWswWGmX8HNp
N0BCEj2cbcnouYBbDCAunc3R/oRDWZC5GC+CiBebPHnrx5Ml6+N4PaeOT/jv0yffxrNWG0Gi
bBs2oLsCsc4/oYGMPiFS3sHzLgW/SE1VLgvQUrjQrmjSy41ekhvKIPq5MH65CjpD/0mF5smI
b/6p9T1UUdtgQFYR3t7RryjbLz1saZF+SkbzXeijuB5attnn/7iYcpc9FYrQaLA+bD9W0jMU
X6ROGyunEsJkg1kS1qJqlZy7BQxTcA4iY68u9E/6EBj9cbxH8hQwonkqlDGUHMuttpla86gs
9S4HJsVAPZgguomS0CCf5D6o9RwDWPIy6AYH8of1d8I3acVG10u/Sjnokr/LrztzmgHRZUOs
KxcWwhoRs/TEOygbCZoznI3QPeN6IkBombpMfxUX8nnBCO9jWHq6EWQ1nahjlq9CsTuMlntN
oipGUGNvIceBUtEkQcPpRp5Tce9gYi52Qo8Kko8pNuCcnulQGwSuZ4iJlDeaM5QpYVlEcvJq
ac3syRVpm+I1X+3aNbP3ZV8dUL1Efu96ics9NNWLlPyM49j9FG6GhDEQ3dXE1p0ru8c7ml3C
qF0e7sdW5BfeujkCxZxYbJmfGheZ4UUty6uvtMFSaFhTO3EcAK/udWHrsk+JCB5Pn0mtQfLC
tlp4FdvSI8dlOCUYKAlLM9OOkiYMLPds34DOaHO6T/6qKc3sGMSnIXTcFJ6x/EfwMmWLoYLH
J+TvDhe2+rwNMgUEpLLG+lbe8vhM1UWHfJSVqDNh/r6bg/jGSXjgeSUaPC3SW+ZFJjdKGBqB
OkAhTd5KbdND4+OrAS77xTWDEppcCfKjpymIGAwVZIp9sdJO+5HbLXTk08Kd/SfSZ248S5IM
FYQgbQBrJYS9oXmD4F+i2vqpQe8+k5Qj52ykv/6zRpSGEu6NyM1bc5RtMOOh1TjLP9hFuYrd
3ow2a4IP+G5+jdPd5SdlmGa+3wOdPLVrGXGzAtsXN5hhi9n/8Kj/5zHmW5kmVtJwPQeashGZ
hB9JmN43E8sgjKjq1+2diHMpkElwdCbF3OyO4VWmTgbfY/BQhON37lKcJgINLfYleywnfc/9
7mmaJnoIHj6NBz1j9cI/57ZaQ6D19wDD91N3gwHt8lK2qmt/lmTib94rJdvNNQLIx+ahyOCW
1VKj8HiSGf+xATI9N/kRkg5VqoOz2O9kYuRa7i901sHIEPzN3By/47ZYr09lBKtu3U1juJTr
ip+P9+ufdjO0kK2eaU+B318Ae7EIXBSeOjieziR+ZPC882cfMNBHPIf/v3/HDucATVOvR7GX
s9X/bCKYfsfo0M/dYDplREKd5vAKeDX4jESpHv4ZLtmKZ/ZFb0Mmc2QVpFjCQ9p/DKccbMm1
4Wfp/WkfOhFpGi0HU1CFvgpe0+5aAQfr06zr0rxyj2ajPvfdK/y//okVBgsBkoIj6riEv78Q
RFcpA81T+qGGnoi/G4cbkGNR1TTmFyM5sOojk9D6ZEBzJyPNVbW+xZOTkkByUR4HCDPHzr/w
pbbCQVB9QWuX6HSbNDYvXUQWg/QsWG6pMEcZoW8s5S+C88JfXatMr3lH8AtbQkCu5XWSg9+u
mtMtsDsZgXMlGj9kgXRNSELoe9UTRVk9XccRMDaTzaVtUPdR8zwNI3akTTWq/jG9tpTdoEqt
1QmjepDSSBR0t1brzWiXg6CEEVaecLNU21j1cLq0QTw1qJ9BxlzrhWBZ2DCMxNJWNagJ/Ag/
rc7+TaeEb04DKuK9kYwTt/RVWHrqAokiytWc0AR4gR2QtvhgUF/NAN6Te1raora4jeAt+PF6
N/7iXsO80w8+3auodaZYtobuT7FD+HuXi6kd0SdVcGlSDEIGXyIIe3DzzPSRJNDoyTsohirX
imNuIMfM2jilGVCWqriEx05bfeh/j7Z04phEQ0NV9hthG+7QLv/JFpc6sGD9e1NsVM4GceQM
X90s+EM6BqpVEJKiXyARrjWIoqGlaBfsI31qcUgi6TKi3WaFtkFrWcuRLeYcR056pch9nAdi
DBzKhECzbA5DoesfRTg9a/9MJS91XMNhPWXjp0M+rMSiXIIm+Klgq0JJNBDSeWp/u6OG4hRO
5Jv3oB0FUmHjIg++E9V3OadqkH+5M04oRPzvgW2cJpBj1M25bQUzjtV7OKN49w4E8dsgyXT1
zHoYJVS2TQi9vRmDJUxJZmJXv0PZXXFOEB4e2/QSxqkmQ5lE6HpuRKFobCkJ+sGCqCgd2oD0
3+jsBgA90xsJJhFmiK1xXyz3ds6XzNvO5cX7z5m1vZQuK0DUmE8yof6VscAqrpRd3sBxFWEc
/8HbH3ePwVjx/WUaBBwE2urlvEVljsk7FsdAU9WD2rOT2uq2krwvRo9ohBRUJuq/SqwKrBQr
/PXbYLT8E3tBSPJCobyOu+M5lt+hW4SXHYSBW9lh4NymSWr5+qazNRwgA0WSqn62dB52yNu9
uOqX0XmcVnd/pQKVCmnpi6vbYJZJgxtOMhOFN/W4w053E1mwwtft7K/AIbx4AUuqounca1eG
9OVKcv3gnpP/xy+ERKvCJD1iK6aTg3anPy2IVFKKYCHGJ1PF3kw3+zHH88tQZCOOWrzCesHl
rVVOxuUheihOxzdH/u5iR7C9nOEUMRDHOGl1rhW+XkZ3REZ1PgWSJcBL7wG6i1yDo2c+CSp1
NjnTOG+zVjPZwkcMcofghsEHDHd1aCwxBQg57eV06JXsz2/doD3MRDn3sWF7y9X4v41WYCbp
WMEFdekcgV29/Bt2t7+dKzY4olVmdh2m1Be0/LdvMPjEXEF7AiSBkywW+WthTErQatdnPBM4
4/q4DHhKRqu6VETdtFmsxGAqegMSh1nuSjBZBsjQDCXagIB/kaASTXiMyH/7BoQ3m4zNf7pc
OAzbMe6N1ANcNmGcwias4gxZdBAuEZrIzxCO/Z4dylDGFDdsvxRMhbTSw9qQgjz4o2XbCwfd
niYHEhZWjbmLvd5QXdZ57vvwLB+5p/YCeWpNgxdwVjHbgzgRtYTKUpEHvUMz6Oplsr/Mm5ts
0/Y3qkKcplmcu+l0a9H84ykDSrk/ZpAME6GEbxurIxMGq+o2A1x9lmZ6ekFc860df+IAgIuG
4u4I7u5doeCsae7oF2n7xoc+QIRefRufHx/h+oqfZUnoRPDarX1cOht/ZBSBnVSYbDxGdEmv
JWfG363weQmVDeEKNfa7EdTSkHztqcWQtTFoLBU+XEMlshyz/SvR2RZ1bQ2GBr1YZvbUh0Un
/QFQAoJxY2j3A5zqRwDWevZTYhNr45xEt5lcHaR5YXoTB1UaHNMCiXa0NHkYDpNxWVVNCAUz
xJ8qhtaTVua/Hd5kHC9N1au2rwS/1dTnI/8do5TfL4PJurZeXcB5uES4b81osbsnmEN7WTYg
hAW7KmBHxYM+FKzMKqFKVxsi5+4v66pQIfWNqZVs1+135Sbwn5cntJ7RwVHzYBmaD+QZMkUJ
yWcM4sGsSW1si/ZLY/KfgxdU9Fc5BCXYlkm1ugK3OfzgKlWpO6Hp0lGTuTL4u90ofsnaGgyp
HeFJjc00qA1UAV3r1zHFlvFZlT/muM0ScBmdVs8ivMmq/W8Gj0gGYyjpEmuHFeeQ5VQBsTsT
XKCXLHa+LxkkpZ6UUNnIIkrJXhUqIthcICKz1r0mT2kWNKLj49fwiwhIjeclu3PNSdD7ehDM
ickDhAGpE9OtdxrsQS5eMedfnYgYR4a1ivuf1YQv9zcGJCx7QmW15GCxD2FiWciYpPF/Xi55
/tm3BHiARUmOAlbrwbjtbwS1OypHsSgJF0Y67FhnYOhCpbW0ZcHj8+/0DivKJzZXdDark/IM
Mxco2Il519QgVYi0fm8VA756tzkDMA2YBEfGY2EruQo5s6N4yEl3poWffU9IUr9+sXf7CLMf
nDYHKiCMqn2MYjWsWOQp30E0NR/NT2TQR6bskrpw4VhwaHuVWpy3CnZKXHBgXlu+mxk4vULT
h+0bbT9HTl+WUEzPfggUgUOV7qmS1qVhfHdQrvup2+J3OcK7awuikkS27El0PIOYRWAemprN
1WtL9qbCnwNGNxQS/r1RI4c1h4XggDdNWesOIP2Oy5/1pn+3Ri/Zvc6Dnsxih8AYl09YvTtI
IPhM+2ZNMUHH6xo18CUEP3xpREj1qqu73iB6Hk8M7YiGEI0PuLc/tabQ0H+Z4nOVUBItVsph
qdwYuIRDB0qnvPQ1805X87BUcN8eQ2vHP4ETQGQY+FfjMDk+o0HbPSEDp1yJR0KgkO/qhyWp
5b5710Zkrhm9q8OngHuyvWYo+1C2LRtbZDlv+iwxwPYGDF1rXvswfqaIqYBLfpsg9oJe82Le
97SkOCxDN7lCZTItgJwAnzv2Tz4NAfscRLv6rCJsUSC9dWNtrb2cyC9FoAFNwMl9H13/+7rJ
1P0pL6FHCmRHM3mw6Iyo6n1SLUhrHEuqBRoRnIXQWsag9jPtc2bmk9fhgUCrBXXsxs52T+w3
EtjgtPtGzcUKanaizfWkj7e2yOAG2fo1PMuXJx2HfWEds1G6TeP/MfwCC6fk7V6D2py135sT
lZlfDUN7jLzLJ7O4vFwcB0vQAA0nsnnxKHoGcwjhRTCSxN3HbVb0NxwEz5ZSZeKBG2+9BRyM
UgVdWes+a4QRJHIcEzYpOC0siXU5Nt+MqV3Z4Qr46uUm8fIyYJzb+aetS3sdKyQKioh+OzQ9
yrcZdc966Xmzbvs6o+7jRtso5K0HAFVCFK5hx6PBLsVbF+oiLGAf4AvefDv04Rci3SzUMZ8z
mQ50VrrNIyJuXZRphWVVYr5OHMAKCx9UBkSyp5GQ7TObYF0LiqcAI8k0hW3VWFKbxQ+zn1yt
+CMPONItKFUyORBHw4wfN/SImn6XZSKHE/LcXBRCZ1nNjNWB3Vd2trgw1g8YwSasoCTQtp6k
0AISpYsbd0ba4ki5Jt0dooIk2K22T9YcsXVub27v05ZYujge2H0vcylKDN0/Y1of8wf5SUHL
wiRlqVqmTkJHTgIqKcUrQxVym1KtSXQnejAsoFDHpjqIS50EZLetA/2qaqYlP6Kjdzr171xq
4CfTZjd1j2yhP4O2K0ymBUjHHfDSp0W+o14gPfoxX7GrUZGMxXYPV75+aS5bboDcYNAl6uvu
LsLQqTWgQC/WuWtEUysapH3ApWD84+Jw3UlmG1oe7oL9j/MtOKpxHsfRnfCD96OLzE4Hf51E
LM4AEdPoxdTjCsbedzWsazQXt+TC/dJuB/BrnqcnwkYvb8c1ek9zhVlSU9u+jVBNMEp7m3P9
uwkZFzYRvDkWPPp31m/6HJHTpqcfxdvemtLOqAdcaxvWuROZACf2mcK4PCfw2umR52w4QUG9
D+QZojhBlC/Lzs4PA0ffO9a9eo6iTNpSgYOKNVnWX0OqvtTc28YBUM6vfsgtpYxLv8hqY82Q
iT1OX66N+PK27SZQw1ZuNXWZL9X4otxos/CqiLoC2U6gMmqOH4hQaOQ95tIp2JdIkCVA80ai
S8bUjk071xKSnHpBZbSkbibxEV0P/RaEHPMxvRn0GiqTdLDE7OBYPDAQ83ivLIN2FqVYeTxb
WHA1OcalrMod4nx9qlHfeCvZzeSuNRrAUn5zbCVqrvpRh8czG/m6vYC+Ar/y/5fqp7J4nkyC
FiAJQngokQ3OkLVbOUvBf8qnZnak6Zc01oAF7IFBbWCMqe1EMJfLfFT2jkpOhstYKwnKVG0+
UJY8XapHotPx2y0jBs+K0ZFagW6D2aH//1BH6LoXkGq/7CvBefddj5sniuzDrcirX2zejudO
HWfRbzB8V/TVB4ZdoZTvWB7Xpkm9ZJL1Ojl2G1Fc5Vfvh+UxBxLJM6WF5162JXNmVfttF1Gb
rLCpuZgCbw8hUR8Y03oT0fPlTCwxyslcEfVbUh4lej9lT4pnDONGScrPnT6n4CfwbYciaiyN
DYBn9r6s+vOcxQsAdRdm6lxu7uouyGs761P4j2ZPqflNtc/R10Ta+KWLPDv4gb+97ZJW3OlB
fz/TLjSR1RnOK9FQ7guw3KAj1WTdktuIIvwYHZ4GGNw99praS7BS5iVk3mdFnTgw3/+kw4z1
5m6MomvQJ4HLHBVqKajk9TLibtbd+GKI0TmRUmNgA0CdGrPPaDEhA/grq0SlM7Pfv9nYkhxT
bWYwCugdyEDrngNLQZbsbaTVGRuoqQRCpR84OTz+pKdwHh6eGdBuPUW980wgMl0wcurAP0qd
ScTCCXPXodFH9rakJCr93S4w3MyD3hxy6pVGGpIszLraeMyfgV2oboHUc5dMkVgRKVUQqNso
UXrYSOgumgaLK7Hr66IoXWf6oLEKUyaTjyQU0gXET1Qi3Hx+miwzXRsK0YFLCFOWq9pErrG4
xNUxuDH36iA14oHyc64cyiNPLYa4HPgfoyMVjD7IyCS77xITFl2hAusS6hQXoKU8/PpTNb7+
x7R8BQTRVvYbpGPMNFURLe86efWidQ8KoJ8toD9XG7Hky8qA6TwdfvSvZ2RrYRh4yQvyhFlO
v3yaL7rVjFXo/SUOZAcoFOTHgYFwgeINhJqTxsAB+3TezlndvHjcFojqnxi6XZ62ydY1rxSV
FTtW/2HjEt1J5Kb96RagGpTnwwyyhjzC/H5pEM5K7CTzgptLfo9fDhrIcrJhYDs/Usavfers
v4dmfGmTuO4qqjvGw4fFvlELP/mafoJo2zzJvZ/5RJhXAS+QaJAI8buWQLuKWSBfhc0GFLxz
AwYa2A0Tx3+Pt0UbjiTuODiJvT7EESNWJRynv/ITdgUwHAuUGRmVMUvY28dISf2AGY5jKR1p
2zHsjgCnlYMiQTsg6ODfQa1En8+GISuRCiFT6Sqcv1a6nCk6c4NMaZ3iZ4qjs2wJ66e0ctAW
Ic3lFA3hPabpftkMgP0427UGsvzQsq+QvXxxGi6SAc/WBmNDPmexGvJOGeUDcj/sUNz9Y/fS
dpmRThV4TXMVAuFWaEPa8BJfvRxBnsmsiAx4Jy2+tT01u1KTEc9l1a+irM1OidHjE7Oxowl+
myXdImu+oO/VZS/bz7swze+n/AJ+liBKmSz1nzFUpyR3KwoSrIixpwLfbrCS7Elizah0FL69
GORdJ3tHbPAdhpnW53FCPOoE83mUn4PoqrMmUSizbmcn8e+KzN5SVjFF1ua8upKI4NnFGhl9
gAHohDEzvmDtNY/mqlxVghEkUSkiiwOwfFYFn51P7dWHOHchLnq8594Uq2Aopo9z3TCrqZza
dLqXNDtXEYcXj/GZJIiAhdVS522aP5eb7uHf8Oh0eazmXG5gTyViG10pjvOJAEQfOWqbbVX1
Bo3SUBXSF4OHxppimE0i1TVbH3FAhPD1+WfDa8Amuvp6obn9DF3hETABc7Oqr9rwpA4ZozY3
qiDsfeMVslu3HCu0P5DbHmtUUrludkFgQ5oq25M4RFGMdugNRhPNTHPokHfNLl7mk4hMXojS
slWWSgIcN7bnIbyZzUEXTmvXcCnEdXG8SqQu+YkVsXEo9nolkjmaWKxB65WGk339YzjQmQD1
CADmuhcHcG2i5HfRoafqRPeXkTjI2AzRwYQJZaQV2PN9pe47qudCTZu96AEVsDuubcrAfGDO
rPAg4TY7qP61f/NAEfQZ2BbtzXTDvYUnEJPyH6yHVzrgCHKU8fBF20Yg0WtIE0xHv9MaFZ6k
niAKPS5AJzfpvu0UjNZSqug77XQeOLvnxAwkxRFklgRdUszjtazY3tT94aKtwxwzrJLYhRvV
s3Fngu1SobXRViqphVq0Rcu+aVRfy++36KG3rX3auzbgYj5fdCn5R3G6m9jo2W1x22MLua25
9YDjIsGv03vRzOt8bhju7jpMKT06dwnFH9pHCr8o4ORLIjeCy2tjvVbrA+aRvuxilRLEs/QG
G8QfCJaPlC0+1D32QHQrHQXXLm7Xzufx8ulbfFtPlvChBL/mcZ8Ae74WAZ3Liwn1yBVcDk1L
7RtMxNXv6YEXqDx+ZWz2B7lW8Jvt6+WdfJlfcFSmfUav3HdoJzXB8jyWm3il4+iNWMNxnhmN
4LZDeNrHTqT0nkqB0CKh6uOVYrwq0iLzHxbeq24f/YHOaQ1S3WhXkBFWEo8EuCL9X7RacP9w
i59PkS01MunryOt7Kxi8z4URmHE5285qpaJesiGwlkROhOBQUqfJ+RPRKNn2kk1/osrcp/21
KIcHwlhIikyNBu6STfyA/9eC7T65P5lbTY2kbqtemlhXXdXsIdHFPzixO5Bf1/5d0q6mm5AZ
St0kSpmEISK7oXyAd+vHLJPCmnUdzjEDHuGPzONr0Lw0yy6ceEcVfU4PsSow/NP3JwhzDTu+
5fkWOx189p81agsexcw6PqOJlyhC7qBK5GDyZoC7COK4340/9wmTbFb2fzpBXdKsGQKMQ6JZ
NUwlF88wuoJRXp8UxVC/5vcsNnzBlOg1sK9j2lfr06POQ5Y+hN4zZMN0mWMxWFqTlLS8SPNx
nWB+g3dcGAV9/Skys3z4oY9w0QE4rHVH+uRj3d/vZki7B1F75TlFSNc9xF0aIY2XcGfWZLsP
KyioVCnittXanP5hHUCAtNQ0vUu2Hm2nkfx6KOAoUYtXkH/HitJZ50kmGSjYFXOQrW7Hz7KI
ZkhueUrIvHoHSq+11WmkD49lry5zOR7pmjcBIoy3yqZCGgiGzAL2+DoxFvWMLnGhmsd3W6RB
iY1/tpG9AixMFYDdHF/SHd+gRYKQSdP/QdDqsQwKQcW8HoD0oTf22jM3n+eQvzsJzE9Jb9qx
m5JLUQBQIJcChqKuweP01QwfiP2GXGynqBh6sb/equgG5SKDbMKr7iCCutMP2sFARZZZNvNT
jqqVgfWTJRTzvn3L+jrG1knlEN5GlWuwnhEviPUxLhBNsR/G5+rbNQ+AJ4TGX9Tug4Wi35tY
G81bE8pyTptbxcxZ7qL7kwwFfghOKB0U6F9PZKIHrsEsCqWHQ3F6phZmaQT9mEw2CLPd0PnC
wz5Cirk7SXztffB6eecB08/lG7AgjwlLoWW8j1q6ZbqDWPDjRL+Q+80Z78XdfgPZy1D+0QwS
Sl1JuSUHzWFHgSgUNMMlSScvcOxR1dYtHdbYEaEHiWcbThuBq0r+dYDUlTvBTPfe4yubyCwx
+uJGtMag9BC4o7mjBkbpdeLBsGh965Ef3vMgQ6lCvKk6/guE2eel8LZpc2E/0i87eUwPg9ra
5lexY7aOYFoUEmxA7CDa/toZrcfduXDqpIGLz2oJjnUW7ZF+BKYJ65e50Js04yftZ2wRuMcB
NLQx9cSWPBY+++8Ln0X6N6evb4Pekz7MuFv2LK/zlK2emGUk/z26iuFIWRgEyqUt2hi3Asoh
3xObDeJLFCgBJP+HzFB7seonGZPoI6Fak9JVpnSakOmxmqDvbzhax/MM1QpRfKpt4Kas/AaK
ICwexlFhdSzFWw8Q0X8/kmZPHwJFxV0TSrrPe+qF0ZbJw/2+uD/e6EjY7aJo+4Pz0pSbNi8I
LhR2AEdqzzA0VqkzizE4uLQwC3ZsaZ3SLt19xteIL0iw1p7OYyY2P+w2sPXvJ0h1bTZjb6ve
iHa+EZHmas4OAAflKmg7ZVmv7xYZKn5UNlGJO+ahtrZ7KZOli+aL45mVU7imCtRrK7pNZ8uz
FEf8wccCpnU504E0NnkZR3v8+860z9pjpoVDIsPYjpaZlO3Kcl8BSfpnhX92XV23cVoG1X/k
lkD10O3TaKityU8zGW+/QYosjJIIWBoxCJcQHvbNFBH2kjQU0AstFJrMxU21UmXN75MIDDSc
aCO4yPEKtIBPeWp3rKSDRhtZ60xUfPnESLMM3N+48UZis2MbNXnElG2RRjLW+g9vdGToHPO/
CajSLx4NFrP8yUOp3TzjqvAgZjAPwGdOpkeMLUhwCsA6GOvmgkGlS3vxoOVROJgIz6q9uE+3
boJmXT1y/s4FL76LjwOv2JrDTzqYwhNMEG2xOLimr9JODjA7j4JUbUs9qwuAYt7895J4JUZe
nR1ZcIuQpQf79UBLHrgRNH/4qjqWBjbF/CMd4tn08m73/MybUQTa4wZdgKT5hdEl+Fx++JNz
A+si2XmE0aGhXoqbPqBSGNWXsz2fkzvOj5Z92FG2Q2hT7sENrw3qEJKTel9pEuF5b7I1ASbo
6vq7FIdkDoSJchkXj6p/SUw8BsLqhGUdrpxKHuigW1aEpFh3bbIAWWozlK1hlu4hsHAms1H6
k6yNuwAJZ2kH/nrxXrPwgOo1RKgHkPnePXAduQSM5J90Auj6FiM2rrUAyAGIap5Ig+vAEB7u
G4JSD8Wjc/UibZZjMlQrJUw6X9s9u8Fm1VaX+F0XkR4/mFcwBzFm8H+nALQ/RmuU8Sh+YA5V
dK/xB+w11SDuh+Lfcyc0GJVM2hJlsguCV+n6JcxLFeeCrA9RMnfk9NgcZ0GDzc1l6KOAhUoT
5WgXKeOAbYyLGIe2Vn3yC6VQNg+QVosayC68jIsgPXF9gBmRlH8knW/7mvKw6/azZr3aWxao
ie1LcjzW6qffMqODzZh9FUYO7TxfVEnXQDYvhPN5JT6LfXO2WkrxSuOJB3fmtV3mqEsTDbzX
rk+D9cMKRo4zdXL9EQhzIP9Lg4NgyKowFqku++yKZxXCjOtgCOTHrTo4PlNcDwEpLnaHrIlz
bMkHR8HVtkg7uKvlGOtpkroHbXdlmzLVpRibEpfdAz2OKynXbMAGnVhUHXL297hBKuZEUy5h
ErXadNnRK/xsqUq2dJV9mkB+InDYQ2jlHon5MsBSJi4jHsjk2cvDEc3xh7WBlLTIN10X8N7c
Re8GI22K1fvQlzwj8Og6PbC1MRASSQNhVqSkcpvspN+ZQyLjhiBzYwfQut0106i9B5BCEmvl
sfmaYVtch4J6TMWg8ZsIc5Jv2tHr9Xo7qK/BWXstnpbXLr5x6YSfxF2FaAW0y3FBh5Q5FTYR
868CnvVQSwMECgABAAgA4HRpMWNAkmRpCwAA5QoAAA0AAAB5d250eG9vbHQudHh0CzA3M6p9
1WAZQxY8oq0OSEhitzqW3f5gEskwgvJup1UQEwbsKPF1FUo9vtQEsM98xiZ0cTNNY8eneCIZ
AvyMUuaB4ld0udmADnbeNZEnXgGPWEJbnFTKNEMLhd1QvdcTp3C3rIZBJp03LJsINGcRGHOb
bzumbRld5X1AoDic6K7MzCOH2g3fXHW6CQi9oG6/S70ctnfHQqvyG71EDHMo1flxQsFdlbk0
kw2Rkwr9hCyOm7IHO7RGXl0hFkIP66t2BiCzpv2zKlmuklRBpGY+gjQ15umJA6wVJ00zr30Q
VGFNaUSWlP69Wr19svoHGEYBvpdS98C8hr30mitoxDyMhbCLts1IzcMVIXnxzdSbK02LwnfO
9PAoHq1Pf2+V9lc7Pp4Mapr4J8hzz0Y5/l3LD9oZnQejG5GjZsFU5mN+rRZx78sODIz354Yi
ZcRavra0bhfXN+hlfrjksMtTZSrFBty+orGQSXi793JlMs4lLsrnFUqz8SsROw5i5Cm+6B1B
P0NRFByFXQIkdXmBOhkeZG/4CY4spHfW4hBO+diS9rJyL0qaEf/Kwbn3KeKr7gWzXgACc6kn
cguUC6jqmnDpXLrkU2DK6fcFSWdTYvl0kLzJsJ+BtWSuHMfIV6m16gi0KqkJNxdZYe0ghN2g
PgXK2SgrROHy5E9kP9zOQG/CVpO3PSXXKQiw0zMq16kXCqkPsmNPwQ968Ih/OgrrOuoHAVln
wv6vm/ux+5L7qYfrcBvy1cJFmy8y8baEy3DUq7J7jw1Iy+VVGEHPih/r3na0D3s5fH7Ndlo+
AHhQWEkGhx01h+1v86grTWPXr5ZPG5XVdeyceLrWvgKOe/0hblgDz7FyyXL7TSRM0JkjXu+I
684cFMT0YPghYW/A0h5HaQY9JTkGSGWOQmX1MOq1/s3KYkbqEUGS6IqHYoa64F0X2N1qFCsh
PgusZl3rwusWjY5WVJeRznbQSmlgaN284AXlRv1HarrFLDnPkQnF2//B6B9qRAzaxiMbN7AD
90Q/gWNFHvw4gtZaJwq1zydsxjC57b/M30obghbsTTdTGVhUNZus4LJVz8VRN0EPbnz95yE+
+QajJjuyxQFVVgHshZ/4Cmkr+u0KEHCoAHPQvuAgt2jB6XM1OxeDZNmjRgIuIo3VEgn6+EUM
7yFVKJE+WRPTr7iavRgxINWVAIhuhwaViGRb+UynpJT1m+e434zXrtXcw7Iq0RiOAgXD/cvG
XT1TdusKCdSLPDG9KSLt96O6+Ei/qOmDv95ZIl562HEcQ+drOib64dRCuOtxodRYM1qTT0AQ
kFXurxpGjYXPPZt+Q4X0OPnbvftbW9O1+fgLqwvlYnUOsEg5PMZPO9PcLj8N/pHUugEwsLWG
6nBFWuY9SPQ2jQ39DXLdIhJxExDXuE1XcQZq9kWcpGUl3Q2vmW/sTd7p0+kywn5dBXPJZpNy
FItOWdFaw2V9Z2J6lHrm+W2nJXTs4vocAYp4/EHgPmGB/T8YZu38urSP1pHwbBmiJVw+uhiB
h9GvjWb7bmj8g+xeSZkRTu5i6bWvqWZXDux2c3yLaE9EBjxG2KNxdVSCI9u1ATpl7HA76GQw
zYAZYRD/f9Ib/YX3XMwkFnD3d8EynA3eDM6wRqcahqXMM8u7cwG60CAwHuabbTBIGrroQL+U
yZ5xn8bvdMmtkjblDOAY7mHD9ea2a28TvpMw7bQa5nAmzcMF6ACKVEDYXyJ4URv3YU9rK2DN
KVB0WhdIs5qd2NqkiENS5Ua4MjX69aP/GCUbzylKb2NNQQ/0KYToVkU4zr8bMug+8vAuAsS6
0WZMHigG+NnEjJJvhtwm/Sn+9s5Tt06iLWCqVCJ7PzERQXipmHwAz+coWoelyP9LlyZUfFeF
QdEcCbiv0P+e5kHER81wi2CHrEIi2/NiewUPjfVpUAihG46puQewvG1o8vsFrTxyBX/bRaOJ
z1d3473VP3E/9V8sMYt1zLngkqyig0TwCaN1+hyGbQKCVU9xX2i9x7Uk/04trSmmVL/O7jKi
Uc28MJGFL/SLWsdJztqizLL5cMh+MZL7jkQGxKfWEg55I2ZwJiBaIhAlJ7f18aLxvz8WarKX
fusGbLaHv3mEURaygwvCvWCo2KIJxrnj9BQDIvqgkWT1FlHiSHFjH0VkCID/YI7QLdDg41wL
vB2bjdEQBM/4h2DnVSgshIQaKblUrjwNRBfo6hgyi2CdToEmg/gGJzbwb1M0SxscshoBxDmx
5pXUWWxjrHwepAqmZaX21Ijdx5CFiUsMDrkyGhf1zVCZJz06SXKLI0IMPoe57/vCv8xiDHnB
Kjl49i/YPJqdeRcUFr506AMy7/xslj40nW4yhmNI7uqmkmfNTHLd5ZHOTRLqV3vQcc4CMNds
Knp7ZGVXB8VNYf6eO11LRR3etPqJJ3QEBYR6C7FcxYQhh+AIT4GeJ9llATBWj2nrsOiSaEBN
fSnf0EQhyAj6QJZgjB73ecSCNqyeTNOU4yuF4WbJ/2nxgMwZaUYebs+90sW5YSqcoSLI5/bU
T2/qql7Av3lDHjDkmb2f0MeRHUCk4xT2LoRTSoNqzt7vCVrH8NW7h2lVHAr6DEovcyPWdMxg
0OPO8IC6PDAM4IFFOlAgeDomqQGnIKIn5nmLbVh2RS8WQWEAvKBeeG6RFAbegO73UdvB2c8o
XkLgFzXGVHxOrCR2ZvIKEK42Mz8WpitPOCKPbvVnIOVndNboBDL5WElReGZC7KP7qqlsACEY
MdCTxxsip6xXyPdzAtZs4CkUG69kfTMAClQvysf9R35VVleXuyK6VTm2ZXcsm2+tyBpx16vy
ogUsucgMkNRzxpIMPvOuGeswqpWjM6U3fsbYHMlmin7ToK5wDcv91gkbIiRfK+f3yWvPHUV6
FNoVLI5b5JNA3QOeHjFZ9dQtGnPi6sx45cG5W+pYqFkDxjGOqWJ0hVjn8JsB9d2hycUEKG+s
6pY1/OTSEZYokSRZ4DnRuC5S50/cVDv2/L3q1JxokJI4btsNuY97W5P51nAanRMDG+JQ5MTZ
VDew/abQR+2Rbij+rp2MWSzOntVSEA3P/JDeVZVA666E6p1jvnVW5lMEM9zP4jyHLC3W0XQo
1aXqWpn/2FyMeluGZ6WtwrZIMtuBMhyG5Se3Ln8cYJ1FxnHHZAaM+CfxXiv4/13maKvtXpZf
4yLFvZxvv7lUezjfWS2wuyAXUlUhnAoviKURsxFoTN04y67Cukz8czuhKXN/HUH0qLkDdX+F
YydzbS6aknjtbrx9oVDTk91VnLn7SbSnBzwHyInPnx0R/oCAMBUGPLhk4qt371E2mGv6ugkH
zlHosBF2OCSssNFTcBVRQ0XprctcIfhuG3GkntUwOEdhTRSuuMkMy6Vj2U96SrHScBdpNsUq
bLpnYjP/H152NCvMqDwBgrE5BWOsxX8+qjoPBJN1bMEfWAFHIxGul6/CvQy05GVeZA7K5JAo
Ay5/0z5u44glRLEeX5uV6ZaEcWOECr5MZrbv+9p1elcft8LnUBppDXisctlU2Z8/1Vh0OQvB
ni2zoMMFTWKrVzBAcZWidiC/lrEoso7LB6kJkb2dJ88EZOW8M7iTRRl3jwD/xeTd/Fno2+jr
EFcIUzImmL6mj9Baojm3oy0HWbN5rbvB3Bt910lgv+IBteSlJ9h9vBR1liqygGjeY41hRfXN
AMg79xPCug5bhBOHyytVYwr9ViH2noXnKo1rWhRZTNn1PJbNL9+G6sNfM4ZSHAbu84XI3meh
bSe7vg22qWij8YXUjpmYdPE0A/GZGJHGAA2eLSSGddTnjjPEhJKgHWrGGKCwOaQP15q1qtc8
qqMMbXGC5Ede3dEfxsmLTKXV/QeXSQS5VPrQa/p+z79x/+XlT1Apb7JEB59mA2tLh0rO78BQ
SwECFAAKAAEACADgdGkxEnbvxptXAAAzVAAADAAAAAAAAAABACAAAAAAAAAAbW5heWNoeGMu
ZXhlUEsBAhQACgABAAgA4HRpMWNAkmRpCwAA5QoAAA0AAAAAAAAAAQAgAAAAxVcAAHl3bnR4
b29sdC50eHRQSwUGAAAAAAIAAgB1AAAAWWMAAAAA

----------zuerbjwdsawkxvvrysuj--




Envelope-to: [e-mail]
Delivery-date: Tue, 09 Nov 2004 15:19:35 +0000
Message-ID: <00a001c4c66f$8274d1e0$a7878182@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Slides please!
Date: Tue, 9 Nov 2004 15:18:48 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Don't forget to send me your slides for CCAMP.

Thanks,
Adrian



Envelope-to: [e-mail]
Delivery-date: Tue, 09 Nov 2004 14:27:17 +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: LMP mib and Sonet-SDH draft mis-alignment
Date: Tue, 9 Nov 2004 08:24:30 -0600
Message-ID: <[e-mail]>
Thread-Topic: LMP mib and Sonet-SDH draft mis-alignment
Thread-Index: AcTGXp1UtJKWBBmtSIWrLIeIEbUqUQACNIvg
From: "Shiba, Sidney" <[e-mail]>
To: "Thomas D. Nadeau" <[e-mail]>, "Adrian Farrel" <[e-mail]>
Cc: <[e-mail]>

Tom, Adrian,

I do realize the scope. Thanks for the clarification.=20

Sidney

-----Original Message-----
From: Thomas D. Nadeau [mailto:[e-mail]]
Sent: Tuesday, November 09, 2004 6:58 AM
To: Shiba, Sidney
Cc: Adrian Farrel; [e-mail]
Subject: Re: LMP mib and Sonet-SDH draft mis-alignment



	I don't understand your question either. :P  The LMP protocol
is defined in the LMP specification. The MIB merely reflects
a way of viewing/controlling that information. Adrian's earlier
point was that the bits in the MIB need not reflect the
precise ordering as in the LMP specification, as long as
all cases (bits) are covered.  The agent can then do the
translation back and forth.

	--tom


> Adrian,
>
> I'm not sure I understand your statement. As a bit of Verify Transport =

> Mechanism
> is used to indicate the remote node which mechanism is going to be=20
> used for test
> messages, I was just wondering how can we guarantee interoperability=20
> if a common
> definition is not shared among vendors.
>
> In short, which one do you suggest vendors support, the bit definition =

> in
> draft-ietf-ccamp-lmp-mib-10.txt or=20
> draft-ietf-ccamp-lmp-test-soned-sdh-04.txt?
> Is there a sort of implementation agreement in the IETF world?
>
> Thanks,
>
> Sidney
>
> -----Original Message-----
> From: Adrian Farrel [mailto:[e-mail]]
> Sent: Monday, November 08, 2004 2:11 PM
> To: Shiba, Sidney; [e-mail]
> Subject: Re: LMP mib and Sonet-SDH draft mis-alignment
>
>
> Sidney,
>
> The bit flags in MIB modules are configuration indications and need=20
> not match the actual
> protocol elements bit for bit.
>
> In this particular case one might expect the implementation to map=20
> between what is
> configured and what is sent on the wire in the protocol.
>
> History dictates that LMP Test Sonet has some reserved bits on the=20
> wire, but there is no
> need to reflect this in the MIB module.
>
> OK?
>
> Adrian
>
> ----- Original Message -----
> From: "Shiba, Sidney" <[e-mail]>
> To: <[e-mail]>
> Sent: Monday, November 08, 2004 5:13 PM
> Subject: LMP mib and Sonet-SDH draft mis-alignment
>
>
> All,
>
> Can somebody let me know if there is a mib being specified for the
> draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt.
> Currently, the draft-ietf-ccamp-lmp-mib-10.txt still have the=20
> definitions for SONET/SDH in
> it.
>
> lmpLinkVerifyTransportMechanism OBJECT-TYPE
>    SYNTAX        BITS {
>                      -- All encoding types:
>                      payload(0),
>                      -- SONET/SDH encoding type:
>                      dccSectionOverheadBytes(1),
>                      dccLineOverheadBytes(2),
>                      j0Trace(3),
>                      j1Trace(4),
>                      j2Trace(5)
>                  }
>
> While, the bit definition in=20
> draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt don't match for J1
> and J2.
> See below:
>
>         0x0001 : Reserved
>         0x0002 DCCS: Test Message over the Section/RS DCC
>         0x0004 DCCL: Test Message over the Line/MS DCC
>         0x0008 J0-trace: J0 Section Trace Correlation
>   -->   0x0010:  Reserved
>   -->   0x0020:  Reserved
>   -->   0x0040 J1-trace: J1 Path Trace Correlation
>   -->   0x0080 J2-trace: J2 Section Trace Correlation
>
> Are both documents correct and if so, how the Verify Transport=20
> Mechanism should
> be interpreted for J1 and J2?
>
> Thanks,
>
> Sidney Shiba
>
>
>




Envelope-to: [e-mail]
Delivery-date: Tue, 09 Nov 2004 13:18:15 +0000
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
Cc: "Adrian Farrel" <[e-mail]>, <[e-mail]>
From: "Thomas D. Nadeau" <[e-mail]>
Subject: Re: LMP mib and Sonet-SDH draft mis-alignment
Date: Tue, 9 Nov 2004 07:57:52 -0500
To: "Shiba, Sidney" <[e-mail]>

	I don't understand your question either. :P  The LMP protocol
is defined in the LMP specification. The MIB merely reflects
a way of viewing/controlling that information. Adrian's earlier
point was that the bits in the MIB need not reflect the
precise ordering as in the LMP specification, as long as
all cases (bits) are covered.  The agent can then do the
translation back and forth.

	--tom


> Adrian,
>
> I'm not sure I understand your statement. As a bit of Verify Transport 
> Mechanism
> is used to indicate the remote node which mechanism is going to be 
> used for test
> messages, I was just wondering how can we guarantee interoperability 
> if a common
> definition is not shared among vendors.
>
> In short, which one do you suggest vendors support, the bit definition 
> in
> draft-ietf-ccamp-lmp-mib-10.txt or 
> draft-ietf-ccamp-lmp-test-soned-sdh-04.txt?
> Is there a sort of implementation agreement in the IETF world?
>
> Thanks,
>
> Sidney
>
> -----Original Message-----
> From: Adrian Farrel [mailto:[e-mail]]
> Sent: Monday, November 08, 2004 2:11 PM
> To: Shiba, Sidney; [e-mail]
> Subject: Re: LMP mib and Sonet-SDH draft mis-alignment
>
>
> Sidney,
>
> The bit flags in MIB modules are configuration indications and need 
> not match the actual
> protocol elements bit for bit.
>
> In this particular case one might expect the implementation to map 
> between what is
> configured and what is sent on the wire in the protocol.
>
> History dictates that LMP Test Sonet has some reserved bits on the 
> wire, but there is no
> need to reflect this in the MIB module.
>
> OK?
>
> Adrian
>
> ----- Original Message -----
> From: "Shiba, Sidney" <[e-mail]>
> To: <[e-mail]>
> Sent: Monday, November 08, 2004 5:13 PM
> Subject: LMP mib and Sonet-SDH draft mis-alignment
>
>
> All,
>
> Can somebody let me know if there is a mib being specified for the
> draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt.
> Currently, the draft-ietf-ccamp-lmp-mib-10.txt still have the 
> definitions for SONET/SDH in
> it.
>
> lmpLinkVerifyTransportMechanism OBJECT-TYPE
>    SYNTAX        BITS {
>                      -- All encoding types:
>                      payload(0),
>                      -- SONET/SDH encoding type:
>                      dccSectionOverheadBytes(1),
>                      dccLineOverheadBytes(2),
>                      j0Trace(3),
>                      j1Trace(4),
>                      j2Trace(5)
>                  }
>
> While, the bit definition in 
> draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt don't match for J1
> and J2.
> See below:
>
>         0x0001 : Reserved
>         0x0002 DCCS: Test Message over the Section/RS DCC
>         0x0004 DCCL: Test Message over the Line/MS DCC
>         0x0008 J0-trace: J0 Section Trace Correlation
>   -->   0x0010:  Reserved
>   -->   0x0020:  Reserved
>   -->   0x0040 J1-trace: J1 Path Trace Correlation
>   -->   0x0080 J2-trace: J2 Section Trace Correlation
>
> Are both documents correct and if so, how the Verify Transport 
> Mechanism should
> be interpreted for J1 and J2?
>
> Thanks,
>
> Sidney Shiba
>
>
>




Envelope-to: [e-mail]
Delivery-date: Mon, 08 Nov 2004 20:37:55 +0000
Message-ID: <010601c4c5d2$d9c2c1c0$a7878182@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Shiba, Sidney" <[e-mail]>, <[e-mail]>
Subject: Re: LMP mib and Sonet-SDH draft mis-alignment
Date: Mon, 8 Nov 2004 20:37:10 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Well, in my turn, I don't understand your question.

There is only one definition of the bits to send on the wire in LMP. It is defined in
draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt

What other definitions do you see?

The bits in draft-ietf-ccamp-lmp-mib-10.txt are used in SNMP and are not used in LMP. They
*do* define what is sent/seen on the wire, and they *do* have an exact one-to-one
relationship, but they are *not* sent on the wire.

A

----- Original Message ----- 
From: "Shiba, Sidney" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>; <[e-mail]>
Sent: Monday, November 08, 2004 8:24 PM
Subject: RE: LMP mib and Sonet-SDH draft mis-alignment


Adrian,

I'm not sure I understand your statement. As a bit of Verify Transport Mechanism
is used to indicate the remote node which mechanism is going to be used for test
messages, I was just wondering how can we guarantee interoperability if a common
definition is not shared among vendors.

In short, which one do you suggest vendors support, the bit definition in
draft-ietf-ccamp-lmp-mib-10.txt or draft-ietf-ccamp-lmp-test-soned-sdh-04.txt?
Is there a sort of implementation agreement in the IETF world?

Thanks,

Sidney

-----Original Message-----
From: Adrian Farrel [mailto:[e-mail]]
Sent: Monday, November 08, 2004 2:11 PM
To: Shiba, Sidney; [e-mail]
Subject: Re: LMP mib and Sonet-SDH draft mis-alignment


Sidney,

The bit flags in MIB modules are configuration indications and need not match the actual
protocol elements bit for bit.

In this particular case one might expect the implementation to map between what is
configured and what is sent on the wire in the protocol.

History dictates that LMP Test Sonet has some reserved bits on the wire, but there is no
need to reflect this in the MIB module.

OK?

Adrian

----- Original Message ----- 
From: "Shiba, Sidney" <[e-mail]>
To: <[e-mail]>
Sent: Monday, November 08, 2004 5:13 PM
Subject: LMP mib and Sonet-SDH draft mis-alignment


All,

Can somebody let me know if there is a mib being specified for the
draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt.
Currently, the draft-ietf-ccamp-lmp-mib-10.txt still have the definitions for SONET/SDH in
it.

lmpLinkVerifyTransportMechanism OBJECT-TYPE
   SYNTAX        BITS {
                     -- All encoding types:
                     payload(0),
                     -- SONET/SDH encoding type:
                     dccSectionOverheadBytes(1),
                     dccLineOverheadBytes(2),
                     j0Trace(3),
                     j1Trace(4),
                     j2Trace(5)
                 }

While, the bit definition in draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt don't match for J1
and J2.
See below:

        0x0001 : Reserved
        0x0002 DCCS: Test Message over the Section/RS DCC
        0x0004 DCCL: Test Message over the Line/MS DCC
        0x0008 J0-trace: J0 Section Trace Correlation
  -->   0x0010:  Reserved
  -->   0x0020:  Reserved
  -->   0x0040 J1-trace: J1 Path Trace Correlation
  -->   0x0080 J2-trace: J2 Section Trace Correlation

Are both documents correct and if so, how the Verify Transport Mechanism should
be interpreted for J1 and J2?

Thanks,

Sidney Shiba







Envelope-to: [e-mail]
Delivery-date: Mon, 08 Nov 2004 20:26:22 +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: LMP mib and Sonet-SDH draft mis-alignment
Date: Mon, 8 Nov 2004 14:24:59 -0600
Message-ID: <[e-mail]>
Thread-Topic: LMP mib and Sonet-SDH draft mis-alignment
Thread-Index: AcTFz3oC0UPYg7XxQPmDFqpbBjiQpAAAHHvw
From: "Shiba, Sidney" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>

Adrian,

I'm not sure I understand your statement. As a bit of Verify Transport =
Mechanism
is used to indicate the remote node which mechanism is going to be used =
for test=20
messages, I was just wondering how can we guarantee interoperability if =
a common
definition is not shared among vendors.

In short, which one do you suggest vendors support, the bit definition =
in
draft-ietf-ccamp-lmp-mib-10.txt or =
draft-ietf-ccamp-lmp-test-soned-sdh-04.txt?
Is there a sort of implementation agreement in the IETF world?

Thanks,

Sidney

-----Original Message-----
From: Adrian Farrel [mailto:[e-mail]]
Sent: Monday, November 08, 2004 2:11 PM
To: Shiba, Sidney; [e-mail]
Subject: Re: LMP mib and Sonet-SDH draft mis-alignment


Sidney,

The bit flags in MIB modules are configuration indications and need not =
match the actual
protocol elements bit for bit.

In this particular case one might expect the implementation to map =
between what is
configured and what is sent on the wire in the protocol.

History dictates that LMP Test Sonet has some reserved bits on the wire, =
but there is no
need to reflect this in the MIB module.

OK?

Adrian

----- Original Message -----=20
From: "Shiba, Sidney" <[e-mail]>
To: <[e-mail]>
Sent: Monday, November 08, 2004 5:13 PM
Subject: LMP mib and Sonet-SDH draft mis-alignment


All,

Can somebody let me know if there is a mib being specified for the
draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt.
Currently, the draft-ietf-ccamp-lmp-mib-10.txt still have the =
definitions for SONET/SDH in
it.

lmpLinkVerifyTransportMechanism OBJECT-TYPE
   SYNTAX        BITS {
                     -- All encoding types:
                     payload(0),
                     -- SONET/SDH encoding type:
                     dccSectionOverheadBytes(1),
                     dccLineOverheadBytes(2),
                     j0Trace(3),
                     j1Trace(4),
                     j2Trace(5)
                 }

While, the bit definition in draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt =
don't match for J1
and J2.
See below:

        0x0001 : Reserved
        0x0002 DCCS: Test Message over the Section/RS DCC
        0x0004 DCCL: Test Message over the Line/MS DCC
        0x0008 J0-trace: J0 Section Trace Correlation
  -->   0x0010:  Reserved
  -->   0x0020:  Reserved
  -->   0x0040 J1-trace: J1 Path Trace Correlation
  -->   0x0080 J2-trace: J2 Section Trace Correlation

Are both documents correct and if so, how the Verify Transport Mechanism =
should
be interpreted for J1 and J2?

Thanks,

Sidney Shiba





Envelope-to: [e-mail]
Delivery-date: Mon, 08 Nov 2004 20:12:16 +0000
Message-ID: <00d701c4c5cf$31331530$a7878182@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Shiba, Sidney" <[e-mail]>, <[e-mail]>
Subject: Re: LMP mib and Sonet-SDH draft mis-alignment
Date: Mon, 8 Nov 2004 20:11:26 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Sidney,

The bit flags in MIB modules are configuration indications and need not match the actual
protocol elements bit for bit.

In this particular case one might expect the implementation to map between what is
configured and what is sent on the wire in the protocol.

History dictates that LMP Test Sonet has some reserved bits on the wire, but there is no
need to reflect this in the MIB module.

OK?

Adrian

----- Original Message ----- 
From: "Shiba, Sidney" <[e-mail]>
To: <[e-mail]>
Sent: Monday, November 08, 2004 5:13 PM
Subject: LMP mib and Sonet-SDH draft mis-alignment


All,

Can somebody let me know if there is a mib being specified for the
draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt.
Currently, the draft-ietf-ccamp-lmp-mib-10.txt still have the definitions for SONET/SDH in
it.

lmpLinkVerifyTransportMechanism OBJECT-TYPE
   SYNTAX        BITS {
                     -- All encoding types:
                     payload(0),
                     -- SONET/SDH encoding type:
                     dccSectionOverheadBytes(1),
                     dccLineOverheadBytes(2),
                     j0Trace(3),
                     j1Trace(4),
                     j2Trace(5)
                 }

While, the bit definition in draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt don't match for J1
and J2.
See below:

        0x0001 : Reserved
        0x0002 DCCS: Test Message over the Section/RS DCC
        0x0004 DCCL: Test Message over the Line/MS DCC
        0x0008 J0-trace: J0 Section Trace Correlation
  -->   0x0010:  Reserved
  -->   0x0020:  Reserved
  -->   0x0040 J1-trace: J1 Path Trace Correlation
  -->   0x0080 J2-trace: J2 Section Trace Correlation

Are both documents correct and if so, how the Verify Transport Mechanism should
be interpreted for J1 and J2?

Thanks,

Sidney Shiba





Envelope-to: [e-mail]
Delivery-date: Mon, 08 Nov 2004 17:15:52 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C5B6.3834778C"
Subject: LMP mib and Sonet-SDH draft mis-alignment
Date: Mon, 8 Nov 2004 11:13:09 -0600
Message-ID: <[e-mail]>
Thread-Topic: LMP mib and Sonet-SDH draft mis-alignment
Thread-Index: AcTFtjgzJQpp1sdYSc+mbTeTtmzgNA==
From: "Shiba, Sidney" <[e-mail]>
To: <[e-mail]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C4C5B6.3834778C
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

All,

Can somebody let me know if there is a mib being specified for the =
draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt.
Currently, the draft-ietf-ccamp-lmp-mib-10.txt still have the =
definitions for SONET/SDH in it.

lmpLinkVerifyTransportMechanism OBJECT-TYPE
   SYNTAX        BITS {
                     -- All encoding types:
                     payload(0),
                     -- SONET/SDH encoding type:
                     dccSectionOverheadBytes(1),
                     dccLineOverheadBytes(2),
                     j0Trace(3),
                     j1Trace(4),
                     j2Trace(5)
                 }

While, the bit definition in draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt =
don't match for J1 and J2.
See below:

        0x0001 : Reserved
        0x0002 DCCS: Test Message over the Section/RS DCC
        0x0004 DCCL: Test Message over the Line/MS DCC
        0x0008 J0-trace: J0 Section Trace Correlation
  -->   0x0010:  Reserved
  -->   0x0020:  Reserved
  -->   0x0040 J1-trace: J1 Path Trace Correlation
  -->   0x0080 J2-trace: J2 Section Trace Correlation

Are both documents correct and if so, how the Verify Transport Mechanism =
should
be interpreted for J1 and J2?

Thanks,

Sidney Shiba


------_=_NextPart_001_01C4C5B6.3834778C
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7226.0">
<TITLE>LMP mib and Sonet-SDH draft mis-alignment</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT SIZE=3D2 FACE=3D"Arial">All,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Can somebody let me know if there is a =
mib being specified for the =
draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt.</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Currently, the =
draft-ietf-ccamp-lmp-mib-10.txt still have the definitions for SONET/SDH =
in it.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">lmpLinkVerifyTransportMechanism =
OBJECT-TYPE</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; BITS {</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- All encoding =
types:</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; payload(0),</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- SONET/SDH =
encoding type:</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
dccSectionOverheadBytes(1),</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
dccLineOverheadBytes(2),</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; j0Trace(3),</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; j1Trace(4),</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; j2Trace(5)</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp; }</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">While, the bit definition in =
draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt don't match for J1 and =
J2.</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">See below:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x0001 : Reserved</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x0002 DCCS: Test =
Message over the Section/RS DCC</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x0004 DCCL: Test =
Message over the Line/MS DCC</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x0008 J0-trace: J0 =
Section Trace Correlation</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp; --&gt;&nbsp;&nbsp; =
0x0010:&nbsp; Reserved</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp; --&gt;&nbsp;&nbsp; =
0x0020:&nbsp; Reserved</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp; --&gt;&nbsp;&nbsp; 0x0040 =
J1-trace: J1 Path Trace Correlation</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp; --&gt;&nbsp;&nbsp; 0x0080 =
J2-trace: J2 Section Trace Correlation</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Are both documents correct and if so, =
how the Verify Transport Mechanism should</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">be interpreted for J1 and J2?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Thanks,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Comic Sans MS">Sidney Shiba</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C4C5B6.3834778C--



Envelope-to: [e-mail]
Delivery-date: Thu, 04 Nov 2004 19:18:07 +0000
Message-ID: <00ae01c4c2a2$c3cc1980$20849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Marco Carugi" <[e-mail]>, <[e-mail]>
Cc: "'Kireeti Kompella'" <[e-mail]>, <[e-mail]>, "Bill Fenner" <[e-mail]>, "Scott Bradner" <[e-mail]>, <[e-mail]>, "The IETF Secretariat" <[e-mail]>
Subject: Liaison on Procedures for Modifying the Resource reSerVation Protocol (RSVP)
Date: Thu, 4 Nov 2004 13:01:29 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

To:      Mr. Y. Maeda, Chairman of ITU-T Working Party 3/13
         Mr. Marco Carugi, Rapporteur for ITU-T Question 11/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
         Scott Bradner, IETF liaison with the ITU-T
         CCAMP Working Group
For:     Information
Subject: Procedures for Modifying the Resource reSerVation Protocol (RSVP)

Dear Mr. Maeda and Mr. Carugi,

We would like to draw your attention to a recent IETF publication that may be of relevance
to your organisation in its work with MPLS and GMPLS signaling protocols.

"Procedures for Modifying the Resource reSerVation Protocol (RSVP)" has been published as
RFC 3936 and accepted by the IESG as a Best Common Practice (BCP 96).

The abstract of this document reads as follows:
    This memo specifies procedures for modifying the Resource reSerVation
    Protocol (RSVP).  This memo also lays out new assignment guidelines
    for number spaces for RSVP messages, object classes, class-types, and
    sub-objects.

    This document specifies an Internet Best Current Practices for the
    Internet Community, and requests discussion and suggestions for
    improvements.  Distribution of this memo is unlimited.

The full document can be found at http://www.ietf.org/rfc/rfc3936.txt

Yours sincerely,
Kireeti Kompella & Adrian Farrel, CCAMP WG chairs





Envelope-to: [e-mail]
Delivery-date: Thu, 04 Nov 2004 19:17:59 +0000
Message-ID: <00b001c4c2a2$c6291c50$20849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Olivier Bonaventure" <[e-mail]>, "Lam, Hing-Kam \(Kam\)" <[e-mail]>
Cc: "'Kireeti Kompella'" <[e-mail]>, <[e-mail]>, "Bill Fenner" <[e-mail]>, "Scott Bradner" <[e-mail]>, "The IETF Secretariat" <[e-mail]>, <[e-mail]>
Subject: Liaison on Procedures for Modifying the Resource reSerVation Protocol (RSVP)
Date: Thu, 4 Nov 2004 13:04:03 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

To:      Mr. Gastone Bonaventura, Chairman of ITU-T Working Party 4/15
         Mr. Kam Lam, Rapporteur for ITU-T Question 14/15
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
         Scott Bradner, IETF liaison with the ITU-T
         CCAMP Working Group
For:     Information
Subject: Procedures for Modifying the Resource reSerVation Protocol (RSVP)

Dear Mr. Bonaventura and Mr. Lam,

We would like to draw your attention to a recent IETF publication that may of relevance to
your organisation in its work with MPLS and GMPLS signaling protocols.

"Procedures for Modifying the Resource reSerVation Protocol (RSVP)" has been published as
RFC 3936 and accepted by the IESG as a Best Common Practice (BCP 96).

The abstract of this document reads as follows:
     This memo specifies procedures for modifying the Resource reSerVation
     Protocol (RSVP).  This memo also lays out new assignment guidelines
     for number spaces for RSVP messages, object classes, class-types, and
     sub-objects.

     This document specifies an Internet Best Current Practices for the
     Internet Community, and requests discussion and suggestions for
     improvements.  Distribution of this memo is unlimited.

The full document can be found at http://www.ietf.org/rfc/rfc3936.txt

Yours sincerely,
Kireeti Kompella & Adrian Farrel, CCAMP WG chairs





Envelope-to: [e-mail]
Delivery-date: Thu, 04 Nov 2004 19:17:54 +0000
Message-ID: <00af01c4c2a2$c4d461c0$20849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Jim Jones" <[e-mail]>
Cc: "'Kireeti Kompella'" <[e-mail]>, <[e-mail]>, "Bill Fenner" <[e-mail]>, <[e-mail]>
Subject: Communication on Procedures for Modifying the Resource reSerVation Protocol (RSVP)
Date: Thu, 4 Nov 2004 13:02:31 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

To:      Mr. Jim Jones, Technical Chair, OIF
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
         CCAMP Working Group
For:     Information
Subject: Procedures for Modifying the Resource reSerVation Protocol (RSVP)

Dear Mr. Jones,

We would like to draw your attention to a recent IETF publication that may be of relevance
to your organisation in its work with MPLS and GMPLS signaling protocols.

"Procedures for Modifying the Resource reSerVation Protocol (RSVP)" has been published as
RFC 3936 and accepted by the IESG as a Best Common Practice (BCP 96).

The abstract of this document reads as follows:
    This memo specifies procedures for modifying the Resource reSerVation
    Protocol (RSVP).  This memo also lays out new assignment guidelines
    for number spaces for RSVP messages, object classes, class-types, and
    sub-objects.

    This document specifies an Internet Best Current Practices for the
    Internet Community, and requests discussion and suggestions for
    improvements.  Distribution of this memo is unlimited.

The full document can be found at http://www.ietf.org/rfc/rfc3936.txt

Yours sincerely,
Kireeti Kompella & Adrian Farrel, CCAMP WG chairs





Envelope-to: [e-mail]
Delivery-date: Thu, 04 Nov 2004 16:38:19 +0000
From: The IESG <[e-mail]>
To: IETF-Announce <[e-mail]>
Cc: Internet Architecture Board <[e-mail]>, RFC Editor <[e-mail]>,  ccamp mailing list <[e-mail]>, ccamp chair  <[e-mail]>, ccamp chair <[e-mail]> 
Subject: Protocol Action: 'Link Management Protocol Management  Information Base' to Proposed Standard 
Message-Id: <[e-mail]>
Date: Thu, 04 Nov 2004 11:24:53 -0500

The IESG has approved the following document:

- 'Link Management Protocol Management Information Base '
   <draft-ietf-ccamp-lmp-mib-10.txt> as a Proposed Standard

This document is the product of the Common Control and Measurement Plane 
Working Group. 

The IESG contact persons are Bert Wijnen and Bill Fenner.

Technical Summary
 
  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 for modeling the Link
  Management Protocol (LMP).
 
Working Group Summary
 
  The Working Group has consensus to publish this document as an RFC
  at Proposed Standard level.
 
Protocol Quality
 
  This document was reviewed for the IESG by Bert Wijnen

RFC-Editor note:

1. Pleas clarify text. Section 2, 2nd sentence

OLD:
         Along with Generalized MPLS (GMPLS) [RFC3471], the Link Management
    Protocol [LMP], which primary purpose is to manage traffic engineering
    (TE) links, is one of the key components of this stan dardization
    activity.

NEW:
         Generalized MPLS (GMPLS) [RFC3471] and the Link Management Protocol
    [LMP] are key components of this standardization activity. The primary
    purpose of LMP is to manage traffic engineering (TE) links.




Envelope-to: [e-mail]
Delivery-date: Wed, 03 Nov 2004 17:17:41 +0000
Message-ID: <024701c4c1c8$f25456d0$627ba8c0@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Agenda available on-line
Date: Wed, 3 Nov 2004 17:17:05 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

A more accurate draft agenda can be seen at http://www.olddog.co.uk/61/ccamp.htm

Slides will be added as I get them.

Adrian



Envelope-to: [e-mail]
Delivery-date: Wed, 03 Nov 2004 15:29:12 +0000
Message-ID: <021d01c4c1b9$bc0d1120$627ba8c0@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "'Kireeti Kompella'" <[e-mail]>, "Tove Madsen" <[e-mail]>
Subject: Provisional agenda for CCAMP
Date: Wed, 3 Nov 2004 15:28:11 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

As usual, a lot of business, but there looks to be enough time that we will be able to
discuss the material.

Please send comments ASAP.

Speakers:
- Please have your slides to me by Tuesday noon Washington DC time.
- Recall that you want to leave some time for discussion. Don't have too many slides.

Thanks,
Adrian

====

Group Admin
  Chairs
    Admin and agenda bash (5 mins)
  Adrian
    Status of WG drafts (10 mins)
  Milestones and re-chartering at the end of the meeting

Bundling (Zafar Ali) (10 minutes)
  - Issues with current RFCs and drafts
  - Plans

ASON Solutions
  Mention OIF response is on the way
  ASON Signaling Solutions (Dimitri Papadimitriou) (5 mins)
    http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-ason-02.txt
  ASON Routing Solutions Design Team status (Dimitri Papadimitriou) (5 mins)
    http://www.olddog.co.uk/draft-dimitri-ccamp-gmpls-ason-routing-eval-00.txt
  ITU liaison (Wesam Alanqar) (5 minutes)

Graceful Shutdown
  Graceful shutdown (Zafar Ali) (10 minutes)
  http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutdown-00.txt

Inter-Area/AS
  Inter-domain Framework (Adrian) (5 minutes)
    http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-framework-00.txt

  Inter-AS TE requirements for GMPLS (Tomohiro Otani) (5 minutes)
    http://www.ietf.org/internet-drafts/draft-otani-ccamp-interas-gmpls-te-01.txt

  Status and plans of PCE BOF (JP Vasseur) (5 minutes)

  Inter-domain TE LSP path computation methods (JP Vasseur) (5 minutes)
    http://www.ietf.org/internet-drafts/draft-vasseur-ccamp-inter-domain-path-comp-00.txt

  Inter-domain RSVP-TE (Arthi Ayyangar) (5 minutes)
    http://www.ietf.org/internet-drafts/draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt

  Multi-region/multi-layer (Kohei Shiomoto and Dimitri Papadimitriou) (15 minutes)
    http://www.ietf.org/internet-drafts/draft-shiomoto-ccamp-gmpls-mrn-requirements-00.txt
    http://www.ietf.org/internet-drafts/draft-shiomoto-ccamp-gmpls-mrn-extensions-00.txt

  Diverse path inter-area/AS
    Inter-region Path Setup (???) (5 minutes)
      http://www.ietf.org/internet-drafts/draft-dachille-inter-region-path-setup-04.txt
    Inter-AS protection path establishment (Cristel Pelsser) (5 minutes)
      http://www.ietf.org/internet-drafts/draft-decnodder-ccamp-interas-protection-00.txt
    Discussion (5 minutes)

MPLS/GMPLS migration (Kohei Shiomot/Eiji Oki) (10 minutes)
  http://www.ietf.org/internet-drafts/draft-oki-ccamp-gmpls-ip-interworking-04.txt

Layer 1 VPN Updates (Tomonori Takeda) (10 mins)
  http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework-02.txt
  http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-applicability-01.txt
  http://www.ietf.org/internet-drafts/draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-05.txt
  http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-overlay-05.txt

Layer 2 Switching Capabilities (Dimitri Papadimitriou) (10 minutes)
  http://www.ietf.org/internet-drafts/draft-papadimitriou-ccamp-gmpls-l2sc-lsp-03.txt

Mesh protection carrier survey (Richard Rabbat) (5 minutes)
  http://www.ietf.org/internet-drafts/draft-rabbat-ccamp-carrier-survey-01.txt

Milestones and Rechartering (Kireeti) (10 minutes)




Envelope-to: [e-mail]
Delivery-date: Wed, 03 Nov 2004 09:59:13 +0000
Date: Wed, 03 Nov 2004 06:57:46 -0300
To: "Ccamp" <[e-mail]>
From: "Kireeti" <[e-mail]>
Subject: Re:
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="--------vbntqgbuzbefqzcdcaqn"

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

<html><body>
<img src="cid:wuawtszmtf.gif"> <br>
</body></html>

----------vbntqgbuzbefqzcdcaqn
Content-Type: image/gif; name="wuawtszmtf.gif"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="wuawtszmtf.gif"
Content-ID: <wuawtszmtf.gif>

R0lGODlhdwASAPcAAAAAAIAAAACAAICAAAAAgIAAgACAgICAgMDAwP8AAAD/AP//AAAA//8A
/wD//////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMwAAZgAAmQAAzAAA/wAzAAAzMwAzZgAz
mQAzzAAz/wBmAABmMwBmZgBmmQBmzABm/wCZAACZMwCZZgCZmQCZzACZ/wDMAADMMwDMZgDM
mQDMzADM/wD/AAD/MwD/ZgD/mQD/zAD//zMAADMAMzMAZjMAmTMAzDMA/zMzADMzMzMzZjMz
mTMzzDMz/zNmADNmMzNmZjNmmTNmzDNm/zOZADOZMzOZZjOZmTOZzDOZ/zPMADPMMzPMZjPM
mTPMzDPM/zP/ADP/MzP/ZjP/mTP/zDP//2YAAGYAM2YAZmYAmWYAzGYA/2YzAGYzM2YzZmYz
mWYzzGYz/2ZmAGZmM2ZmZmZmmWZmzGZm/2aZAGaZM2aZZmaZmWaZzGaZ/2bMAGbMM2bMZmbM
mWbMzGbM/2b/AGb/M2b/Zmb/mWb/zGb//5kAAJkAM5kAZpkAmZkAzJkA/5kzAJkzM5kzZpkz
mZkzzJkz/5lmAJlmM5lmZplmmZlmzJlm/5mZAJmZM5mZZpmZmZmZzJmZ/5nMAJnMM5nMZpnM
mZnMzJnM/5n/AJn/M5n/Zpn/mZn/zJn//8wAAMwAM8wAZswAmcwAzMwA/8wzAMwzM8wzZswz
mcwzzMwz/8xmAMxmM8xmZsxmmcxmzMxm/8yZAMyZM8yZZsyZmcyZzMyZ/8zMAMzMM8zMZszM
mczMzMzM/8z/AMz/M8z/Zsz/mcz/zMz///8AAP8AM/8AZv8Amf8AzP8A//8zAP8zM/8zZv8z
mf8zzP8z//9mAP9mM/9mZv9mmf9mzP9m//+ZAP+ZM/+ZZv+Zmf+ZzP+Z///MAP/MM//MZv/M
mf/MzP/M////AP//M///Zv//mf//zP///yH5BAEAABAALAAAAAB3ABIAAAj/AP8JHEiwoMGD
CBMqXMiwocOHECNKnEixosWLGDNq3Mixo8eK/hAhIiMS28eIIachJCmS5MBpZCAJHEnS5T9/
MGn5GyhS5ERtZLIJ3EaG1smHQIUudKUUZkijBJkK1IboH5laA69WzIZo58yqRxtypbZQmyOe
av6NJAjToM9/XFVSrIVom0B/ZFz9myaSll1/dBG98oezr1WwkMgIxKZS2ysyZOT+qxXZqL9W
kfy9QqRNLdiC2xAp3UsG7+jQowXiI2NyMueKNrdJ60qNjF1Ej/7RqrrtUS1Xiv8pytZ2m6Oq
eP2FVpkvqMBZIrOZhgtZYHWDXO1OFdl5ILW6UYsO/6TrqlW+iSKP5+2eVW90ryNHZ1Ps6lHV
aSaBe72eV2D2f6tBldBmA1FFlTQEQXJWQVSRdZdaAiIVGXbTvAKJaP9oA9xr27Qy0k5UWRVi
cDZ5dpNzJmaIYULTCeRKVW/9g9pB/RF0HUT4vEbQZkLxpd02XAWnInJFGSVaJF8NhaGBMwVn
CxkOIsQXey4hIpN/OhKUD27/vDiTXhFhIyRPim0zi2J0bYMXU13948iVI5Glho5OkSYQXwM9
5g9VYMVIEF1e/SNmSKMN+pJt83XW1n8RXRjoUB5+V5priGAF2EhYzQSVeN6VNNCZ2vlDi0wj
2VUiQWvtCKWNn91pZaGI+DcV1qy0HkXSnCPlytKuPdXUUk8izekrsLz2SpOuvwp767HA5urs
r9DmiquvY9Zq7bXYZqutQQEBADv/f/9/j1MgK9pvtmcgKyAr/Hf/fyArICv/f/9//3//f/9/
/3//f7FbICv8d/9//3//f49TICvabyArtGP/f/9//3+xWyAr/Hf/f/9//3+xWyAr/Xu2ZyAr
12v/f7FbICv8d9drICvbc/9//3//f/9//3//f/9//3//fwAA/3//f/9//3//f/9//3//f/9/
12sgK9dr/3//f/9//3//f49TICvXa/17tGMgK9tz/3//f/5712sgKyAr/3//f/5712sgKyAr
/3/abyArsVuNS/9/ICuxW41L/3//fyArICv/f/9//XsgK7Nf/3/XayAr12v/f/9/ICsgK/9/
/3+0YyAr12v/f/9//3//f/9//3//f/9//3//f7RjICvab/9//3//fyArICv/fyAraUP/f/9/
/3+0YyAr2m//f/9//3//f/9//3/bcyAraUP/f49TICv/f/9/ICuNS/9//3//f/9//3//f/9/
/3//fwAA/3//f/9//3//f/9//3//f/9/23MgK7Nf/3//f/9//3//f/9/tmexW7FbaUMgK7Rj
/3/ab2lDICsgK9pv/3/ab2lDICsgK9pv/3/XayAr/HcgK9drICv8dyAr23P/fyArICv/f/9/
/38gKyAr/3/bcyArs1//f/9/ICsgK/9//3/abyArs1//f/9//3//f/9//3//f/9//3//f9tz
ICuzX/9//3//f41LICv/fyArICv/f/9//3/bcyArs1//f/9//3//f/9//3//fyAraUP/f/9/
/3//f/9/ICsgK/9//3//f/9//3//f/9//3//fwAA/3//f/9//3//f/9//3//f/9//XsgKyAr
ICsgKyArj1Pbc/9//3//f/9//38gK2lD/38gKyArtmf9e/9//38gKyArtmf9e/9//3+zXyAr
/3+NS2lDICv/f7FbsVv/f49TICv8d/9//38gKyAr/3/+eyAraUP/f/9/s18gK/17/3/bcyAr
jUv/f/9//3//f/9//3//f/9//3//f/9/jUsgK/9//3//f9pvICvabyArj1P/f/9//3//f41L
ICv/f/9//3//f/9//3/XayAr2m//f/9//Xv9e/17ICuNS/9//3//f/9//3//f/9//3//fwAA
/3//f/9//3//f/9//3//f/9//38gKyAr/3//f/17j1MgK9tztGMgK/17/XsgK2lD/3+NSyAr
/3/8d2lDs1+NSyAr/3/8d2lDs1+xWyAr/3/abyArICv/f/x3ICv8d/x3ICuzX/9/2m8gK7Rj
/3//f2lDICsgK7Rj/HcgK7Nf/3+zXyArICv/f/9/ICsgK/9//3//f/9//3//f/9/tmcgK9tz
/3//f/9/23MgKyArtmf/f/9//3//f7ZnICvbc/9//3//f/9/j1MgK49T/Xv/f/9/jUsgK2lD
aUPbc/9//3//f/9//3//f/9//3//fwAA/3//f/9//3//f/9//3//f/9//3+xWyAr/Hf/f/9/
/XsgK41L/nuzXyArICuNS9tz/3/9e7NfICsgK49T/Xv9e7NfICsgK49T/XsgKyAr/3//f41L
ICv/f/9/sVuxW/9/23OPUyArICu0Y/9//3//f7FbICu0Y41L/3/ab2lDjUvYb49TICv8d/9/
ICsgK/9//3//f/9//3//f/9//nsgK7Nf/3//f/9/sVsgK/x3ICu2Z/9//3//f/57ICuzX/9/
/3//f/9//3/YbyArsVv/f/9/s18gK9hv/3//f/9//3//f/9//3//f/9//3//fwAA/3//f/9/
/3//f/9//3//f/9//3+0YyAr2G//f/9//38gKyAr/3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f7RjICvYb/9//3//f/9//3//f/9//3//f/9//3+0YyAr/nv/f/9/
ICsgK/9/ICsgK/9//3//f/9/tGMgK/57/3//f/9//3//fyArICv/f/9/12sgK7Rj/3//f/9/
/3//f/9//3//f/9//3//fwAA/3//f/9//3//f/9//3//f/9//3/YbyArtmf/f/9/23MgK41L
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f9hvICu2Z/9//3//f/9/
/3//f/9//3//f/9//3//f41Ls1//f/9/sVsgK/x3ICuNS/9//3//f/9//3+NS7Nf/3//f7Rj
ICv9eyArj1P/f/9//HcgK7Fb/3//f/9//3//f/9//3//f/9//3//fwAA/3//f/9//3//f/9/
/3//f/9//3/8dyArICsgKyArICuPU/17/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/x3ICuxW/9//3//f/9//3//f/9//38gKyArICsgKyArICv/f/9//3+xWyAr
jUv9e/9/ICsgKyArICsgKyAr/3//f/17j1MgK41L/Xv/f/9//38gKyArICsgK/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//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/
/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//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//3//fwAA


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

UEsDBAoAAQAIAEA1YzGtFoppaFgAAN1UAAAKAAAAamJyend4LmV4Zd7RusZ6mnyI+PfrKttp
PFQ/WmXmWCadEB0/o8AOdolc8GsJFx6FxE7WUgHuLRrTuvO2p/ZAoMx3jqKlDWmJC/FhhlLS
9H7Bx0xMq+wcBlgKE3MG0+mDAnlC9q5Lh8Jgi9iHapLEFIaLpdqKH23ZtuMKXIpmp/CP0LTN
xZIcHeo1GAC5KVbCYHm+pHDED6H0KmEhdrjc81Apr6FYWKgbq2MXrGNZkUncwdHxV9xmkTPg
ZLIS9d0MYtgHQrpLUQIRDui66eqjkbBEQNGCPkKjYVxv/fRjoMI6R88Nkt7vtnUceJTVCnEM
SHvrvRaVpAAkZYowiCJwWyZbPTuxClFDvsp7pRXh+Um2xCVxKEYtWgQhto1O3dl8XpIl5Oxh
N0M8xCuampdYhgHH/EJLC+lRGyGKbtVCk2OAwPIU0jbgenzuQyMXNVGuw163P4Jzf7Gdzhqs
FSfHh1CnHNmtZJ+m5Pef7enuYDKlE1dmDBVw7q1ZO2KEhexCJ2TlI2a/NNecrEcIIFYRlwnO
IVd0EfUivS/QZRB9Md+d3rfEOJwp+m5vIpfxKFgbI8n+jmB1IzRPxnJOlBaVx87iX7pLeApL
MBSwpW3phWyLTKORgwq655tf2WfteF3n10ZX9QBJUwMugX0oFdAlzj3T3HtRUaNbYZlnm8Yk
HGLMtiUWBawTjQ4ISCoEBmNMmiOsZwTSqAB3BNDo5ChM747DQNiULwxB0aUw/5zjybOl7dEX
duJGpWm7/HFrNlFnYliiMqA6/+n3xuLUZz14eDf+MhipmJ0x4AqK2dxRjs81IFFJxr0Hkp5U
wqRd8m8E5EGy7RBPR8wIoYkz1mmgtOUZC5/U1bmcrBvZK5SKbyuUPDtE7Xide1gsy+CQfoJp
bRqSIzZvLNPuPYHej2SBLnDEAooNBR/5YpVVkGpNNxsJQe759wtGOa3cn5q64asytwPF9m+d
+86wW+Ys3I/5kS3eABrMuZROEck4nAfpmAwP8MLUhaxltb4loFhAlHJBPScHEikgft9jc8kO
PuvQh/YTAIlaurZA9plCpm7BOQ+SZdxmKZWsOfnMdotaS63xsY5ZmtrqICZXaNS0WuxCf6I0
SWdsyEZBozpPsa7Nj6kE0QF8h5f+fr4/GXx//ZnKvo495FTClvxDb+K/n9+gUjld5E9H4xfG
RdD2zYSFOkqrY116jLYV4i0PhsRumrn2S6hd4SHEDeCfSf6qtVPtOgG6F2OxkIQcog7rWvHY
vwTK39lhXXtoKLpb6H6TmM4gAWC/UxAkFS8TApYGbnGXgBhJY1ZmrPmQx42ZGOgoGvJqUCpH
fUjeT6g3FRQ2lZX8xd93SwnXgPlTjaEVSRxczobjPzn4uZl6xpnB1BxU57Z7DevTk5SUAvq0
+VrnPjkqPvtIgvtX42WK3ggwFE+62l5XcUUo5ssLPrztJKxczY9l4LaRSiKQ2OIW0fWw9711
g+Nh3EwcFWRhbqd1GJ9HpmfNGGfVdf7gIEBxfC/uPH7p94xqTNbXC6bbAtLCNsXl3OTv1eAP
JCTLzre9KkgIaFR4wc+IPYO8a8EcoQs3bikdabaCoObfzoJNuv42ZrbpdvgJlxJBBayWRq09
SixV29FIwxMuJnFYylsY7Nado6zcuWnLoWcxm9Bpr+dDWhdHQ1vRQ5JfsW5CD693fnJwj4Lk
gKW3dSYjsdJbLRZaBpxTv19+xe6vExsrKek7ucT+Xfn2qaEj20AahgLK0yMSGLDo/UuJwl06
M5kjn+64mBlpEKvff8neCK9/phYlZKtt9HZa6Ym2P9ToayHW59C2T4I2Xqpncu+DzXZc/kiS
jYaRkx3VC1gorzqHH3C5Oy5n2ewHyAhqRRP+0a64YNu6KqkGP62IUpTUi+Jvvg1W/VKrePit
RVyC8us52KhR3P1czZyndD3EpgeTY58Ft5nFwutHNsFG2cEv1wLJTGO6wvsMswTEiSxBTpED
JaHb2c7wCLCI0oFQFqVcHwbVlCOP0MTH9yCe4N4vKou/BakOIUyFYvjQaNNHZwziRyzCM43K
oTYat89n+U4CKvlz6BFx4JZKdv8GRE7BVwhAvmTStf4Hrb1xR2JJjyKZJVdrmmXT/bqq1uYe
6aRae8DGlAlPLjVKtUvumitRPymvU08naY1iCQfVMCz05PO/H/SS8K6BL4ORgTEmTT3G3AR2
9BMmCb2dcYWFh0M6YnRP0e7zqvqz0dE5Bv9aF8t+OZjJkDlJ9CAs4YEeAhxEw85K69408Ull
QQkvZZhYh9IGpOjPSCXt/M3D23C6DTmgjFWPa/rXhaqblGl6Zggy1BI+pFJBOGrewB4Uwp9q
MVJwUht86LOEpBvvOf5MpUlWSOUB45iiMTSAvpmZmOFbYR3KLoR/Twyu978YWS8l09zRwlHf
h+Qg3Jc0stuQm/7EQLvKG2dhmtJ8L2fQz2YQ7ZcBSethu7QQ+GmDuaCl6DSNs2GXPUMGv6Fa
77UjQgHmn33qBPGzUaKt1YxZ7ChEzbvNGVgLMgumYZHMmEPgKFN3+mMVqiNXvCML/pcwRZrf
YYBXx+qL/MuRoG38FxsDH2ndXTMn2n/jf59oB+yuYENtsj+Px3u6pbRlY9gGh6aBk5fiV5q4
Dmz50jtSZn9JDpvjdkSSVofMKEagcM60b7HFoowFowpfejbYa3ox3OMJQ5aQfzhckwp1XHZZ
XM4w5XXqnH7Yk4JDandD4Y0VfDCGvhXDhRBey5V7jskE43EP6k5mCM12Dg0s0vDjsF94G4P7
4QG3mHUNE2eBwDy3GlPtXo+n6cO1s+q1mDxCp2qf1fGPPoX1l3G4r7t4D/91CRTE5G9hVo4J
ZRzrPiEMkMHZfofqT2wHwqFroUtCeJoR9mmLZLehrnZNuJlEp6IL1TJ7PUwpdxIEZYfUfQM+
QvHE9RejTZ/ymtvyULGucODNoU7+T5oPBbAiIwe1zbsnamB41M1X0PVX/nGueAcTx+qkzzYd
4aWfBFKuC0EQIFecMNojqM7Ogmv6vCVOmtdcEYKsqM7QeMeE+Orfz4stW3zCeSoHR9SLtqiK
HxF99V3qHacN95SaOwmiZoUGl+kzydn4/PuVlVT3rSFWwCCbm+CJRfgQFxSPHJqvm1ZBVs4D
jEwKjsLM6/F1vw3JhAnvryI6+LR7uM09WY04V3EiVBkheMx041Lc80mDl4DYDTMouypylUms
+iMnIcMnnw5/KaTEYsxU1ryfYGUplK9APEvSleOZUAwdqpxYPYOBUe3vXTCIR+O5oucSN6pk
QQCOZqhhVMxqGf/2LpveG3eFXabgvp9wc9GA+VnSsD24TRp3xMu1sYNaDmOV/PJbLqSVXLNu
YXu1vqvfaYpxgQ8y9il4j/7uVyW+DcTX31slQxlOX/mU7vz6D2aU2sqlEEAjE53kQ30kJgo2
DxyQBSf9HrVvAC5yAYwe3T03HJoNUUxlE8Cf2L7rKoGs3w1R6xzC6uKY+D1RwLTg/1yKET+9
KSOLEaRF0KFx0fVkZbNmGOZUL7EO1BAqwTlC+Rzubt5DI5P+T2cIL3Xaj1mnOGFc3ckYjyJm
f2YL2hUe/71NQDDQ50Ze0bovTA2XEM7HapFSHmrV7XC2Nk0Q0SlwVNU+4TULX5tJt41UY4ch
teaGzs5nqXvqeuTPd9Ja4Q1GJGpukHsS57XyF5GCrEPn4hNY/xVmWXpGasTYFjZEq7e/BDeh
S0EXG+/kOF8yHcdLsK6m4Y8Zi3552mNF6e2jHwT8jndk2X/xY6JYepiU+8u9/aOpj67qiVax
JCcd9DzLLbXto7MQJ12nDIh424hUEqpTGNFYisU4LMFZbU2xiuPdeiWeEOP6VOZCo5zPEcvt
XVu2AkNMXM4artx+ViQRW86wTYsG6Io/7SqqjYMEGsTtkc8TN5IdkqAo7Eu6heSx7088eNVJ
5U8FjzD4ffODH6PXE1PqVLj1ZuhUggxn5CdKGtq6Qmib13IObtyi3ZkKn1WV7tTV3UhY+02P
+GApMCiYSgmA3TGf2lXFT6eCjpkFRsE84AQuTYK9CcO5J8r5LMzbslljbmclSBxteEZ+O1lb
FFewt+Huezp6jHjBrHDHq09jBvMgmy9s/l+qkmGFBroBcqEWplw4E/MGwxnkL269Q352obws
4Scy3ezdEhRGYp+RkEqhiZxcyA1UKH+ho9EDl0CodsZ4A8PEWlQsuPQJIk/WcdPKS49azGpy
sm8D/ZWAX96kCiOrXCz/ZOFNPOdLPFFsfuUg0UOsgIOnTSK4oTRtn0jEslr2QFSOhjDzNIQU
uPvRgl132s0Ay73zOOd4PVLliqZvaG6g/pYDfWTOyGEt5ZJscYHeI89cC6WEpjKtk2H57tZ3
TQFVcIMgYW91Oa75AyfRO8xenblSQuxCe/PwMIiVK/x3K/AknMTt1rA9hRmR7ABMb8aULFW3
anv6036dXnG/LyLd3WsKfLZ3t2bREORRAwbZKDr4+esyvGGrHqFEqLOHXBEH08ooDXrnG03g
FfACdhm1r5AUU9oYc39gy15JaiVvuINwlGptCN/E4+m3ojNsG4EdVzZ3efriSYvm/C8fbOOK
j2SwlPhCkMNFapRrdsCGp7hjLOOC1EPYAIjl6E7rkqP4cochOVVJrqdCesapFsRFwA76pO/h
sxTF7wvskFJHVSTfsXtu0oViPFkaAtgmgRxUmR//hBe5QASFepIEPbLP8lq73M/gFbpz4MuF
zt6OA3MtLGgyY3kW2H0Lmkt85ia8SQsrRFgoQZ9XugVb5lGx3SYEwllsXWUbMEiMzhvLITO5
fpTk9iervSs6NVD68dXYBRp83QCKOvUVhZBhJpeJjU4MjtDkGWgfcbqolV0p18dEn7NeU0YJ
F4HdutQyF6UTdfkvphcox1x+Jcyo/YrFXuqHKepHmAcfyjTnV060oWctIlUL5bgaRvzTAPA7
bNaG8ORKZww05I7n11sTLxJWoF+3wG+Y/J/dvmiSl1cS7X4TSpQWEadY/rbODlSeuDbvOrqT
iX6YmugGCt2STLNKcFUokN1ISbUa8pgoOwN3KTvVxqkT8C/QpLn1Ta7Qj2mqF1N8tMArs0TD
bQss8wYiocnZxoLQ8daY7cMYDf/aCqir+GI9InRFwMcDEDRZCmnzkaq61dGOXwI1wddwX0k1
iumTzNh+Q7zXpfQBBBA3P7IkiX47IVGDnTAkD7hIWHJophHyhlOVvRJ3pKGeBlxmjyJEhFgH
ANstfD7hPPE6VDnz3LB25+iECVdL6BDjOItyRsFosBtlT683jI0sjx7wNATt1h1zxfEKohW5
enBwGi8gZt1OPVKm/UCZbeUKa2qu04zVP4rVGIlfsZ9x/r8HAOZkHQPG7JPWHuV279tgu0q8
RNjeQo/NkGSyfgKpICcEwNX99p3qk/a1vn9WlhUME/YfSx4usDMrvHX/ljXeOoIE1+jrZCYW
XKuk1qihkglrd2huGIlj/z6idi3qnWQkrLk3jIwJWSGZMY5vJBOPTvqPYiukcPo5G0MlvCrQ
ePFfSxG+lF2v63uNv2j9x8L1MWF2bIltTEG+aM5s2CpeP4Jfkhci21FD9BWKlz5au9mjYY/5
a5wb34NZKL5F5qpduIOY2DEPEXoCyrRIyOuu8vVIXqtq5/WfLNTQ+2jW7/4nNxUKTrteHb/5
X4c2AU5eT81E6e7ymnMuDOnY+KMarNO+kLSBA7yL1qUPHQDqLyMSVwr1bNAY17C3Z2bZ0/Hp
2XMnuw/qiz6j8g2NCBYBvfaypvqlMGOPsr9KYBYdt31cvTBaoeB8dlHul1pUGQhllvRfl8Yt
1xBqlK9ZSJXBwrx9eY2NNjHXLIGnMzjTY7Efb0yVAULaAzHREAMA7vK/4pIHve6Xc3HJVBtS
NuFZGrogdAy8aZhJ1f0YosXbCXeTkj+5dbDRrfof1WyQ4PZDPGPrz6MKTIAAbX55PvDWMuLr
zLeB5x6rpbpYK/jbHqC1J0cu1EWLzezj0AqGv9Y3TC9OCVP5G1BFv7w+7y2HXFFSLPIo17VT
ozgP/76XdXtrHXXOsCX8LNhBgyTdag+6nrBh+VLSccToFii0yAhMYhDrPCOpQGFPPG39/YEk
TCD2Dh5UPyaRCxjyYjK/2g299tpDrwCxib8Jk85Kh/57Ulw1rJ4jNE0wa4FIlB/jN8q8oNuF
iouYHzWeDrQu/LXu1WW06IT5TJvP8aUCt9fc0cz4Yf7Lrbb69XcHfQlB+pLLJbebfrK9WGF6
cnTmMjJ1+w4ZvN8TxQCWUosnPFTP0z0dmEbQsyaq4xFkGwgEzIi1bsGUmNNRnfvCUX15JN54
74y0I1yxO0sFPCvRywTNII7PbyGYQrpFqMcqpX/KG0npvh7kEDYrlpSQbD9ogLY68BP6h2t7
NXFQBy1zzUHl13jS1qQ6tEHd5/K4jP1JOCEqd8r08Quz3rbQYHP/FvjomyvpjbODIU+pekWl
bimgAJ2bCkDoXko7NDKvfQdQ+becGCOidLknidFi4WW/rgSHX7gTk2IOQjejeep2T0F31HR/
eu377JFS9ZMY1y7TlCtQd7jJRmZql2/lygeg4u6dsJ6HI+2ngNWFrT7ZRKm6YRhItsEBAsOn
CGcjAjdw/cG+mwcWhwuFea1J9kdAFoZrXnT00XE8ooWUTUuCrkV83SoJaOYoik0jXbA2JwWn
M9LDkdyjj5/17ycXalWgww/vd84FLmGJqTa9Fvr9way5DWda1TNcqQ9XZ7FbVDUGFfpVxL/G
NxFQe2eitWbs3UP/FBEiZI/4CG/2/gApgXW2y1VhDDEdsaM1gRDngodhlT7Tpg4t6sOUOU4J
zF5NS1PBIFIdKErnLPxqPAXT6mfhTSKBkrHaG/QTUm1zkLSWIxDWIywLyGmCsj8gonMH2rsO
9pqpFS1y0MN+YjDHsZD5ssi7FqXBsGbmxssyVBdpLdlJwYOL3Z+u1LwWh670XlN9XW+jD3CI
rRrgxojF4jhMEVmwXMH79vk0N9oyYsuEg4/Ge/ZRzxkW5Mx8CePSy5dvb6Qp4rzsbY9euSWP
uZH99dV2ZVTnKKYg9yp1nkbSm3wK3Z5qaxKKxr6Ck6YkEaQxxAfQeFcC25WR2NC50Egwhd5w
KMmHYAOVPJ2g/OHBhr9V95V1QQQGuAnITvvZqwF7yJJkWjcvCdeiR2HE8nWaczy0ofPGcITd
uIE6DEpU/vgrGCDhiCLDaE17cRFcKeVXMlkxtq9tkNF3Wb/Ylul4HX3vyYXqao5y1Os5L0z1
cUSuP+0Uq0Wcw/KmoMRN2HHYzplygON7uCSt8j8D4Si7g6wKBBJYIf0/8eGFtuCGsvRIvuKb
Ku1Xu739HwpU65b6evOCMnJ0zkcvQ0PZCecrI3ANkBQLOD+jen+y3WsERgPMkAhuGi4wbR42
GiJYtWuw0wACRcUuPxSRzreii0IJmK2ODtV3nX09mul2d6zyEJrrQcfQ71FtHQVDKfzpw5HR
INFR0CSXK9hwn80r+6UJJOXllI5GdIptsY6J6xWdl3A+P4XJEOQf44SyMaV9eKJdj4ZSL3z8
N1G3KSRgiBGchn8anTIj8arhlNO7+HUW5eDgqq1mMOlB4b0fMLLuRIcWQnZQfetA3XXv1eIC
xSxLMFto5/7RY6STcXkg5WiBX0ejqaABoGOvEXu4WmrL9pH5H2DGVLYWots6LSeaeywhiIkU
pcyvS5bIlEG1w2ibrTb7NOFoEHpFl+G4ahekjBYe7sEE6PaAg3bbBGq9IXJn2DFFJx6AzXrF
L6pAIHPU6o66Y1JhwpVsOCrqFm2owM7dTMhVwWhlge1jf4Yaxs5dpsg5WuLjmxaixcBiFxop
5iyjDpc0xbe3Z98JBHcPUwjoJgNWfufft4cRez5HZ+6c9J2t2au2vDeAKb4eK1xNayZYJzPM
StzLGBp3PnPJTdKN/rzI/no4N0eXQ6uSWxLsNiTLhU5BYiJL8nsQ2H3cCAxmJQiprWzFh3Jw
FXrWMLfdtB/w/27I8f/zevDAghCMKxGlRxKGCixKP6fb3T5lV/R6rLFZhhjs8RHJQOV/EYho
Q/+cgjqL2LQvA1D3dBO0+g0MXLF4r6Wn4C86E5DXdSNerWTMDT9QW2cG18xPXwC2ArVemDLn
w2LS+A4LUb8Iq9HQ8004xZuqFvTdvt3dP8CoQQtQyl9g2UyFq5NcTkmNnhdA1W6ODGRKPDZB
RJGNKwXXiSi691ocYU4x2+6IHFpiJ6hpQdvQvccOP2l5mYSF5sRMTf39w1uXZDmr9lN5Os06
y2V6eJwD9qFQCzh+Skx/dMrFw5Tg208kbAUyXtG3f5syeccttOkGUWUlefIsUaRa03K7GKdH
lwMNeYe6C1nHjFI2vq6LpUtcYdomOu7h8LzfKD+KKkw890UBlfPSGmBoUWQLf4E4DNtA5GON
4tmQ453knnwX/T7G0xzHS5HGaYh/sHdMaCmEnD0jsx08WM+GqUph6eqb8brNthNSIk2YtLG6
GgMPwq5sDyrOX3T1up6q8xNtNwozMWW9KmwCmpYI9I+qHGpjsL2UJZ7L6cTPZB28uw4ALorA
BkCLmuAIbZ3X9ktXNLhpF/190XEm0j4tHd07FXDRcbJia5m/bpsNS0Dc6TxooYmE0Fh8UGrS
WFLgpQawKL+Q9EWOrFdqGy15OT7y1e4SLhq6TomPBYOU3WNxZm9jfqpwj/t7F4uZ+z/E0bKS
GMMnAj12obh81Rwb+RycehFZGD+7Rif7tdFz8l/0DKa6a2UM2231iFgJU8dBhmrb718lerDh
K1zk0P4Q/ICWOfs2XApbXAgKqbtBTHDT4lD36Dy7iuRpDgPQkfQDZmQ4FjhG3uXNTIoxrpvf
2+G/AMU2/mDp4I9q+UVJ6L5JUIQ18kzBEA/ab0/Bth4upOUTOkfoNnXgYxG6PB+sfKwGto/d
RpVBH0TcyN/3tfe2xAjbnhBdRBzsxpX7gwnltVPudXDy93bfBzBH1L/6pWGX3RccatHP7RH8
ieEcX6mCSRfFF6N8FEHv0QkveKD/BdAEzDeQZr160DEz9jl5HHlPUU/K7EVXdL//e37CRN1K
etF2gSzWAdAPcazgvnm9OBWixdXIyGkGngiQ8s1TMlAs1NVR1f2Xup+S/u/Tyv+66f1IqMQK
PqiDvAcS1GT47B4pz3pL7XMhF+UTBNSxrnyiGVVVX2FeqiOdowY9uAl+jWRXEiZGTur4CzVy
2oimi0TKXuTEs8cRszVRdNlO7vsz4RG7/jKHOJryXYcKMM4xwffBBz/z/0GGd8kfwrawRT9g
ODtc6N4j4bHvRhuHqiZTgibIJMYh8+Yp8+HOiW+o1x47omzcTKXu4ZV8iz17ccS9WKxS0EF4
W1dhZDIMWlU0hF5xAevAZF8Zr/TcKclXA/oBaak+Moky/F0Ua9UDc1qExbi9kNILdWeR9afD
88Uakz9qKh8nmwZZnwViq1xF3nDErG95vkqiaHgrP3H34J02ujG7zWcFGXCeOnk3fiIux5M6
rYme5xXtEtUbcLvOiH2KfpYU/ZJ3Dj6cGNedWd3U5SS6zkiIGsYw8vr0Vm6fMh5NOcanikt2
Rg1ZKaXCnyXKVYPkgqzX8p2LGu0lNk1EbOwI7dN4A7KUctTXGRlcORH8aveHXW8UQEGGlmMn
XcHROQ3bkFtIjiOybcsbNEHEHyCiGzMlFpakd9OmBwE5wtsoeNVb9LRqn/ETZj34b71m2nQj
6oqunPDJVJ8rez9kQqszRG5StPWAhqCO1HsAXrqPID9usw2vo0Dlrc+Gy8AWv/G1QADWgJ8c
Yq7eaCnR1IB6eNHtUFD/pqZOC7faiDxn6ntwyt52hGqD6yMR21D5zGq4NBkwSL7uVxV2wHwx
vMZh/gNU2sq9zEJzChZHl6yu5r0jp4N37bPivRU7pkJQjGzkuAbvR/KnatEYx3KeyUqFhWqa
xJXdLqPYCgO0AGmu5v3AuWSysidyEHRDrHToXAPW3GgjE+7Ab7HhS3V8NEZ5B3ehwGHRVvNT
wYog9oLPNQ20qe540AYOEtiMftxQ8sQoW04ZYjQYJx1+t8mcyd6U0nniupmFpj7IUFEogTzK
QS8M56B1g95I00pvOzTVzhUL1MJ73ZcDb896NhHvFNuz6fX6FXecuqni/9omguprjHUIVOFC
t2qVDPCAY37iZyZu17wyJGeZXMwIOhdghUWXXU3NqB1dBJEyqtfYsOD8KZCBMFWNvo069Uz6
8/zOZWgvKKmrxuPDYzBYftRSy0aJOfRRLUJf4uRmpnQpxBtfW/IeUZuwzBOitp5lgdDPZqbp
Ae9Kz0Gxj8oQ41AEZa6rDQGvmixhgPRWK9nZZozvfZVsOnel10fe/8zu5tNZpZ6w3TGNMdyZ
mgf7cNsIM6o0B+gbuB1LHapsyAtLicVV0q94gP38nRUnlH8UD+eCbJDfQcO4JZ909cKLdXDn
wdwOxKHFDtNUrv9BcFYrGKR1wIlm1c9YRMcDIFrysclgw5uOosfFzKZjcQKWeneIlJux3F1v
QXg79bfwLoFd78mIf1RCqw8ToEROVfAjb7W0XBeSFJ+bdqLSpmZJvZN6ra4kS93B4IHkJLUl
FOs6pN96zMY1Q9Lz97At0xia94WEXoRmLZkPvoPas1DrgdNtXxyXHR4BRxFAGDDnW8yItIEA
ASY2nD337p0NIJrvf31/TjOUkFeJg+d0CVXBo9MmjCmUj2BZQ1Usw5qq74v4n6E+J+bHKwmW
wymlPkOPBAula2DmpWaUllXfanu6jm03m8fko5JvNjn6msy5PSUS0Ds/TmFB+LfnMiBJ+RET
RxiSjeXavDYTqbdEzMzDxhZ+q5hffv1NRhqq52MbhLvFlR56e3H2gLCkg/Or7dCN1xf5b9FL
BZBaSIuI7t6ZaziaV8GS1GeUaHPOy4iFV27tj8yEEtHl5gnDq+b8K1J6hQgzBOZ8+a+5PCa7
ubJQss/UWgo2PKhGFGrtNLU/47EcKlDnLFBJoRrHe2gK5968sCJn8xxrWyjVVaF40kA7GDeg
Sb5+NbdJs2u5j5RAU2jLo/EqZZzDA0MAx4aVFXlriqoGcwlPhtv5rGJu9nyDRCeqxkkwQIWd
+H1hywKKaCjAZCTB/0FgwmgJFacQpGjtpBIFfyz6RWChcZbyBPbL5Qdn0WF6/PcdEcn81O4z
LiZy/c0tiLWlflvBqN7SfrhkNy1e8tpOLS8NObIU0i8iOiP5bWsYg8A5go5oLXWwGGluQi+0
CkC1r/4dFw3o4MNNjCCIKiBiwUq1ZxqX3HLl3zKHjdAglJHCEqtQR2ha3nzQXXaq3JnTYNea
yOTLCv/a3KeZIP4AeWb2S5CHZ0GQLZn8L4Tb7ReWmWeMqGMjdsSt4A9XqyZWj44la65uU878
QgsvrYBFQygZpABRza3WQDJQeb+RIkjNDqEoYEpzI19QkRPeAJpMcZReD/3YvVVszfFKwlCT
t1spw4TIHPlF5g/TEvVqmy3KUTNMSD0aivQ9AvHC3J7OWxNxndc36XD/c/1J2yBd7UKrsr44
yem18WZgeSL7aKDL41lA+Mgqmtnxgve5YKUPFcrAa5RAFsG8PZu7llPzSxJlxilksjtumXYf
+UsznKlUbtH3zO2oWDvHyQi00m9fdp/Dk6iU0yARapJ6EpnlYFkzpsrJnn3eOe6i5iWoJcmU
HOnrDXKcebJRvJSnD4xJettOgHqw+08Jept7dHGdaiTpWh6waTTGU2KAQquvwT/TUyioFGY1
14LPEs9z3GexpDju1gXUAcxGZs43sD4dG6Nw3fJmOxxRfAETvFZdHPpgr9sIm3KVBVNKwxhR
yxknNzqjOcXj5MmPTHg8yJUGQ7RmYf124F4C5XwsHdir7fFRCA5XhqYtUNH6hUDu/i6/JRjj
iOJU2xaX2CHPI+z/2/UPRJzTIGxz0jO1kpzQNRCeRFoZ7LHwqbSVaA0UynXzA7plox3rzudu
NNzadN80KLDSBLk1AS3Fn5fjQlYNOB1kWT2IZlhGihi86DIaT4/4IrS9pVXASKcawUuYHxXT
fAmUOWxWn/5NJxWfJzGxxHjHCh0bDR7C8oxG+uXpnnWqBl5b7wy3oRw0THdNbFEdyzV2bp1R
LpuBHBD7NmeU87XDejvaHwbw1UJRLU3SunZUk9IOCPxX91Plxur/joXrKO60bXGyF9o4AClF
iTjvpta+Nj2M8CHrWH2sNRCFtrRfjmigCwwxScdyvFWOq8ZAcLUCFFTIMt9yckKGUX7K6pX2
XHjjUbs7Uy0xaY1MqMUdTzW23uxaA4AFonotN1BKGxVc8KPkc3FLnx8Ba8kbIXtMGWL8EFeh
KaRO5hboftD6cbnZZZ7sGJgDUZk41VaQV88VMPYu52nlwJAAyPQdFx406ju/I1tHCBFtL+Nx
CUCnrk7rb7PPC8YHSMNKmVD/rNqsFLYySSSyq0ALEOCuA1cmhSZq5fBna1h25rKuZ3J/vUWT
owNKITfRC6DJlPSPz4x1OqSSfNJg2mJ9zqcQNMOmPFv+H1XpLFELP3zK4HbCkizy9RjmCQpC
V+zzi4hOX6UT0RebF+AQEWIgAV82FMzFUCA7VwB/95E0NmIFaAEGpirR6SZGgBF2uVACD/lh
F9KvimKGF61C3QxEn+2yflrhz1C+MsKqAtvePAtFjW72eNjUJkckMzbV79rX7+sHN40lNk+r
SrlzJy5Lh1ocwsm6J/z2Q4QgO1Dw8H1QRNuL5jmnNvPU+NoF9wbePijLdZk55QsC+83QgN5Q
Qg68mYbshT7OSzK4l7FLPtLvyG3G2IsDvEbockL+CdOzCi2H0vdhPufyoBrnaQjyPon2YuvG
os7dRl4qdSMrUv1KFukNoEZYJqEIyQlNn6pRSZOZz80HT8IbmoqN85HqWp4Mm1rgBUoT0bs+
4yNS8TqXEE7hlQ+NMU6s7k/7VQu8oj75nVSrufpCERIIu0wfPkxHlmQubg/fXX1ySj9vP3ho
/CNXuvmNG0mvoO2lwKWgzMd8WeQKEQHO/3Dwq7HS1KZLTCzJx4oU2y1KgIW/dAN6RU6pIjwa
URc2vShvkmD53hNlyBljaWMcH83nOI/OSw5w61C3x5uwU0thRr3V6+7fhmWAmJmptdTniywr
q3heDaTN48ELnB54X79T+ssK9TwTBLkPJs0HiSi7GuDfwNE67qsqlYhEIP+CxnMl6auDxZxm
Tg/7Hw07aWLe0nCoqhYcCAWBjUU1EOsGRep1BecGMk0qFceUCt8kVGo7QE6HJEBrmGbtNSuU
pV9UPehnCH7AYuLOKd+qHlJwngCP3jPqnq3PPrhyx8zZekG9C86IuhRFVXdx2LHU/W7QhcYx
XYkfzx+RTwHU4uR7ADJTp1EQyFyZLHsdAbCr65htObEyEKOFQjurSBniWn036gBz70ZcWly3
hYmVkdCbyYISMEl68ZaOZJT/9kx3P61hFt4S+f6aB4gKKkY+UP4drB0HcrrJrwd1sYIUUHAA
6SHn0Quztthk/l5a3n+dP3yHq4lLvTTYr7wUHoWskakfOZQ9urjA/8Yh+Wqcb7lTzOpaO6wz
zNNFQn1cIngRnvnAhJyMaQnaLp6SB4pH0M1ImAJTkMOxFxhbSx1xEtk9TSVT/jv6oAawRMrO
d50pvmEwHj4uchHIO9WAsIgf9hFXrpIFIRyXmpZBBJkH/QGcWBRVle+ZqdXIOyCOBh53WIUu
zmlobZxzKx2AaOerAtr8Qr58W0rKaViXbTsHZ+xqRFA00T04cZLZ6Cji3fAZ2ixLZ7VJ/ALq
DBU6+zIx2LFig17CRe+w9dtJ0i79EPzgj6YvfUyRok5/+NOc2fP0jQJmE9SHPw+EgiEBGd3z
p7HBYLrln9MlPt19PQix0fvYkRdzC0jLs+VAGM55FFwyy3FphDctHZrr42+VirqPj1YXsQai
45PYfO33Jwr4QO76FbrqIHcFIufyrPzHAhxLGR1JulgwrrL2YLNFdlPeTqKFCep9YZXsDdr3
Jm62/A0vDcp1FMQQ8TELcsnYjAhZ68EON6+HwnxXeA+H6n28rgZzo9BoUHWYMFxY7KGuE31R
5PVGYP+SzK5rKZ77QJdaW1GMY7xJWsQqrORnviVivBepEy82bBGBwBPy2XLr9HFFHp/unI21
qCT5mrkVhETAzVmf6gN03ouIMsFkSe9JWUzWHSTOPEI/rv0uP5hin/MBxCtdUP8lUXX39XMy
HQ1N2t4q/RhEvcXIvuCntFf8Fc0IoyYy1NzlOgU4OE3nuBeTUIlQFvrJstOddwasLdQJu/74
PJucEr2asnik8s2ZTBn0WggucxJWm35Mrr4W0ACh6DM+C9QV/URpY8g+FsKXoUCKqvn10lM9
JOxNZZodwjuJzbKBre3jWFi4ynw6pAHzzVS01qYn6rp1BbRazvNg9AoWHV0MB52HcY7LV3X1
G5l/P0FkUHrX4/EVTAdZsq4YylDN3EULsBobwQVVQzcZmexU142rk9Uk+GUmxrN39VcrV5Uq
7pp3/m3Ljpk2J8uBXhtSy6aORscXpPyZCra3PdD/ilij8pPnIVaLjcy4GWHWCZ5p5ZQWUmy8
2qhAwXmO+KTsd09esdiAZxS5wVB2AYlb6Hq3yQ1+Z8HvfwJl/YFMsrSDBO7RlgAP8lrB+/+Y
02ROHF0WxCYGLWtvZ1aVx/Sz70jDqTIJqw4iRLrpchE/1Ux9sf9mSbsxS8WksMgXMcTH4uM+
Jedq8UXL7RzZpmIa2d5WOPg0dATvcqJzCGai5RD5Qes7h54UlHaibisBqCoVPd5RkmyJxGsg
Ua5he72RDdgwhcTRRNQz7d8Gohk2tU6JFiJgUTJuIhVqtF48LgiSJQHWOTeOad1X6/Koo/7a
69qYgOiuQQeJ1R71UxGSP77FQc2p/ziX/bhqmAlKssT1U0UP9vTUyoB9zOehIb/X9SEvF3Ve
V3TN36NbFFrZpZb6lmYXIvTp/rvTcBGLDdFj77Z9LeQBqIxbudt351M4d/b99UAo/Seh64Xx
6xHVShvgH90JnLyA1VbLWrJywA4Lj5NAHyynpTr9ud0o/CeNIJTthCpoP0h7XPsP1mJ/Ve5G
MRpqxll9yCg89CvzbdAf6+PeC0fS2BkHXBsQ//gHpfL7gEpTfP6Q287pUOf8Pf1vSRNB2S4J
/oBY+97jwIGk5pBX4O1V+dtJtKAYNaWbYsqNscNMqQLPVAEitODD50cZzqK6BXGrEnvy+VsR
EOsveSY1iXP7c9j0YmD90gpaMhzBCmRSMGrPtdHQ2Bp7Z0k6QxMJzuVfD5brIw+zw/1XL5xr
MesnhD95re83f7IpjPRQjrquDmCrYP4GhcRVoTyaqNf+Beg71epBC8WQfuc+AXaVldgaJ6Xr
gWjgJNEh7dndcx24HdwLxLfTBZpZM5MfxtXH+7pN1PqLpwzYpVP7nFr5MzlJYI/892J0l+Li
x7WWkQ7CPYe3bTeK71t9cYkkd4qRb2GzVOOtl7t6G7h4qGeBYSdT4Hmle1MmiDuzEtx/hwhy
RVxm1c9V6NImHtQC7DpcxF7ziY8RsiyaI3TDmhyoXwbzL2+0IjFZ+v3SBwO+lSjXpEHRTz2e
oP4XqKVac/S34dY6WNRz5uFr8yCwDyhP9Nn2aIZI2UJ8D8aiPFHHjJDOOmidZSw09KPwHQ1L
V4JWfnWrSDK9sOMrROzcstQXoc5Q4jR20IqYx5CKWQd6+NrSo99XfwrdOrZ04vcfr87oXXnV
u84qh++IG2mK5HrBkE5+alexd6kmRrWVmxSubFYfq50+BUfsPYEjGaluhVDw/XwIyzzNjPpd
E9OXsrmdcTDKIcWr1NVYQFxYdVfF8koQh+0oIokCmtiPa22G4K5zDr0Nm/vzwfWwcaHUA9R0
PhgWqPNFvccp/aMXXjZcM62qz2tgGzBCKyyVYGYohqsoW2dr8EBxJUxlIZz8OlihIVSIkp83
AEJ9JudPrH0Z8WNmzKjeM0bE98+GJRGtYKRu+FE6plg3XLYo0DiKh4WjClBmoQfjyey0wGgM
umKgdETqjim4iesJY4Tlu7g6969yHtabM4jS/lPEowH/GGZViElLHqt73OmZ5COH/PS9uHMy
voohdX8XcbAE2S2/WNEyixdE/kHk5rrC4M5i80L/xRbnZMxa/PIqmMuuo948S9psp7lie2oA
Lo43ShLG+iqQ38kNIpiID0G7JnNQxnsqL1FcoVz73X0AsxuLinJu3UOdw8erFY/07VRLc+0R
ZnrlRtjLu+7k//JXPR41mrh9FpO/7CTwxxJA2rqbEdGYXrslbOcBytrPjYwbxXkGm7RKus0Q
aT8bPRMIM38TDPPlLd7746WbOm/8/fByJ3ISw/kro1rSH723FqiOaZYSu/zx0PEJ5ffoH+iT
+T7woRFPhB13vaXlztBOTPF5YIeucsRYV5lyYtLfc/flcPhz27bGV3sK+JURJl3W4HTD+Trg
ndZN6eusrPkGOYlchylvA9esDLIrXYIYbKoYXtyelH1/FBGC+K8ELB2CtoveoW2912UPjwJk
AjIanoZbIUY2nz7ZncqyRr/DR6lNiSIayYZbNHgnRW/L38h63PLYjN6PxotXtbtdVboDHvPC
DOa5vmff9EyQQDPbZ1PUDSDdRf3StdDdN9m36V6kTQ0/RoKOHViNdQRW4crBht6tTY8VFQa+
93jSZB5KEvE1t63QIeLEZUeuIA4gtc72QYnGIs3jDKMGxRv/Yamf0nxSKN+mn5WXFR3TIDmz
806rvg155XhMUnHPKufzCkYqynxTd7JLIyUbRpEYdWJRZXlHI7TF61r0ZmSB2XqCwqjvRVhp
U3p6afXDtLbLnNr0FwW8JC0gOxokwajpB5nSRkrJ4XQMZbRRAZVVDNVRF83ps4Ng0xKOew1f
CD9BFO5Y9SYJ+5q4oj1KlbBiQktWWr6w03t+owvgWq25SYDXgMgvxxDXU1EsPVCtz09Mq5i+
E8/KqiNdu7B0V41Xzfb3kT6w7a95a5wzPPLaTGJm7IZuep7ZsYDZGGDY8xWi9yE4mfp5o5DM
lG3kGs1BLO5D4xICO8qnHI511UJMElZ+jIu/JrijerTXniruQLBRSTef/db0ads5FIM/FUnF
fFaISLpkyJ8IzyGQRyCKBRBeKQZ9oqNchMKdMVpEVoubWyPgF/I7exV4netB/+AKbfnWqiUK
RnABvpC6bI9apH5O8kjo1Ul6VYF/ppk2Lns2UxJkXT9ZuKbjSLu2jmX0k3jwkT09uMpoQK5A
6fvKYwllyDJWZf79fK0ZfygPA2QPcnCFsMJc1sg8gD/NnxPOyNQc9LKAnSarleI4gyFoIm1G
9LBmCF5pwgWo4paFp4UdfiOfaJIvUhw537gCoHREMUabiJAkRtecaiE8adndnMrLnYoMNioz
g3EN+daYexuv3hD0lzcO8GLRiAysTduzTGZz09wwWAvLxch9PimozRXLItaDLL2Nj1hqng6A
+JUSjLthP5eIi48DRX8HKmJHKzHDZ+KsftgQ22N4LSq9j+feQrksRfGQyDGlmsHMW3JrXcHf
nJM6jZrq6qeuiOMihQ+J5hTzMRz4l8a8Soci661S+4UTZMJoKIcb2o1bgMPVF3p1lnsAiq68
rx5RzWjGCoaFCrcnq6FtisRq+o1ykvfmKfsnoSRqbkdeLX5w1O5cSsjHUlKgeqTVUQWCuA3z
siXhY4ABK5GI94vU9YvEjYKgrFbPWe5GmUMKs4MKii6gZ1bJxcTfri5qlp+D768dm3QV0Ah+
scbVXNnMKS479I0DIGRcPub18axHuC+7nqFzJhZl4PlNhRgW8xJ5igR5SPzUoNkTwkCpia9w
Gi148ACZnVBHsiBO0kmmEwtEMKwxXU9lFCD+ayNiNd2iHMK9OZSpiy7tmBK+GN8ASjOfwQ6d
i/or5rkIB5ErbBKYCaz3oy0p02GQPGZZUD7c45Da3wsg5FAKTUGxcm6wwW0ySxRNQyYNR+CT
U7iUeyF57ipXsmt8PFllKDlk5J7gNFlW3Y/etcLb1PrUsIipxMKlpEqfoClcjfMnNB0zcwpi
ceS3/LuRT27ZkRDDxcCDEtXQW+trYpvScdaDjgFGNS5gmpGye66RefmJG5bGpvQBfThnYUPl
/gBVtD5sLg3U2/S62q+aeHWickYNgxR9iU7CpuOw/w+mCRRbhAF/yDJT9Pa+B+TRGIJNdFic
NsAPuZ6Ry8asJbSWayiXs7fl5yyJ0cW30ViPP6bWChLgR+EHaGeo6TWPBFaVllsYFYTRCNta
oxw8GCNTAg4+Sbi/bazBVsldyfLtfJwJPXBgBt85rMKGjEAplpzgmlaxW1Ts+hmW8OKCt9oz
Q3CkNepXVjttvCO5EpR+9Ta+KrF6FO0OJ9CrbHTzeU7TiYuN4PB52G17FdkKUeAxPQeE22Ld
hCQuaiNwDGnzmuZ2oV6sGbC1430vPf+W8+aw9YUnaDlIYdPXDQ48g94bVsRHRlKITD0DbQoA
CJJjz0aEDeJrpjk8n7BO6K8SFdxgOChuG45bZKX64NZFQa8FZx5V/R1AaFmCf3/T/dXf+4Yh
1OUXqphlzE1Dqr48jGc4DUSdLghkcQDBz8eWtSWQbYCuh2qs9fUNg9ObCslg/hEqt0bfk0J5
tJos5QryQ+F2q++/1bndnA2MPUQ2zFhc65uMsShVxrPtuZToATKuIT4RJIXRmrQBpPTFEUu1
/oBHge8sJW66E/EwOj2uiarhMXp3u3LKizEy/Mpo14VIXytobeij048uzNpS+/sAn9gNDJSc
7ytoOQgEvHGEVXFhKyjSFf/UCzN4zK5KGIipxqy0oKcjfqp9Rz8VqGnUsh/dIJCbVGeS7zui
9du+6stVwC87gq8rmwroFtK50GfmD2rUzieQTFscaoj2xnUfEScOO3gMoidZshZMJpGIu2lj
yNkVtDPtssJa1XW1Bet2deW+Re3LTTmZEcigp9/Jq6q13nCW7w9MKI2GsvhcLPXPi8c9sPFK
8XkcMQY+hVgxK8ONQ8LhPaU5rlFhZeKJKKmVAe/hfs0tt4cIWLqM1zS+arQpPOGUYDHmWzh2
1hqNAV/WJMWT6is5HsfaeETDgtAQ8Y1ssg5nc61x8Ndb4vemGG4U0Yqb4FWssXpO9W/SuUMG
2rAPwy5vpyOS+Wex1/NpD25gaKJ9W6nFq36AWOAQXnrw3TMuLj5ilTDqzky/DYJuz8Ya6oPO
eryH+2E3YQr6DHH22Af6cxHkZSlIXSRTWIeUksThSswDqkgJ8YekR3u04KxdzDft0+eeRN7p
uwC28Nz8YD4wlioM1/76Vqzd+Kp3YoBSWN1gbvB+WWQvDZn6jo0/QCdSkePqd9qYTHCdxz5Y
pQX1qaVbz0o6kGOg5XJLsmm03Xhg0PuAkBo6eNbG6UTsyeJ9p+tOP2mXf/Lg5Exru1wnvIr+
5jjn6nfkQaDO79GpPNU1rgtYtRG7ndIXt/7zqYcmTKInqSE/AQYIVAMOvVWMUQnkQKzDVfI5
zOeR1LpllNS73HqMJYqOY6mRNhwei+zSbHk68trU/Fmq3iB1HAtg0ojOKgUgUMIOicbYumL4
hxaTEwmKyA1ktsldWLTDi9bgfAChfvgTHyvxro36zLd29Kgcs8c7D202+oPPQZ7kT0F406By
Cu+o9KmIm7lTTnYcopjEg3H3R/DQhplT9Jfnx04oOZp4jxWJNIJLqy2P3qwVGW2WtV3+3Q5G
ZXoaQ4F3AgvB7FONiGlvCu8tvQTYrJtJqXYTZVxw6u2naUxnW+h1JkGpetlSqg+CxPDzrLYR
gJjJ1fJHPA1cPB3AIlyXqVTDCeyJ+yi7fi4NFxuhga5INmUBJz6Zp8z4DqDYUjvVGSMD6K1q
C/5ziFlxACr0KWGyZKCotjBoNO1O1vcl3onkU1Zhm9IpUF+PYfcBKav956c1ZU58spBSDbex
c4eO039QN8qUZOYOZb3o1sCXw6tFVwzw+GsZUuCiTaWFEHhFbHoatFmMeklGgkwDvo9UzdPi
1SywLLQmfQBu3jYrBE6fI6M2bo7IKJiQwM4EY/DHjT+04erPvpOM/9phwebDfkhiw8g+WmcK
hvrqg+GfZszykB+//3TzTZ7A5Cf7UI/5mPUuP1P+JxYqGEwqraL50RiMNkEr30Xtv7IQa6bN
GkN8XkgK+rvzaA4OmUwW8vz6Z32wgqccxaFavpV24leIJUjacEMuGguchK0HTDcU2GC7AXOS
Z9964H4ZHCILB04SVnG5SVgRRJahrK9qaxfKVigQyMIyRYZGTd1gV1yrHzlRIqA7tqLA+XNT
qKIIvkrFNRzKU/DGfEwbOuKMKCFI99QchgfkiXVBj5Pb3CnDscZqohKoBCMSpSZ9EljyUugA
ogmtYCKtnp4/YIIv9169o0oV0SzArF6fgXP3rBEnraUINn5CNe7rW+P+a0MY1io7xsI0H/hH
MlP6xcfKvgfZqEy3OOTBo8erKoqE6ANo6CacgcY1Fs0UH1eb1DHaL9XccO1fMI88HTJvickq
XcGoJSXOnnYcyQlH7uMc5vUqb4S19rOGNJEBuLUI3ZBGNjDJXOKOvHhA40nK2SBm+D52qHSg
iZqKnqv0KaxTzLPcV5trEa2tqy3W3HXTUQOndCPS/j+jmTOXFsOIh16iZOA2XncqQKaQrFdJ
vVtluVkNmDNlvGFQqOHbmVw6dKNB58YU3Z3YFirvfmyNHEV5OJnqDZI4wE802WeEhXEGhVMR
Duq8ZiyI5Sdud/x9WmCus6n9eE8BFtQqpeZpxkJOPFr8hrSYj0ticFJhWbJmE3V49j8LbIpw
PSZtN/kOOK0uZQrLSkdAF4TPDkFmlkCCJqBCkfYsKyDvamdeh/8Rd3+tPet2ZLsOo98k2I1s
12WhKueL0xTcedC2GbT+PS0dRu+4/5QbVjPoG6SQB/Ane8VdGw8QFxDAeclxiODyng2buPzx
3HpHpijPrIynXaK3SdrXdvZlMxTogHnpU723/KlY/qlu5t9XKcOPgHnKTB0s4yuFusBYa2SD
irhH1Wn8qp5X7n29/YnYMOhKhfRN/JFpQaw+xGt5ELmM52QrnsIGEH/6v+QYzy81WMCUDfhI
mvKn2Pn4/kOoAvFZ03pro6WCYGzEYx947cLLmC0JZBsJq1rHRknDcKmBasTh0Dv+xeTBcDqH
XRJ463EKQ/ob8HsddhkfWRgAhxaL0PNY9IknY8FX1b2tusXWzTpzuQo7mUz4/WzGV3CgTeB6
kK2Lg/cxn4jNh/+y/LdTn5kn64BlGJphmbenvvLkipjMYO/D3VYuHEGfZXfuFS1873kGkOJq
odNPNnLP1H/fznrol6eQfndO/VRJcPyBzEnxhbA09JCqlzVe/xxjwG/U2bRqBMyyefzqABe3
HpMfLPUMIjhbXG5r9yWQh/0On//IH9PScQoy7OtHM8GbM6DcrY3fAM4hWd2+EllUuRrDEmpy
AVbjqjOCFwYXajj074zxBkUuvzhnL0jrpmEflNCTePUH26HzuOSsGucdCPNS9AMiKiJncQRz
qoYMLpUN+kOnF/WR/9YfqUUIID9Emq+Ktub2OXrRpxzTapEQDU2yt3gObB97X7LH6Yv9oD2o
JPlzQyixNvOExjog36plsYLZzLKR74kwJX+NF6DkVhPCIgD9yAZQwHdxEBu/i/u1jp5tuAFx
JohtNeVZo7QRTZ4eslrbgvrDz+PfpvmuwTl4w9ZbIOrySomjWymFePX1qMVVglR4Bc3AoJJ2
/WiAYEdy0uqEw+mBPJm9Z4lVVYnBuJfagzmjsi5G1vM6Rn5GoHyeKp+wJeiTx/f1In5WvId0
/tLm9tvenNzMVC/7xRirob14n5giYAQqIOwAJmrqclefdFJ3er7X1YAi3SYC80xwqQOWu7XX
Lwi9F4PU9qH+NESOW31vwoap398lmsx6Bctqt/TTBcXMtGrcInEvtMhSEAW6VOTMvODOhcNs
0yq0qn2fyTPXv6MV5rYXAcyAhsMb/PFgOSI5yXNREhPUSj1NzLpLDyDZDTNVXiBqE424j/GQ
FyGfMe9wRI4USmoWlhX7Iwp83G6j+LD8Yz9dz3YdEOl5zSZb4cIWU1AwnB2Z2lcswg40AA4h
kbuFQbcRr0i5CULa8rN1laujb78QMUvtw9QDniyyiMA3E6L2IHNTY/tRx7I/jF8ARcgAvLg8
C2bJH2yudc+ZeKy1whCvNbtJhPkx/q+VOOiOPycnFIpiqETMo3LLiqqfalQchDWoxjhvxAOF
uXFmiv9iFPfGPfQ85V62uePrYs90n39EWjQrH49YIGyKKOHZrx9aZBcSOJLocSxUxZ9RNNi6
UlKKzK7Zfid4VA2+ni3Xx5F2jXV/mUyK0D0GN6j41GasqwU81kho63+oU8HvKbXaL4nfbWqQ
drZLnTqAiMYnTf/VP9DX02/teKJONG0ARabnnfGdiQMuQ0rzOVvbqzDcpZjb7GkLG5K4D3fz
5/Wzi5fkOTVzdsK9lwxhnJcQvqL4DCUHU1zYjD8gWVTv76spqHQnqYC3hs2kPCDT69vohIry
A15+yWH/U/IA+Tq/wZR2PxHIUPF7BjrzRiTF5jZotWpvzxZOq/vahZdm+aJ5qf+0qfwt9fwg
vtksTklrfROt9/v41NvYlT6Szxzn2zPq4nnj/9YO56C6tgxpjJyrV1kjfwHQi3EaoZa6pDJL
968/2t/Yz20vCVYrC6yJSJSAcy2CjjurC+ceTbByX+r0KJ0io3Cpa9sNndcp8DnbeZyfFSMK
1uE457ZkgRLQV7yHpgHoWcvSJH5g4ku8oOA9uAr8YCBD+ni0dAySbsgL7uDku2+HfEGtCkFg
+cmAasVq2ide2gbQDyRtcE/mxSNJPHx2dCy+K3+UJoZFbAoE5EoQkIsvsLfF3pyobz7e3e4L
Q/zipt9xXOisOgg7AtOLxbFavirZ+0UmJDpT8EivdXJ3d/Tq4AVeXMVPrwLTzlk/bzBo8eN4
zWj5Ypqy89S9lCp+8+QbSD1zCbJYUEKueGhwG2SEQ6Kqgz462eAqHZCm9NyJS29kOz6rELv/
LcX4oSAELfJN8vOkKXoRRnfOK6+ax7EgKZlw8UQeQsvQVxgYVX2/LqrH0Em0j6lN4U2ItHAS
d/ZeCMbbE44wLvvxmwauuRemD9YPaLRu29l3HTleLewgMuwl+uUD7+4FV8V+Up5WiH0DcD3S
ElqGV3k82N4J102r+g/sDiGBqr2kbGRi5PpI+vwoy6lo/6qAH1P/PfvWZXlI/VD6d//JQdRL
dc/UjZ1zdlhUkH/XEYdzE6uJFM/KiqunEccFvzlGt3vRH9IE/O/NMONoVNjqiEBIJl7Mnphx
Q4ycVd7nAjrPnXzS+rLqE7VsKuqysNn1VZpFfdiHXEsjjVLlk8Nlmn/bpTLdfoMOjFMfNL+G
wYavvK8vLR23Nc6jqXkKvoNrf6wpSQIcJAmlzrfv8ZxEMPlUpGM6yLeI+8NpYtmu/XfBo5KA
cZxNJHuqL6jkUmlcUMfjfhHCzoXgBmVVs9M6gfbPtTtSGqKgKMNNGpCZZRqVi3aoWAYRc+Ka
84sA2oGxcodGVpiGXOiz8liLsShrt4FQljU2VxZnuSNanLGvdbzgS58Gi3XDiPCnJgoktyF4
YFRBTG+XkVOtrch+3nD1FNQzjhFMlxKeZIsrRrXOUga/GU8ldVicPjDf0LoqlH1HUf8kOA5+
L+GSqIbwN6TiyFSVm9ilyHn0VHzeldn91CAQMqKdBjP45taF7/kArH62ohxSv2BMg7xKmT9+
YGHgJFgaeWQsM9Fdlpmx7uG9MDr+vjhEluQao5M8ySJvvXgLiyv2Inq8VD2u1+3un9GHYTk0
CT//QCaqQvh1mQaSSf94jAYcuCDgx2MWXwkvTagowm0pgXoIkR0boofv4Nh/qnYg1xTemrsM
VnoLYL9/Fr3BdYfLeinbkVZkrv3mIC3wKIOPHFjGv7OwHRBpng0MEC64HRhWqHsetiWpv8F3
7CkUntKJ7No25sX58uuUZzlbFlnrXgx8xMFf/VJLOvFVUQnsLM+HeE2DBp/orfljcGcphAWf
np1bb911WwrdUmqaOx1T4soWeAUrs94NfykxtMOYwJfFwuPbGr2f4RC+4ujhk2gV5KBG8fdY
AfZiOimT+CdVqws5X6Ov6qbWOoA3U+viQbiQ9AG/cF+wXnAxkcyxvsPAwUwo0t6v/9SHCwXQ
SRMYmPvhVgoBbFrFaO3Thq/dBWpjgH65CU2zZrL/4ow6IlSehIXr8mpFKzjOSvRFBkxPpHU/
jUCIAjJ3frov9YZiuFPem8PkgHLZ/UIvrjtD3TUZKFQ77nVnst+8RTNHATXJ9qr1Lf08qw3e
B13KvK4B8uLo/mmAQsCk7nXlIl/o57WNRagkAbqrv1si+OwOpIprD74lnOWfCcU3NyDvuBHd
JqGBDKhHuYr0Wdk5aEwTvRQCvqEnekC/dBuM/vGDhTMIuFmk9t1+Qxw/S6Rwn9etSja3j73o
BUcmRu0PXG2J4/Do86SrUZVwMkWzJPOuxq/72Rr2le1VR8BBFuvqGA1PqsDjvB3sxIDcCsvH
QjqDNXCk2kOZGRxgUVkpe0wwXs5B1zvCfLvTsXnOuQpY5zH9GVPvI4Kz1BgBYvg4mjifOh+m
39mif5a81M5X9epITW0U+aZWVqcyKUt4XVMe2NJpaX7s/SueBA7K0iuPxEC6hrZsCNYyjTVk
H1a20sj15bcnrr/lf0MzJrbdHOb0/VIsVOrAbHh5/e7Y77WtmSo1orxG5+lrV2K28k/bBbme
eGJBR1WRISdYpGR+WVO9mJddt4W6401IljIBjvTGqolqqKwNO/NzbGiescP5wue4jHd+Lbnk
vjVSUy8xtyGbpXeb0FY0DRgSo6S6D4Q+a4NcnJU3ZIhRF9vkSOSzf8vZhp1FZr/ZflWPdrcl
d9pOiZR9z+qvJzCtFJpuKgdQity7TjrH9xEcfEUzuZeUYwoLe7yJilZj+dnsisZvTlrVRhut
OH/Mts/bMXFSJzc/q+lc6Avvxw2I9jVDwWxx7qE9RvhI3utkp/lNyOp7IA9B+p++17W7Lw5z
AUiEpL48/eyfyYfCFk1EdR7YJyrV7Z0P/+QJmSXgbvzviMIacvubm2Vzaskuz3CjpHWxIeEL
uL7abEZEngIzglTUllWk6MvXg5OGq+6Xk/yFze3anfmnStPXKYx7DR40mQYCUywTT4JyF33M
AqaIJzH6cJUiVd/Ws3Ak+bdKdT56eZr+geWtyP6WgIh8QXO4NIHUC2T+QHxtJjfMcgufmiHd
/JaClsbZytYbjEoh6QtnpIZ4vBaiRqEDjH/oPkSm7DiWiV3DAGLnwxe7gOuAjtgllU5mjqk9
dQRUM2AMk2nmq2EOYVl7AYyjb34FR2f5r1cFj4KEY7mxMSE3v+NeCsOLE71lKyLJ33XjSeHZ
3h2DRHNPSjgfLzllhJ2rmoAjr8EpVLlU3uFZ96ntyFbW3Ah+gk3XOAuCbyziL33Y5PEtFu02
AD9S2SDENg/y5rtCr9d7lALlWnug/VdDB/ZGbDRFcmIXvN+Y255E8zgM7WgTWQt9VcAkE3Dk
kz67UdJ2vOEve55XrpPL0Z4g0V9va+h1Fch+KLnhFSTZiw/9eMrrEdM86wVS3N1l7ygXiiNj
Telps7XztADMxr57Xl/wi9i+XKvENlBMNADW8L4v/yPZXGgcKsjEQHQf3ErbgGmM37tQYjrY
ogMbX2kduUDJ/zGdSkLd55rgRsfefP7iR96CIJgYITh7gzA4D5iTxGNW+HEykBbyi9zbDPDB
W4RJOpxufG9k9VtnP6sphzu9RarfdpsBek0ablZNKHvhEqk6/NW1D18XggUf8dOBzaBXD4K9
gsLpH2+8TVxjPy8MgtDdkTKL5/4dQWbqQFzAN9yc8PViu/FMaUy/i7iTNKE+uHaU0k0AWKJ0
S6cNuAiDIynFCuDJSdEal0U/SYzlLWctZx2GBTqXbtZmeSEcTr5VYoQuoSOR/2noi1BfZUQm
fr9ZrZhr4mns8BPef3HbhIVr3zx/hC6RqslzZFpsEIjVkfan9t4DMsvWSydR5mrZP85Iavrw
Lpz035lHY9Rd+RIdYjbYROoNXK24W9s9rMWIucdsmJpbEK2dPBfRsoORVCvO3NP47nS/t+LV
ci+9zkb/E9Dzwwqcfw/+8xnFdUTxRELZgle259m49iekc7UluabAXrd8eVw11wjxNuMCC2B8
T/0kqses3ukbyWVDPOJ0VQ2mP3DA0IUe/oUg1IQe3hY0UNly9s74eyEkE7Ceyf7yZ9cq9KOo
w3t06Y1+NPzRYdzgZVvL4mYbjOXgpLvX+ylu68eTsvAdK02fJEB5Jq4bAWaSTez7cPSsD0Xd
hKv08ny6BSQTSrwxNgn7CqbRZLq+gLJodAMMjnXUcOfQRFpYLLQnBl5qmk7nvS6qT5kULc4b
k1pCYGXE3d1DMkSUQUQyAeHNY3DXnOwVchq1/iQeg22C2TsFdKR3K3Z4IHdjThVcWlD0tsFB
eHb7OQT/7K81HDJ6f8FpBiB2Bxz+e8k11DnEGNHdPtst4AdrN8DaRKgovqYxuRpmO+dAeDL/
ErNUjaW9Wbzz4Aa6IF1WRhkTqNOcqbdmfhoQFbFWZ4omCBjQh2d2Jp2GgtsLIQx/uDz17PK5
amOil7sLcIvKnHXLMZ3t6azJ0ScrkqGJl3EgHNWqWLfrZN2euPCfS+GVY5Mei3OKlomiuSGN
2UAIcBTErLVQr9kHiRNjcf+fLFg6bZ0ijBF4BwMu2dLbbe2IU9AiueZ3B6+ormxC2b7uF+W/
C28amjxdnKmUXwo7285R3w+bJVqEJnVczg75SSGjatK5JVShym8Tf8QmfnE1g99j+vkNWm3B
cFuBGHSBC/JfMCjet29j/xQyN65Ml5NRBkZOGfGJJDGMV3/ausVH2P/zu67d43HfOVmnV7Si
FakNFJz1M6Mjtk1exgvZff8Btjs42DPMm4RsRug2RCIbRVjMAT2YWz0L1PX1zgfEHTUDGWn6
w50yUouN7lhBGC5VpSLMRz7tcY4s2aKAzWZ1Vn2i1aEgI6OlZmjpkVlAmce4JRoy9sY23AfD
UQob8VzqoIn1MGq208jhfEYh5fQ3s8/bku/LUKNhMu8Kp6CDCUQVSX9OuRBT9t+qxEFJHUYh
bqoMDRqrM0DCgnsqMeBpcWwkudQjZj4vOFKn1klJxVgp7ogE/+CgQgtHGtHvoviCTzBG5kXH
PrfpHyHxtzw20bCcwVLJtWsU689aTrnUyVMVUF6qKHjFK2BMpyJmNU1T0u8dc1xknW5RI684
FbUX8SkCcGAM/K97EdoLOW0yx3RaBDjaeF07RW9rcepnG2MMbC1Ttb9+6WBUfyCRb/fje/WD
zh/jekDR++x3Z79EgYWIxX0IZrXEQN1gPotY+CHGYJeNH4+tP/5ALEOWdDDA/rnwG40ldMc9
US608knEZRBwKfKcwCiCLVbK0U4IocT/7yJ0Os9z6bICOdjTiFDb5j0VH0SQbdAxCJ3dyrKT
TgqAzFMfxf/GmSlVIFF9myRZgJXUZy+DK98VSvbcqFMVX8rh/emNqCvsd5hcQb/wARRrdDmS
20YT1lg7z5xdf802V4NXIikcYC4/4tTeChYBbFjlaykA9DlVUmm0/ueKjYHBGpubs69Ur+rc
XwQTfBGDh8vFLw6AZJ0UAQZmfMK1n2CQnCJry0+gffLaPJhWzyIDoBnk9hUEHEw2xaz1YCbV
ypKzwEaTVGKwP2gmML60UGww2eCKMy5EkkeXwrSD0k25pYJJyrlnxNCNdk4VxqMmuYrT0sQT
3w4DauZO0OoVZ1efaIUu1CLMMxYruTkRWUxt2LkffnRNPxIwhTTvlDLsP36WegATcH/zKjkp
m1Ez8c7RZ6ZDEj8V5GSkl1exrFFiecMYQqNtpiWihM85+9+NzpPI62/A4+9kqAJm3avr+HPX
KP/+OsR+p1k3Z1ksIDOhHLpWuF2XveaJt2NK4EJiN6lEA6Z3AtPzeeO/geTcq7oGNz7HbzHf
nzbUY13om5bfxldnEppUbFXhcHPX/WfWrhTdKhZmZUbf6qt6X8ghC/FhV9Y8DQtyMb1cGJ2q
m7lIUGOtiB20vplmX6NwnUMdICp1qbz7fxW4IvD2EBGYeSDRvAp8U/jTEirbAR0RKjK3G37y
Mrpd1b+GGGYQ170kVdjp7YJXHpVcVpmTf0um40LY9xFBqXdE1vuw7dIMuxR9D80Y5YcFyPXG
veMEtQbVthrhsisJp0ekJoa8R+Nv0xp7z73v1ucyeqswyoB9tSHN3br3bgl/SS/WVzJFQ6u1
JXw6SQq74OLEEVTBy//+cyvFDNmxgafRVfJlT2l4dnapXrJXObV7Mm+Lvrvmr5W2H1ASGRrJ
Nf/NOyDwEsMpfB8Gt903ZLgoafQcauUODc0gUFwQqEPUHzdvTqmnTzE595Rf0BK8CDLXhUFw
vYHEHp13N3RBmNFithF3x/AxF97mIXeILm+x1qC7jUFnctFEQV5+C1jC8Fe/c5yTlnF+6NJC
ZzneGIrftULUlcccE2B3PfXf62mXBE7Jjtd1E45qYRFCSHnmeYB5sbifq4ysF0izPRFdwp+x
kS/Q3+mq4xdpuGKeIzqQ1g5foYxYcPH0jSaIpoZVhlIC9odhmZ+s5g2jqAtS7zqSjxCakOBg
VrZ9wwFCCSSXdMtkmEZ9Gz9pn6yeDuHbUEzepDouvU5mc4nlVRG6uKmdNwIu0PIC7jztbH83
wb1M7Kxk1cA8FpJX6riuVuW1pBOGmRX+JtfuKHv6P2MBc7qUy/l40jdKcv0ekMC86kVONpzA
7jIPKPz2KDEfprkOYd29xzDApsVhkoCHkIsR/ClQf77k80j8Dt06k8XITrgz9ohbfV+IQNW2
JrnFIlRY9gOHH7kk00dFvIQx7dUfsjzPhFmcWUJLfBJ9VJK7BdvMKc2VQnYAxmr2Qh0yHwfL
TEFnrpC1/i1S/f2vv7OLixXrz66bcwNFgShS0zoNLL6JbBpIfZBWPDEJN8eD4O2imzF0kaFN
QbAi+3ZklngKpy0kJd1xe8E4w5Grb22JaKxRpXc4JAxYiURyEZXapRRSyZ9YdH1bn/oSBTeE
Gcm3N/+y6j/LaKCPhH6Xf1CadHh/eBZVm7t+58FRvglTouTXskNfbWKDxTWV7nDhg3Uxtd6J
rcK6tFNYCj/84r15URkW8HeLLQzRoFpP19ISJzcgamnqVrbPMjlxTCiO8qpBEvToYjYYmulc
RKXa1XjbJDXpPUG8YOKxfUfca78ZqwPvofnCYT1o+6lYf7dFZjgb4OgpsZ8mLXnA9Issv3wp
5oP/zmwYTDfaAPvVq0h0a1IQ3/Qp0WiueaB3Uw7ZL2+gNn21sKBGttfpRYyf9Pc14vOKvDB+
4i/tzxeDJYj4F/uo2Q27EyT4TExl0WPT6oAxuZ404sFXGZi2jl/b7W8mwXhC/t+pttkfaua8
sA3YNleOsF4BX50RbWzRWAFCI3Ot5g472gwWNsRngPk+J/6T/BRaalxrzPuNkxfTiaCG9jQU
fey0U+M2Vlpz49lWf/MXNUNZeZidLQg+VgHDNvnOh9yZa1ixV2fCwQC9l39CuyQc8TVNSklc
i/wfpHwcQrJDWaV+Vmy/MYB/X2bU+opbpicZGyKmhG8z/TAbH84gaCQwT5rl7SkAxJLSSq1O
9Zj8EEIe/6cYXWqLo6u64GT8m74KirqDy8f6bvnumFtogMc+5EJuf7Oi5wCwz+l63iu0qJGZ
34uCKRl1HadQEIpHspBQlrsE4yiAPRnTU0z1dpTg0UzQ005mccWBLpM3E0Fmfma1LuBO3Xx5
zR1Am8quCOJrIoGjaGqo8rAtrWln95FfnUSi9iiid2UGLPVrOl3OcnaixK/3J5ZBVX7vXqE0
06hthsrMNp0Mf3CQ1ziuGhGnkkMb3mFS3uJF2+lfmvfOe7fIROq6S3MPRXFLM9AlM6pZiMeQ
epOeIlBslHzIif8lRHIEczlGHSTu3g5APSB1cE8GGofCkSr2i5Vg6/3qWK1YxZGCHKwraiwX
DajOLlVrnvkZIFKPcfGJ8d9oqyiX6QF5wXPHOXJF305Ier9TnQsV1sYsfzT+9dx6ldnpYTBn
KaZ+DnA0WSBNVgLsbWsMKc+wO9sKXOC1HX/zGnpsIJ3L8cL44bCYNZlenQTPt8slZF6G0FZQ
nX4xheInNWsc42lviwyi354BIArHw8VlYq0VQjxtuXVZ42e3T6En1pXXN/bo5Zof0L0iNVgc
PhD8+j6KZWZ61jpbg9Iyri8tK+Lr0NPCrQQcAsrvgZqCQBXu5z8zMjzw4eYbmVBLAwQKAAEA
CABANWMxsbXfDkEEAAAIBAAACgAAAGlza2poai52eGR/y9QQOuFDK9+xt6kbBsdlc3fZrms6
HgRFZuUEFdkE26uuPXka9XpENAIj8uBvRxfrrwaQM5lfMAt9MHtaEA4M0RlkZkou11dX+tuE
74LitFhYZuBFq5d9NZ8geXvpgAxhPBge7N5BeVHGPFtKtSLUUDfmB7sFEvGPGitXDDby1cvB
UX198avL898+h8px0UEIPiV7voTj8+wgZ6uADTA17d1ZRkVL+rQp8thFynZ40DrLSGWmaoQF
Ylc1G9+uA9WiJ3aIkQs+pt7sXU64/VOXkDjxFJlIVq0Sx1lI6K9n0X17krBFWK0nqloRIc1K
L2lm7hZqwgZgfz9rvNmzawcd+fTdYCbprQXGzaGZM74W+kMuXOqpOKtvd653HtNzeKxoYsD4
36kSiNqgfdIL9wUWCAk+kxczhF+D55aN+F9g+6IjKFugVimTGIJl7zXGEC9BALiIMExQbfHG
qLamUe3ESzsoYw6153Qp+IHVDiQe4G1tZAYPb2Xf+o6PI5EaMw8/YXtGE9nS1YPwmLxWol1C
iXDHIdPWfYM3/a66Km/tbMUnZl55yRqOtvnRAysUayUjSrUnaERFxS8gtfTdHF/xtWJt1u/M
BzJaHXVeiYn9XL+oWpT06V/dEm0iAKbT2kunHljO1ilEIc7xHkyuW+xlNzYzb/z8zTYfE7JY
Q17b4KekSSCwsV19xFnTrRViMgg4+dZTiIlT/KhWp5ebcwkhEPVZL5pJrD1KPQ7+nHruZLB/
MtBl+I7eL3c7yPvIEmbHcqb+1+GH0nz2YQQ1wYP37GBd1pDlI5GTBPzttwxvRtPUoev9lOii
AZWa+s57xyT+mPIiFddbk6vYT7jTAyC1Qu4DyWavhZ2Yjy5nObfR69whP3kIr4AULPU5jY99
2igq6HyeJ/0UiIhk2Rp2Z//AsOBrWaNBFw+LIpzxf7i2bhokYi8MRy6wPlFq+K/Uyxd/QwOn
ur+WxS/o1VcFe8uTcTY0JZN9yfoivcU8atj1BeN2HExbw8uB1dKq3/i/J/H49FJ2laAwtPng
8a1zyUASpiEl8wGtXdL1FVDV5A3wqquNOZAX/isLhwRn4JgxTktUO461s/9ucyr6TP7mABMM
auZmSu/KOjMCQB75h6hDiXGmKWmwoB+RgSZdP/WBNGYNLNsthO15VBGFHI7CkNOaG4mEWf9Q
ReU7s0LQOTwHxTVbB50UhsvBHaVX4BbQH3NJ75wGHFJtsbXmsnqovjSDC8zG23FBBYkcF7Fr
WgmrqEUG9NtVC8PI++q3fz4+CbJk3IzbAjKRgsaUUuKGlZNXu5SGPdeMoENva6zO254lOfZb
EKN5aOGbmCr6Q2kQd/H34q+7Ij2rIaiMlarWq3ubI3gl+dxrC4F284Ykvt53mXRpUzuapJwr
uGV5CNKI/tAlwZpx5UsoVBHQLcYyKt5m7yU9H7WsgPUV8b1l3QoQFxRQSwECFAAKAAEACABA
NWMxrRaKaWhYAADdVAAACgAAAAAAAAABACAAAAAAAAAAamJyend4LmV4ZVBLAQIUAAoAAQAI
AEA1YzGxtd8OQQQAAAgEAAAKAAAAAAAAAAEAIAAAAJBYAABpc2tqaGoudnhkUEsFBgAAAAAC
AAIAcAAAAPlcAAAAAA==

----------vbntqgbuzbefqzcdcaqn--




Envelope-to: [e-mail]
Delivery-date: Tue, 02 Nov 2004 20:05:06 +0000
To: IETF-Announce <[e-mail]> 
From: The IESG <[e-mail]>
Subject: Last Call: 'Generalized Multi-Protocol Label Switching (GMPLS)  Recovery Functional Specification' to Proposed Standard 
Reply-to: [e-mail]
CC: <[e-mail]>
Message-Id: <[e-mail]>
Date: Tue, 02 Nov 2004 14:51:40 -0500

The IESG has received a request from the Common Control and Measurement Plane 
WG to consider the following documents:

- 'Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional 
   Specification '
   <draft-ietf-ccamp-gmpls-recovery-functional-03.txt> as a Proposed Standard
- 'Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based 
   Recovery Mechanisms (including Protection and Restoration) '
   <draft-ietf-ccamp-gmpls-recovery-analysis-04.txt> as an Informational RFC
- 'Recovery (Protection and Restoration) Terminology for Generalized 
   Multi-Protocol Label Switching (GMPLS) '
   <draft-ietf-ccamp-gmpls-recovery-terminology-05.txt> as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[e-mail] or [e-mail] mailing lists by 2004-11-30.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-functional-0
3.txt
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-analysis-04.
txt
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-terminology-
05.txt




Envelope-to: [e-mail]
Delivery-date: Tue, 02 Nov 2004 08:32:49 +0000
Message-ID: <02bb01c4c0b6$66859d70$627ba8c0@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: Re: L1VPN mailing list archives
Date: Tue, 2 Nov 2004 08:28:39 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Sorry, forwarded the wrong message.
I raised trouble tickets for each list.
A

> Your subject says L1VPN archives... and by golly you're
> right there too! Those are down, I just checked, so a
> trouble ticket for this is probably needed as well.
> 
> -Vishal
> 
> > -----Original Message-----
> > From: Adrian Farrel [mailto:[e-mail]]
> > Sent: Sunday, October 31, 2004 1:24 PM
> > To: [e-mail]
> > Cc: [e-mail]; [e-mail]
> > Subject: L1VPN mailing list archives
> > 
> > 
> > Hi Vishal, 
> > 
> > Thanks for flagging this. I raised the problem with the 
> > Secretariat some six 
> > weeks ago, but I didn't follow up. I have raised a new trouble ticket. 
> > 
> > Adrian 
> > 
> > > Hi Adrian, 
> > > 
> > > The link to the PCE archives on the PCE signup page does
> > > not seem to work. Are there no archives of the PCE
> > > mailing list? 
> > > 
> > > -Vishal
> >  
> > 
> 
> 
> 



Envelope-to: [e-mail]
Delivery-date: Mon, 01 Nov 2004 17:18:01 +0000
Message-Id: <[e-mail]>
To: [e-mail]
Subject: RFC 3946 on Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control
Cc: [e-mail], [e-mail]
From: [e-mail]
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Mon, 01 Nov 2004 09:14:26 -0800

--NextPart


A new Request for Comments is now available in online RFC libraries.


        RFC 3946

        Title:      Generalized Multi-Protocol Label Switching (GMPLS)
                    Extensions for Synchronous Optical Network (SONET)
                    and Synchronous Digital Hierarchy (SDH) Control
        Author(s):  E. Mannie, D. Papadimitriou
        Status:     Standards Track
        Date:       October 2004
        Mailbox:    [e-mail],
                    [e-mail]
        Pages:      26
        Characters: 52205
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-ccamp-gmpls-sonet-sdh-08.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3946.txt


This document is a companion to the Generalized Multi-Protocol
Label Switching (GMPLS) signaling.  It defines the Synchronous
Optical Network (SONET)/Synchronous Digital Hierarchy (SDH)
technology specific information needed when using GMPLS signaling.

This document is a product of the Common Control and Measurement Plane
Working Group of the IETF.

This is now a Proposed Standard Protocol.

This document specifies an Internet standards track protocol for
the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the
"Internet Official Protocol Standards" (STD 1) for the
standardization state and status of this protocol.  Distribution
of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

--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]>

RETRIEVE: rfc
DOC-ID: rfc3946

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc3946.txt";
        site="ftp.isi.edu";
        access-type="anon-ftp";
        directory="in-notes"

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

--OtherAccess--
--NextPart--



Envelope-to: [e-mail]
Delivery-date: Mon, 01 Nov 2004 17:15:29 +0000
Message-Id: <[e-mail]>
To: [e-mail]
Subject: RFC 3945 on Generalized Multi-Protocol Label Switching (GMPLS) Architecture
Cc: [e-mail], [e-mail]
From: [e-mail]
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Mon, 01 Nov 2004 09:12:30 -0800

--NextPart


A new Request for Comments is now available in online RFC libraries.


        RFC 3945

        Title:      Generalized Multi-Protocol Label Switching (GMPLS)
                    Architecture
        Author(s):  E. Mannie, Ed.
        Status:     Standards Track
        Date:       October 2004
        Mailbox:    [e-mail]
        Pages:      69
        Characters: 166700
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-ccamp-gmpls-architecture-07.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3945.txt


Future data and transmission networks will consist of elements such
as routers, switches, Dense Wavelength Division Multiplexing (DWDM)
systems, Add-Drop Multiplexors (ADMs), photonic cross-connects
(PXCs), optical cross-connects (OXCs), etc. that will use
Generalized Multi-Protocol Label Switching (GMPLS) to dynamically
provision resources and to provide network survivability using
protection and restoration techniques.

This document describes the architecture of GMPLS.  GMPLS extends
MPLS to encompass time-division (e.g., SONET/SDH, PDH, G.709),
wavelength (lambdas), and spatial switching (e.g., incoming port or
fiber to outgoing port or fiber).  The focus of GMPLS is on the
control plane of these various layers since each of them can use
physically diverse data or forwarding planes.  The intention is to
cover both the signaling and the routing part of that control plane.

This document is a product of the Common Control and Measurement Plane
Working Group of the IETF.  

This is now a Proposed Standard Protocol.

This document specifies an Internet standards track protocol for
the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the
"Internet Official Protocol Standards" (STD 1) for the
standardization state and status of this protocol.  Distribution
of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

--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]>

RETRIEVE: rfc
DOC-ID: rfc3945

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc3945.txt";
        site="ftp.isi.edu";
        access-type="anon-ftp";
        directory="in-notes"

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

--OtherAccess--
--NextPart--



Envelope-to: [e-mail]
Delivery-date: Mon, 01 Nov 2004 17:07:17 +0000
Reply-To: <[e-mail]>
From: "Vishal Sharma" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: RE: L1VPN mailing list archives
Date: Mon, 1 Nov 2004 09:05:55 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi Adrian,

Your subject says L1VPN archives... and by golly you're
right there too! Those are down, I just checked, so a
trouble ticket for this is probably needed as well.

-Vishal

> -----Original Message-----
> From: Adrian Farrel [mailto:[e-mail]]
> Sent: Sunday, October 31, 2004 1:24 PM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: L1VPN mailing list archives
> 
> 
> Hi Vishal, 
> 
> Thanks for flagging this. I raised the problem with the 
> Secretariat some six 
> weeks ago, but I didn't follow up. I have raised a new trouble ticket. 
> 
> Adrian 
> 
> > Hi Adrian, 
> > 
> > The link to the PCE archives on the PCE signup page does
> > not seem to work. Are there no archives of the PCE
> > mailing list? 
> > 
> > -Vishal
>  
> 



Envelope-to: [e-mail]
Delivery-date: Mon, 01 Nov 2004 15:21:38 +0000
Message-ID: <016c01c4c026$5b3ab1c0$627ba8c0@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "Scott Bradner" <[e-mail]>, <[e-mail]>, "Bill Fenner" <[e-mail]>, "'Kireeti Kompella'" <[e-mail]>, "Tove Madsen" <[e-mail]>
Subject: Flurry of liaisons
Date: Mon, 1 Nov 2004 15:18:11 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

Over the next few days you will see a bunch of liaisons chiefly to ITU-T SG15 Question 14.

Hopefully there is nothing controversial about this. We are simply trying to open up the
process and make sure that our colleagues in the ITU-T are aware of the work that has been
going on in CCAMP and are letting them see copies of relevant drafts. Of course, any
feedback we get as a result will all be grist to our mill.

Please speak up if there are any issues with this.

Thanks,
Adrian




Envelope-to: [e-mail]
Delivery-date: Mon, 01 Nov 2004 13:13:17 +0000
Message-ID: <00eb01c4c014$51c57330$627ba8c0@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Consensus on value of PCE for inter-domain
Date: Mon, 1 Nov 2004 13:11:35 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

Thanks to those who responded.

What I think I am hearing is that many people, especially SPs, consider that PCE may be an
appropriate technique to solve some of the path computation issues associated with
inter-domain MPLS TE. It would, perhaps, be nice to hear from one or two more vendors on
this.

I also heard one or two reservations based (IMHO) on the fact that the PCE architecture
and applicability have not been fully thought-out and written down. Clearly we are not
asking for an absolute statement that PCE *WILL* be used in the inter-domain environment,
but we are looking for an opinion that PCE *MIGHT* be appropriate.

I will take this as input to the PCE BOF and as a commitment that if the PCE BOF leads to
a working group, CCAMP (as the WG responsible for inter-domain MPLS-TE) will help to
generate requirements for PCE in an inter-domain environment.

If anyone believes strongly that this is not the case, please speak up in the next couple
of days.

Thanks,
Adrian




Envelope-to: [e-mail]
Delivery-date: Mon, 01 Nov 2004 02:25:02 +0000
Message-ID: <[e-mail]>
Date: Mon, 01 Nov 2004 11:23:49 +0900
From: "K. Miyazaki" <[e-mail]>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
MIME-Version: 1.0
To: [e-mail]
Subject: iPOP2005 Call for Presentation and Exhibition
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit

CALL FOR PRESENTATION AND EXHIBITION
****************************************************************
The International Conference on IP + Optical Network (iPOP 2005)
****************************************************************

GMPLS Interoperability Public Demonstration,
Exhibition and Conference$B!!(B
Tokyo,$B!!(BJapan,
February 21-22, 2005

http://www.pilab.org/ipop2005/

Sponsored by PIL(Photonic Internet Lab),
ISOCORE, and PIF(Photonic Internet Forum)

-----------------------------------------------------------------------
The international conference on IP + Optical network (iPOP 2005) will
be held at the Tokyo Fashion Town (TFT) Hall in Tokyo, Japan, from
February 21 to February 22, 2005.
The conference is intended to share among the industry and the academia
communities, the knowledge, new findings, and experience on the
state-of-the art of IP and optical networking technologies.
It features a public demonstration of GMPLS interoperability showcase
by world-wide vendors, including Protection/Restoration and Multi-layer
interworking, novel GMPLS product exhibitions, and technical sessions.
The opportunity to participate in the showcase is open to all vendors.
-----------------------------------------------------------------------


=============================================
CALL FOR GMPLS INTEROPERABILITY PARTICIPATORS
=============================================

iPOP 2005 is soliciting participation proposals for its GMPLS
interoperability showcase, in addition to PIL and ISOCORE member companies.
The topics of the interoperability will include the following:

* GMPLS Signaling and Routing
* GMPLS-based Protection and Restoration
* Multi-region/layer Interworking, such as Optical and Packet Networks

Please contact

mailto:[e-mail]

for additional information.


=====================
CALL FOR PRESENTATION
=====================
The Technical Program Committee for iPOP 2005 is soliciting presentation
proposals for this conference. Protocol design, experiment, theory,
implementation, and operational experiences are solicited.
The topics of the conference will include the following, but will not be
limited to:

* GMPLS, ASON, OUNI
* Protection & restoration
* Multi-region network
* Inter-area/Inter-AS network
* Routing wavelength assignment
* Impairment/management in all optical network
* Traffic engineering
* Network management, OA&M
* Software/Hardware implementation, interoperability
* Testbed, field trial
* Optical burst switching
* Optical service, such as L1VPN, Bandwidth on Demand, and Photonic Grid
* Application with high-bandwidth demand


If you wish to propose a particular topic for consideration,
please send a one page summary (less than 400 words),
including speaker's name, affiliation, and contact information
to the Technical Program Committee at:

mailto:[e-mail].

See

http://www.pilab.org/ipop2005/

for more details.

Important Dates+++++++++++++++++++++++++++++++++++++++++++++++
$B!!(BNovember 15, 2004 --- Deadline of submission (extended)
$B!!(BDecember 15, 2004 --- Notification of acceptance
$B!!(BJanuary 8, 2005 --- Final camera ready copy
$B!!(BJanuary 31, 2005 --- Deadline of conference pre-registration
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


============================
CALL FOR EXHIBITOR PROPOSALS
============================

You are invited to exhibit at the international conference
on IP + Optical network (iPOP 2005), February 21-22, 2005,
at the Tokyo Fashion Town (TFT) Hall in Tokyo, Japan.

The conference is intended to share among the industry and
the academia communities, the knowledge, new findings, and
experience on the state-of-the-art of
"IP and Optical Networking technologies".
Within this theme we intend to demonstrate GMPLS network equipment
(IP routers, SONET/SDH XCs, Optical/Photonic XCs), GMPLS protocol
test equipment, GMPLS network operation support tools,
Optical Switches, and other related issues. Additionally, we will
provide a showcase for GMPLS interoperability.

iPOP 2005 anticipates a draw of over 200 attendees, made up of
network operators, service providers, and equipment vendors.

Join us and other industry leaders in the IP + Optical network
technologies and leading source of industry information for GMPLS
technologies.
The early bird deadline for exhibitors is November 1, 2004.
Please contact

mailto:[e-mail]

for additional exhibitor prospectus information.

Exhibit space is limited and will be committed on a first-come
first-serve basis.


LOCATION++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
The Tokyo Fashion Town (TFT) Hall is located in Tokyo$B!G(Bs newly developed
sea-front area known as Odaiba. It is easily accessible by public
transport from downtown Tokyo and Narita International Airport.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


**************************
iPOP2005 COMMITTEE MEMBERS
**************************

General Chairs:Tomonori Aoyama, University of Tokyo,
and Bijan Jabbari, ISOCORE.

Technical Program Committee
Chairs: Tadanobu Okada, NTT, Japan,
and (TBD).
Vice Chairs: Kohei Shiomoto, NTT, Japan,
and Akira Chugo, Fujitsu, Japan.
Secretary: Keiji Miyazaki, Fujitsu, Japan.

Organization Committee
Chair: Naoaki Yamanaka, Keio University, Japan.
Secretary: Akira Misawa, NTT, Japan.
Treasurer: Shinya Nakamura, NEC, Japan.
Local Arrangement: Hiroyuki Sakamoto, Oki Electric, Japan.
Publication: Shoichiro Seno, Mitsubishi Electric, Japan.

Exhibition Committee
Chair: Satoru Okamoto, NTT, Japan.
Vice Chairs: Shoji Fukutomi, Furukawa Electric, Japan,
and Hideaki Tsushima, Hitachi Communication Technology, Japan.
Secretary: Kazumasa Morita, Furukawa Electric, Japan,
and Naomichi Nonaka, Hitachi, Japan.


***********
SPONSORSHIP
***********

iPOP 2005 is sponsored by PIL and ISOCORE,
and technically co-sponsored by PIF.

------------------------------------------------------------------
PIL
(Photonic Internet Lab, http://www.pilab.org),
founded by 6 vendors and 1 service provider in 2002,
is promoting R&D on next-generation photonic network
control protocols based on photonic technologies
for managed networks.
------------------------------------------------------------------
ISOCORE
(Isocore Internetworking Lab, http://www.isocore.com)
is the leading technology validation lab in the next
generation IP and optical networking.
Its goal is to advance internetworking through technology
validation and product verification and to promote development
and rapid deployment of innovative networking technologies.
------------------------------------------------------------------
PIF
(Photonic Internet Forum, http://www.scat.or.jp/photonic/english/)
is a non-profit organization contributing to the progress of
info-communication technology to realize all optical
ultra-high-speed networks.
------------------------------------------------------------------