CCAMP Protection/Restoration Design Team

[Kireeti Kompella <[e-mail]>]

Hi Folks,

I'd like to thank all of you who volunteered for this work.  To keep
the team small and effective, not everyone who volunteered could
participate directly.  Note that you can (and should) participate
through the CCAMP WG, by giving suggestions/feedback to the DT, and,
if deemed necessary, by proposing alternate documents.

Finally, note that the design team is _just another set of authors_.
The document(s) they produce are subject to WG consensus to progress
to WG documents and beyond.

Here's the Protection/Restoration Design Team.  They have been on
the job for a little over a month now.

Deborah Brungard
Sudheer Dharanikota
Jonathan Lang
Guangzhi Li
Eric Mannie
Dimitri Papadimitriou
Bala Rajagopalan
Yakov Rekhter

Sudheer is the team lead.

Their charter ("you" in what follows refers to the DT):

a) read drafts re protection/restoration in CCAMP, IPO and MPLS.
   These include (but are not limited to :-)):

*******	draft-ietf-tewg-restore-hierarchy-00.txt *******

	draft-bala-protection-restoration-signaling-00.txt
	draft-bala-restoration-signaling-01.txt
	draft-ietf-ipo-carrier-requirements-00.txt (Section 10)
	draft-kini-restoration-shared-backup-01.txt
	draft-li-shared-mesh-restoration-01.txt
	draft-many-optical-restoration-01.txt
	draft-suemura-protection-hierarchy-00.txt
	draft-ylee-protection-occ-00.txt
	-----------------------------------------------------
	draft-atlas-rsvp-local-protect-interop-02.txt
	draft-chang-mpls-path-protection-03.txt
	draft-chang-mpls-rsvpte-path-protection-ext-02.txt
	draft-owens-crldp-path-protection-ext-01.txt

   The first draft is the requirements for Protection & Restoration
   produced by the TEWG Design Team.  Functionality that you come up
   with should satisfy these requirements; stuff that you come up
   with that either goes beyond these requirements or doesn't meet
   some of them should be called out so that we can re-evaluate.

   The drafts below the line may be MPLS-specific, so they may or may
   not apply.

| AD's comment: For the first round... please refrain as much as possible
| from going beyond the requirements specified in the first draft.  That
| document restricted itself (on purpose) to requirements that are felt
| to be realistic for real operators and in the reasonably short term.
| So that is the scope you should be working in.

b) produce a terminology document, preferably using ITU-T terminology,
   but having a decoder ring to translate to terminology in current
   drafts as well as the TE WG document
c) produce an interim analysis document, comparing and contrasting
   approaches (i.e., the above drafts, published and ongoing work
   at the ITU/T1-X1/...)

| AD's comment: And be careful. Leave the ITU and T1X1-... etc work in
| those organisations if that is where it belongs (and often it does)!

d) produce a more complete version of (c)
e) produce a functional spec delineating
   o What's in scope, out of scope, what's for future study, which of
     the TEWG reqts have been met, which not, and what goes beyond.
   o Overall approach
   o Objects/procedures/... needed in a protocol-independent fashion
f) produce a document detailing the changes for RSVP-TE and CR-LDP
g) produce a document detailing the changes for OSFP-TE and IS-IS-TE

The timeline for (a-c) is before the next IETF (March 1, 2002).

A first cut of (d) and (e) should be available by end of April, 2002.
If there is rough consensus in the CCAMP WG for the approach in (e),
work should then start on (f) and (g).

Kireeti.