RE: Agenda updated
Nic Neate <Nic.Neate@dataconnection.com> Tue, 18 November 2008 14:12 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 AB09B3A679C for <ietfarch-ccamp-archive@core3.amsl.com>; Tue, 18 Nov 2008 06:12:05 -0800 (PST)
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 ZfJ99khXs+Ll for <ietfarch-ccamp-archive@core3.amsl.com>; Tue, 18 Nov 2008 06:12:04 -0800 (PST)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4ABF13A6784 for <ccamp-archive@ietf.org>; Tue, 18 Nov 2008 06:12:04 -0800 (PST)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-ccamp@ops.ietf.org>) id 1L2RE5-000IYd-PH for ccamp-data@psg.com; Tue, 18 Nov 2008 14:06:45 +0000
Received: from [192.91.191.38] (helo=enfiets1.dataconnection.com) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.69 (FreeBSD)) (envelope-from <Nic.Neate@dataconnection.com>) id 1L2RDy-000IY7-NU for ccamp@ops.ietf.org; Tue, 18 Nov 2008 14:06:42 +0000
Received: from ENFIMBOX1.ad.datcon.co.uk (172.18.10.27) by enfiets1.dataconnection.com (172.18.4.21) with Microsoft SMTP Server (TLS) id 8.1.311.2; Tue, 18 Nov 2008 14:06:58 +0000
Received: from ENFIMBOX1.ad.datcon.co.uk ([172.18.10.27]) by ENFIMBOX1.ad.datcon.co.uk ([172.18.10.27]) with mapi; Tue, 18 Nov 2008 14:06:39 +0000
From: Nic Neate <Nic.Neate@dataconnection.com>
To: labn - Lou Berger <lberger@labn.net>
CC: "IBryskin@advaoptical.com" <IBryskin@advaoptical.com>, Aria - Adrian Farrel Personal <adrian@olddog.co.uk>, "ccamp@ops.ietf.org" <ccamp@ops.ietf.org>, ALU - Dimitri Papadimitriou <Dimitri.Papadimitriou@alcatel-lucent.be>
Date: Tue, 18 Nov 2008 14:06:34 +0000
Subject: RE: Agenda updated
Thread-Topic: Agenda updated
Thread-Index: AclIPeh+pqzmg/rBStmo5d+6gtIapAA3sOeA
Message-ID: <11DE3EEC54A8A44EAD99D8C0D3FD72075C6A465549@ENFIMBOX1.ad.datcon.co.uk>
References: <11DE3EEC54A8A44EAD99D8C0D3FD72075C6A401662@ENFIMBOX1.ad.datcon.co.uk> <00275A5B436CA441900CB10936742A38015CD737@FRVELSMBS22.ad2.ad.alcatel.com> <E1L1qNx-000HNr-3l@psg.com>
In-Reply-To: <E1L1qNx-000HNr-3l@psg.com>
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
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
List-ID: <ccamp.ops.ietf.org>
Hi Lou, Following up on our conversation in CCAMP. I think you agreed that the "Resource Sharing" association type 2 is not relevant to this discussion. You also said that the intent of the statement from 3.2.1 "processing and identification occur with respect to segment recovery LSPs" is to indicate that the procedures defined in RFC 4872 for setting the association ID to an LSP ID are not used. Instead, a unique identifier should be chosen by the association source (as suggested in our draft). I find this quite a stretch, and think a clarification would improve the chances of interoperability. I'm also concerned with the reuse of association type 1 with different semantics in segment recovery to those defined for end-to-end recovery. Consider the case where a segment recovery LSP is itself end-to-end protected. Then there will be two type 1 association objects, and the merge node must process each differently. How does the implementation you mentioned decide which is which? You also dismissed the other issues raised in draft-rhodes-rsvp-recovery-signaling relating to protection of recovery LSPs and overlaping protection. Please could you respond on the specific technical points raised in the draft? I'd be glad to meet up and discuss this in person while we're in Minneapolis. Thanks, Nic -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of labn - Lou Berger Sent: 16 November 2008 22:46 To: Nic Neate Cc: labn - Lou Berger; IBryskin@advaoptical.com; Aria - Adrian Farrel Personal; ccamp@ops.ietf.org; ALU - Dimitri Papadimitriou Subject: RE: Agenda updated I agree with Dimitri. also, note: 3.2.1. Recovery Type Processing Recovery type processing procedures are the same as those defined in [RFC4872], but processing and identification occur with respect to segment recovery LSPs. Lou At 05:36 PM 11/16/2008, PAPADIMITRIOU Dimitri wrote: >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 > > > >
- Agenda updated Adrian Farrel
- Agenda updated Adrian Farrel
- FW: Agenda updated Nic Neate
- RE: Agenda updated PAPADIMITRIOU Dimitri
- RE: Agenda updated Lou Berger
- RE: Agenda updated Nic Neate
- RE: Agenda updated Nic Neate
- RE: Agenda updated PAPADIMITRIOU Dimitri
- RE: Agenda updated Lou Berger