Re: Polling for new WG I-Ds
Dimitri.Papadimitriou@alcatel.be Wed, 23 August 2006 08:42 UTC
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFoJJ-0005ks-Ce for ccamp-archive@ietf.org; Wed, 23 Aug 2006 04:42:05 -0400
Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFoJD-0000JB-E6 for ccamp-archive@ietf.org; Wed, 23 Aug 2006 04:42:05 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from <owner-ccamp@ops.ietf.org>) id 1GFoBD-000CHN-4I for ccamp-data@psg.com; Wed, 23 Aug 2006 08:33:43 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level:
X-Spam-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST,NO_REAL_NAME autolearn=no version=3.1.1
Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from <Dimitri.Papadimitriou@alcatel.be>) id 1GFoBA-000CGa-6V; Wed, 23 Aug 2006 08:33:41 +0000
Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id k7N8XFva019284; Wed, 23 Aug 2006 10:33:15 +0200
In-Reply-To: <004a01c6c4c5$a64fb200$d04c460a@china.huawei.com>
To: Dan Li <danli@huawei.com>
Cc: Adrian Farrel <adrian@olddog.co.uk>, ccamp@ops.ietf.org, owner-ccamp@ops.ietf.org
Subject: Re: Polling for new WG I-Ds
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5 September 26, 2003
Message-ID: <OFD6F45EBD.82EE4615-ONC12571D2.00675B7F-C12571D3.002EFBC9@netfr.alcatel.fr>
From: Dimitri.Papadimitriou@alcatel.be
Date: Wed, 23 Aug 2006 10:33:10 +0200
X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 08/23/2006 10:33:13, Serialize complete at 08/23/2006 10:33:13
Content-Type: text/plain; charset="US-ASCII"
X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 0770535483960d190d4a0d020e7060bd
hi - see inline Dan Li <danli@huawei.com> Sent by: owner-ccamp@ops.ietf.org 21/08/2006 04:01 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, Adrian Farrel <adrian@olddog.co.uk> cc: ccamp@ops.ietf.org, owner-ccamp@ops.ietf.org Subject: Re: Polling for new WG I-Ds Hi Dimitri, Please see in line. Regards, Dan ----- Original Message ----- From: <Dimitri.Papadimitriou@alcatel.be> To: "Adrian Farrel" <adrian@olddog.co.uk> Cc: <ccamp@ops.ietf.org>; <owner-ccamp@ops.ietf.org> Sent: Thursday, August 17, 2006 6:32 AM Subject: Re: Polling for new WG I-Ds > adrian - see in-line > > Adrian Farrel wrote: > > Hi, > > > > As discussed in Montreal, we need to poll for a couple of new WG drafts. > > > > > http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-gmpls-vcat-lcas-04.txt > > > has been updated by the authors to provide further details and > > clarification. > > - ok - > > > > http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-02.txt > > - guess it is v03.txt ? - > > > has been updated since the version discussed in Montreal. > > i am ok in investigating the MP->CP but i have two concerns that imho > should deserve more specific attention to maintain consistency wrt to > CP->MP > > section 2.2: if control is lost for an LSP (during CP failure) how can it > be possible transfer that LSP from the CP -> MP ? [dan] Yes, there is a problem if we still want to use the control plane to do the CP->MP transfer. Unless the transfer is based on the predetermined policy, MP takes the control of the LSP resource directly (no signaling required), but this way should not be discussed in CCAMP. [dp] ok so what's left for this doc ? concerning the MP-driven failover - imho nothing > section 4.4: why the document assumes that both MUST be supported ? in > part. concerning the CP->MP if one does implement current GMPLS signaling > restart/recovery why shall this be mandated ? in brief, the document shall > take into account existing mechanisms and prevent overlaps (with existing > GMPLS mechanisms) > [dan] I think the CP->MP should not be the mandatory requirement. [dp] this is what i thought > hence, it is strongly suggested to identify conditions when such CP->MP is > required (and not an alternative to existing CP mechanisms) b/f > progressing that part > [dan] In order to make the carriers' life easy, when we provide the MP->CP conversion feature, the reverse procedure (CP->MP) may also is needed just simply in case the carriers want to withdraw their previous decision, and they also feel more comfortable with this "undo" function; In order to achieve this, we should have the working control plane. [dp] concerning CP->MP input you provided would be helpful to have carrier's speaking for themselves - now there is indeed a side question shall CCAMP take care about operators that want to step back from GMPLS or more generally any control plane technology (usually concern is how to move forward not backward) > http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutdown-04.txt > > > has been updated as Zafar says in his previous email. > > informational imho - in its current version > > - not sure to understand why the PathErr/Notify can be processed by the > head-end only (what about segment recovery and stitching case) - why only > MBB is possible upon reception (pls use E2E recovery/Segment recovery > capabilities as you address GMPLS networks) > > - compared to path-reopt, error description is identical for the TE link > case which leads to the following point - if errors code/value are the > same how to distinguish them (assuming that the query procedure described > in path-reopt is used during the setup of that LSP) ? - comment is more > for the path-reopt draft than yours but since there is an overlap ... it > must be addressed in a way or another (note that when fully head-end > driven operations look similar but there is a major difference role of > timing and severity of the error code/value) > > - in case shutdown of a protected component link (of a bundle) is > initiated why can't link protection be used ? > > > Please send yes or no for these I-Ds. > > > > Reasons and opinions are also welcomed. > > > > Thanks, > > Adrian > >
- Polling for new WG I-Ds Adrian Farrel
- Re: Polling for new WG I-Ds Richard Rabbat
- Re: Polling for new WG I-Ds Dan Li
- Re: Polling for new WG I-Ds Wataru Imajuku
- Re: Polling for new WG I-Ds Huub van Helvoort
- Re: Polling for new WG I-Ds Diego Caviglia
- RE: Polling for new WG I-Ds Trevor Wilson
- comments on ID-draft-bernstein-ccamp-gmpls-vcat-l… Huub van Helvoort
- Re: Polling for new WG I-Ds Dimitri.Papadimitriou
- RE: comments on ID-draft-bernstein-ccamp-gmpls-vc… Trevor Wilson
- Re: comments on ID-draft-bernstein-ccamp-gmpls-vc… Huub van Helvoort
- Re: Polling for new WG I-Ds Dan Li
- Re: Polling for new WG I-Ds Kenji Kumaki
- Re: Polling for new WG I-Ds Tomohiro Otani
- RE: Polling for new WG I-Ds Zafar Ali (zali)
- RE: Polling for new WG I-Ds LE ROUX Jean-Louis RD-CORE-LAN
- Re: Polling for new WG I-Ds Igor Bryskin
- Re: Polling for new WG I-Ds Eric W Gray
- RE: Polling for new WG I-Ds Dean Cheng (dcheng)
- Re: Polling for new WG I-Ds Tomohiro Otani
- Re: Polling for new WG I-Ds Dimitri.Papadimitriou
- Re: Polling for new WG I-Ds Diego Caviglia
- Re: Polling for new WG I-Ds Diego Caviglia
- RE: Polling for new WG I-Ds Bryskin, Igor
- RE: Polling for new WG I-Ds Drake, John E
- RE: Polling for new WG I-Ds Ong, Lyndon
- RE: Polling for new WG I-Ds Brungard, Deborah A, ALABS
- RE: Polling for new WG I-Ds Bryskin, Igor
- RE: Polling for new WG I-Ds Drake, John E
- Re: Polling for new WG I-Ds Dimitri.Papadimitriou
- RE: Polling for new WG I-Ds Bryskin, Igor
- RE: Polling for new WG I-Ds benjamin.niven-jenkins
- RE: Polling for new WG I-Ds Bryskin, Igor
- RE: Polling for new WG I-Ds Drake, John E
- RE: Polling for new WG I-Ds Drake, John E
- RE: Polling for new WG I-Ds Bryskin, Igor
- RE: Polling for new WG I-Ds Bryskin, Igor
- RE: Polling for new WG I-Ds Brungard, Deborah A, ALABS
- RE: Polling for new WG I-Ds Drake, John E
- RE: Polling for new WG I-Ds Bryskin, Igor
- Re: Polling for new WG I-Ds Richard Rabbat
- RE: Polling for new WG I-Ds Bryskin, Igor
- RE: Polling for new WG I-Ds Bryskin, Igor
- RE: Polling for new WG I-Ds Drake, John E
- RE: Polling for new WG I-Ds Drake, John E
- RE: comments on ID-draft-bernstein-ccamp-gmpls-vc… Trevor Wilson
- New WG I-Ds Adrian Farrel