FW: draft-rhodes-rsvp-recovery-signaling-00
David McWalter <DMcW@dataconnection.com> Wed, 24 September 2008 12:55 UTC
Return-Path: <owner-ccamp@ops.ietf.org>
X-Original-To: ietfarch-ccamp-archive@core3.amsl.com
Delivered-To: ietfarch-ccamp-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03F3E28C34B for <ietfarch-ccamp-archive@core3.amsl.com>; Wed, 24 Sep 2008 05:55:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.495
X-Spam-Level:
X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fu8qClU2FlGl for <ietfarch-ccamp-archive@core3.amsl.com>; Wed, 24 Sep 2008 05:54:58 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 74E8C3A6D91 for <ccamp-archive@ietf.org>; Wed, 24 Sep 2008 05:54:58 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-ccamp@ops.ietf.org>) id 1KiTm2-0002vb-W4 for ccamp-data@psg.com; Wed, 24 Sep 2008 12:47:18 +0000
Received: from [192.91.191.8] (helo=smtp2.dataconnection.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from <DMcW@dataconnection.com>) id 1KiTlv-0002ug-OS for ccamp@ops.ietf.org; Wed, 24 Sep 2008 12:47:17 +0000
Received: from enfimail2.datcon.co.uk ([172.18.10.19]) by smtp2.dataconnection.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Sep 2008 13:47:10 +0100
Received: from ENFIMBOX1.ad.datcon.co.uk ([172.18.10.27]) by enfimail2.datcon.co.uk with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Sep 2008 13:47:10 +0100
Received: from ENFIMBOX1.ad.datcon.co.uk ([172.18.10.27]) by ENFIMBOX1.ad.datcon.co.uk ([172.18.10.27]) with mapi; Wed, 24 Sep 2008 13:47:10 +0100
From: David McWalter <DMcW@dataconnection.com>
To: "ccamp@ops.ietf.org" <ccamp@ops.ietf.org>
CC: Andrew Rhodes <Andrew.Rhodes@dataconnection.com>, Nic Neate <Nic.Neate@dataconnection.com>
Date: Wed, 24 Sep 2008 13:47:09 +0100
Subject: FW: draft-rhodes-rsvp-recovery-signaling-00
Thread-Topic: draft-rhodes-rsvp-recovery-signaling-00
Thread-Index: Acj3o4DOGW3WZ0v5Q3eH38o4DzTYjwVSg6hQBFU8a5A=
Message-ID: <44EE1E31095AE349AC6C3C0B69FFBF025C56A70144@ENFIMBOX1.ad.datcon.co.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 24 Sep 2008 12:47:10.0321 (UTC) FILETIME=[A8F79610:01C91E43]
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
List-ID: <ccamp.ops.ietf.org>
Dear all, We propose this update to RSVP recovery signaling. Comments would be welcome. Andrew Rhodes, Nic Neate, David McWalter. http://www.ietf.org/internet-drafts/draft-rhodes-ccamp-rsvp-recovery-fix-00.txt Title: RSVP-TE Recovery Signaling Fixes Abstract: This document updates the ASSOCIATION object used in RSVP-TE signaling of End-to-End and Segment Recovery. This document solves problems with existing Segment Recovery procedures, and also makes possible recovery paths that cross addressing domain boundaries. -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of David McWalter Sent: 02 September 2008 12:23 To: ccamp@ops.ietf.org Cc: Andrew Rhodes; Nic Neate Subject: FW: draft-rhodes-rsvp-recovery-signaling-00 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.
- draft-rhodes-rsvp-recovery-signaling-00 David McWalter
- FW: draft-rhodes-rsvp-recovery-signaling-00 David McWalter
- FW: draft-rhodes-rsvp-recovery-signaling-00 David McWalter