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 ============================================================
- Re: CCAMP Protection/Restoration Design Team Yoshihiko SUEMURA
- Re: CCAMP Protection/Restoration Design Team Ben Mack-Crane
- CCAMP Protection/Restoration Design Team Kireeti Kompella
- Re: CCAMP Protection/Restoration Design Team Jean Philippe Vasseur