FW: draft-rhodes-rsvp-recovery-signaling-00

["David McWalter" <DMcW@dataconnection.com>]

Dear all,

This mail contains an udpate on our work with RSVP recovery signaling.

We are considering changes to RSVP signaling that
-  allow segment recovery to use merge points other than egress (rhodes
draft section 3.1)
-  allow inter-domain e2e and SR (section 3.2)

Initially, we will not propose solutions that
-  allow protecting LSPs themselves to be protected (section 3.3)
-  prevent loss of traffic on overlapping repairs (section 3.4)

We shall aim to be backward-compatible with 4872, as we know that
deployments exist.  We shall not aim to be back-compatible with 4873, as
there seem to be fundamental problems, described in sections 3.1 & 4.1
of the rhodes problem draft, below.  We shall try to keep changes
minimal.

We'd be glad to hear opinions, and we would welcome collaboration.

Andrew Rhodes, Nic Neate, David McWalter.
 

-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
Behalf Of David McWalter
Sent: 06 August 2008 10:05
To: ccamp@ops.ietf.org
Cc: Andrew Rhodes; Nic Neate
Subject: draft-rhodes-rsvp-recovery-signaling-00

Dear all,

We would welcome comments on this draft.

Andrew Rhodes, Nic Neate, David McWalter.


http://www.ietf.org/internet-drafts/draft-rhodes-rsvp-recovery-signaling
-00.txt

Title:
Problems observed with RSVP recovery signaling

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.