Re: CCAMP Protection/Restoration Design Team

Jean Philippe Vasseur <jvasseur@cisco.com> Mon, 04 March 2002 17:13 UTC

Envelope-to: ccamp-data@psg.com
Delivery-date: Mon, 04 Mar 2002 09:14:38 -0800
Message-Id: <4.3.2.7.2.20020304181219.065fce40@paris.cisco.com>
Date: Mon, 04 Mar 2002 18:13:54 +0100
To: Kireeti Kompella <kireeti@juniper.net>
From: Jean Philippe Vasseur <jvasseur@cisco.com>
Subject: Re: CCAMP Protection/Restoration Design Team
Cc: ccamp@ops.ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"

Hi Kireeti,

At 18:25 24/02/2002 -0800, 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-ietf-mpls-rsvp-lsp-fastreroute-00.txt.

Thanks.

JP.

>         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.