IETF Logo Mail Archive

RE: Agenda updated

"PAPADIMITRIOU Dimitri" <Dimitri.Papadimitriou@alcatel-lucent.be> Sun, 16 November 2008 22:42 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 334713A68AF for <ietfarch-ccamp-archive@core3.amsl.com>; Sun, 16 Nov 2008 14:42:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.698
X-Spam-Level:
X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, 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 ihZysVqbRatR for <ietfarch-ccamp-archive@core3.amsl.com>; Sun, 16 Nov 2008 14:42:26 -0800 (PST)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AA47C3A6358 for <ccamp-archive@ietf.org>; Sun, 16 Nov 2008 14:42:23 -0800 (PST)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-ccamp@ops.ietf.org>) id 1L1qF4-000Gr0-4e for ccamp-data@psg.com; Sun, 16 Nov 2008 22:37:18 +0000
Received: from [64.208.49.5] (helo=smail6.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from <Dimitri.Papadimitriou@alcatel-lucent.be>) id 1L1qEy-000GqN-QV for ccamp@ops.ietf.org; Sun, 16 Nov 2008 22:37:15 +0000
Received: from FRVELSBHS06.ad2.ad.alcatel.com ([155.132.6.78]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id mAGMaxar021955; Sun, 16 Nov 2008 23:36:59 +0100
Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.56]) by FRVELSBHS06.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Sun, 16 Nov 2008 23:36:59 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Agenda updated
Date: Sun, 16 Nov 2008 23:36:59 +0100
Message-ID: <00275A5B436CA441900CB10936742A38015CD737@FRVELSMBS22.ad2.ad.alcatel.com>
In-Reply-To: <11DE3EEC54A8A44EAD99D8C0D3FD72075C6A401662@ENFIMBOX1.ad.datcon.co.uk>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Agenda updated
Thread-Index: AclBEdrEXjU0mOCKQ3CvjSu7MB8uLADwUelgANoLACA=
References: <11DE3EEC54A8A44EAD99D8C0D3FD72075C6A401662@ENFIMBOX1.ad.datcon.co.uk>
From: PAPADIMITRIOU Dimitri <Dimitri.Papadimitriou@alcatel-lucent.be>
To: Nic Neate <Nic.Neate@dataconnection.com>, labn - Lou Berger <lberger@labn.net>, IBryskin@advaoptical.com, Aria - Adrian Farrel Personal <adrian@olddog.co.uk>
Cc: ccamp@ops.ietf.org
X-OriginalArrivalTime: 16 Nov 2008 22:36:59.0041 (UTC) FILETIME=[D62E7910:01C9483B]
X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
List-ID: <ccamp.ops.ietf.org>

nick,

you mention:

"3.1 Association between LSPs in different sessions

   Segment recovery protecting LSPs may have a different endpoint
   address from the corresponding protected LSP.  The protected and
   protecting LSPs are therefore in different Sessions.  The Association
   object of type 1 (recovery) is not effective in this case, as the
   Association ID can only associate to an LSP ID within the same
   Session."

but segment recovery makes use of:

"9.1. New Association Type Assignment


   IANA has made the following assignment to the "Association Types"
   Registry (see [RFC4872]) in the "ASSOCIATION (object)" section of the
   "RSVP PARAMETERS" registry located at
   http://www.iana.org/assignments/rsvp-parameters.

      Value       Type
      -----       ----
        2         Resource Sharing (R) [RFC4873]" 

and states:

"Consider the following topology:

                        A---B---C---D---E---F
                                 \     /
                                  G---I

   In this topology, end-to-end protection and recovery is not possible
   for an LSP going between node A and node F, but it is possible to
   protect/recover a portion of the LSP.  Specifically, if the LSP uses
   a working path of [A,B,C,D,E,F], then a protection or restoration LSP
   can be established along the path [C,G,I,E]." 

[...]

"Segment protection or restoration is signaled using a working LSP and
   one or more segment recovery LSPs.  Each segment recovery LSP is
   signaled as an independent LSP.  Specifically, the Sender_Template
   object uses the IP address of the node originating the recovery path,
   e.g., node C in the topology shown above, and the Session object
   contains the IP address of the node terminating the recovery path,
   e.g., node E shown above.  There is no specific requirement on LSP ID
   value, Tunnel ID, and Extended Tunnel ID."

so where is the issue ?

-d.

> -----Original Message-----
> From: Nic Neate [mailto:Nic.Neate@dataconnection.com] 
> Sent: Friday, November 14, 2008 4:46 PM
> To: labn - Lou Berger; IBryskin@advaoptical.com; 
> PAPADIMITRIOU Dimitri; Aria - Adrian Farrel Personal
> Cc: ccamp@ops.ietf.org
> Subject: FW: Agenda updated
> 
> RFC 4873 authors,
> 
> Just wanted to flag that I'm presenting a problem in segment 
> recovery signaling on Monday, together with a suggested solution.
> 
> Problem statement: 
> http://tools.ietf.org/html/draft-rhodes-rsvp-recovery-signaling-00.
> Suggested fix: 
> http://tools.ietf.org/html/draft-rhodes-ccamp-rsvp-recovery-fix-00.
> 
> 
> Nic
> 
> -----Original Message-----
> From: owner-ccamp@ops.ietf.org 
> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Aria - Adrian 
> Farrel Personal
> Sent: 07 November 2008 19:29
> To: ccamp@ops.ietf.org
> Subject: Agenda updated
> 
> I have made some updates.
> 
> http://www.ietf.org/proceedings/08nov/agenda/ccamp.htm
> 
> Please shout if there further issues.
> 
> Thanks,
> Adrian
> 
>

v2.23.0 | Report a Bug | By Email