RE: New Version Notification for draft-rhodes-rsvp-recovery-signaling-01

"PAPADIMITRIOU Dimitri" <Dimitri.Papadimitriou@alcatel-lucent.be> Thu, 05 March 2009 16:42 UTC

Envelope-to: ccamp-data0@psg.com
Delivery-date: Thu, 05 Mar 2009 16:43:59 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: New Version Notification for draft-rhodes-rsvp-recovery-signaling-01
Date: Thu, 5 Mar 2009 17:42:35 +0100
Message-ID: <00275A5B436CA441900CB10936742A3801DD758F@FRVELSMBS22.ad2.ad.alcatel.com>
Thread-Topic: New Version Notification for draft-rhodes-rsvp-recovery-signaling-01
Thread-Index: Acmc3n5UWDz/TTfcQ52UgSHFQlBjRQAlPNcAAA9LIxA=
From: "PAPADIMITRIOU Dimitri" <Dimitri.Papadimitriou@alcatel-lucent.be>
To: "Nic Neate" <Nic.Neate@dataconnection.com>, <ccamp@ops.ietf.org>
Cc: "Aria - Adrian Farrel Personal" <adrian@olddog.co.uk>, "Fatai Zhang" <zhangfatai@huawei.com>, "Francesco Fondelli" <francesco.fondelli@gmail.com>, "Fujitsu - Fred Gruman" <fred.gruman@us.fujitsu.com>, "Fujitsu - Snigdho Bardalai" <Snigdho.Bardalai@us.fujitsu.com>

Nic: 

I am a bit afraid that the main discussion will soon become a trilogy
between 

1. actual interpretation of the RFCs (without taking into account
feeback from the list/f2f meetings) 

2. lack of understanding on how to use existing RFCs to implement
certain scenarios

3. protocol elements left for further improvement (cf. WTR negotiation
example) 

up to chairs to tell here about the process but usually only point 3. is
in scope of "internet-drafts".

thanks,
-d.
> -----Original Message-----
> From: Nic Neate [mailto:Nic.Neate@dataconnection.com] 
> Sent: Thursday, March 05, 2009 11:53 AM
> To: ccamp@ops.ietf.org
> Cc: Aria - Adrian Farrel Personal; PAPADIMITRIOU Dimitri; 
> Fatai Zhang; Francesco Fondelli; Fujitsu - Fred Gruman; 
> Fujitsu - Snigdho Bardalai
> Subject: FW: New Version Notification for 
> draft-rhodes-rsvp-recovery-signaling-01 
> 
> Hi all,
> 
> Following discussions on the CCAMP mailing list and in 
> Minneapolis, we've updated 
> http://tools.ietf.org/html/draft-rhodes-rsvp-recovery-signalin
g to give a clearer statement of the problems we identified in > GMPLS
recovery signaling.  It covers the following.
> 
> -  Association procedures for segment recovery
> -  Association procedures for inter-domain LSPs
> -  Signaling a recovery LSP that is itself protected
> -  Data loss resulting from overlapping segment recovery LSPs
> -  Assignment of the segment-recording-desired flag (a new 
> but straight-forward issue not yet raised on the mailing list)
> 
> Thanks to those who have helped us clarify these issues.  
> Please let us know if you have further comments on the 
> problem descriptions in the draft.
> 
> The next step will then be to develop solutions to some or 
> all of them, either by progressing 
> draft-rhodes-ccamp-rsvp-recovery-fix or other documents.  As 
> always, further input and collaboration welcome.
> 
> Nic, David and Andrew
> 
> 
> -----Original Message-----
> From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] 
> Sent: 04 March 2009 15:32
> To: David McWalter
> Cc: Andrew Rhodes; Nic Neate
> Subject: New Version Notification for 
> draft-rhodes-rsvp-recovery-signaling-01 
> 
> 
> A new version of I-D, 
> draft-rhodes-rsvp-recovery-signaling-01.txt has been 
> successfuly submitted by David McWalter and posted to the 
> IETF repository.
> 
> Filename:	 draft-rhodes-rsvp-recovery-signaling
> Revision:	 01
> Title:		 Problems observed with RSVP recovery signaling
> Creation_date:	 2009-03-04
> WG ID:		 Independent Submission
> Number_of_pages: 12
> 
> Abstract:
> Implementation experience with RSVP-TE recovery signaling has 
> uncovered some problems.  Associations between LSPs in 
> different sessions are forbidden.  Protecting LSPs cannot 
> themselves be protected.  Overlapping repairs cause loss of 
> traffic.  This draft provides details of these problems for 
> the community to consider.
>                                                               
>                     
> 
> 
> The IETF Secretariat.
> 
> 
>