[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: New Version Notification for draft-rhodes-rsvp-recovery-signaling-01
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.
>
>
>