[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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-signaling 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.