Re: CCAMP Protection/Restoration Design Team

Ben Mack-Crane <Ben.Mack-Crane@tellabs.com> Tue, 26 February 2002 16:20 UTC

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 26 Feb 2002 08:25:19 -0800
Message-ID: <3C7BB5EA.2EEC7BF7@tellabs.com>
Date: Tue, 26 Feb 2002 10:20:58 -0600
From: Ben Mack-Crane <Ben.Mack-Crane@tellabs.com>
MIME-Version: 1.0
To: Kireeti Kompella <kireeti@juniper.net>
CC: ccamp@ops.ietf.org
Subject: Re: CCAMP Protection/Restoration Design Team
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Kireeti,

As I've mentioned before, the design team should also consider
draft-ietf-mpls-recovery-frmwrk-03.txt when generating a terminology
document.

Regards,
Ben

Kireeti Kompella wrote:
> 
> 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.
============================================================
The information contained in this message may be privileged 
and confidential and protected from disclosure.  If the 
reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to 
the intended recipient, you are hereby notified that any 
reproduction, dissemination or distribution of this 
communication is strictly prohibited. If you have received 
this communication in error, please notify us immediately by 
replying to the message and deleting it from your computer.

Thank you.
Tellabs
============================================================