RE: comment on draft-takacs-ccamp-revertive-ps-01

"Attila Takacs" <Attila.Takacs@ericsson.com> Thu, 31 July 2008 17:50 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 B05913A6915 for <ietfarch-ccamp-archive@core3.amsl.com>; Thu, 31 Jul 2008 10:50:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.698
X-Spam-Level:
X-Spam-Status: No, score=-4.698 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, 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 bqJqyJ59f5Rn for <ietfarch-ccamp-archive@core3.amsl.com>; Thu, 31 Jul 2008 10:50:45 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BECD03A6808 for <ccamp-archive@ietf.org>; Thu, 31 Jul 2008 10:50:44 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-ccamp@ops.ietf.org>) id 1KOcDp-0008gO-22 for ccamp-data@psg.com; Thu, 31 Jul 2008 17:45:53 +0000
Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from <Attila.Takacs@ericsson.com>) id 1KOcDk-0008fa-R5 for ccamp@ops.ietf.org; Thu, 31 Jul 2008 17:45:51 +0000
Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 16E2D2103A; Thu, 31 Jul 2008 19:45:47 +0200 (CEST)
X-AuditID: c1b4fb3e-aa991bb000004ec0-1f-4891fa4a701f
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 9D4EE206BC; Thu, 31 Jul 2008 19:45:46 +0200 (CEST)
Received: from esealmw116.eemea.ericsson.se ([153.88.200.7]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Jul 2008 19:45:46 +0200
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: comment on draft-takacs-ccamp-revertive-ps-01
Date: Thu, 31 Jul 2008 19:45:46 +0200
Message-ID: <53CCFDD6E346CB43994852666C210E9104B145E6@esealmw116.eemea.ericsson.se>
In-Reply-To: <00275A5B436CA441900CB10936742A38DFAC6C@FRVELSMBS22.ad2.ad.alcatel.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: comment on draft-takacs-ccamp-revertive-ps-01
Thread-Index: AcjzK8ZcRl0pW3mYTZOYSECZLMfVBwABeq2A
References: <00275A5B436CA441900CB10936742A38DFAC6C@FRVELSMBS22.ad2.ad.alcatel.com>
From: "Attila Takacs" <Attila.Takacs@ericsson.com>
To: "PAPADIMITRIOU Dimitri" <Dimitri.Papadimitriou@alcatel-lucent.be>, <ccamp@ops.ietf.org>
X-OriginalArrivalTime: 31 Jul 2008 17:45:46.0335 (UTC) FILETIME=[43061EF0:01C8F335]
X-Brightmail-Tracker: AAAAAA==
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
List-ID: <ccamp.ops.ietf.org>

Hi Dimitri,
Thanks for the comments, please see inline!
Attila

> comments on this doc:
> 
> 1. the document should leave outside its scope signaling of 
> the hold-off timer.
> 

So you are suggesting to go with alternative 2.

> reason: this timer is used for multi-layer recovery while it 
> would be advisable to have a more detailed understanding 
> about the needs before extending the protection object
> 

Even in a single layer case one has to set the hold-off timer properly
(e.g., it may be see on a per LSP bases so it can limit the load of the
protection switching process).
I do agree in that muli-layer recovery needs to be properly understood.
On the other hand, from actual extensions point of view, I'm not sure if
there is more to be done than to carry the respective timers. The
complexity of multi-layer considerations relies in the way the proper
values are derived which is probably outside the scope of the extension
doc.

> 2. segment protection: it should address first RFC4872 and 
> then see how it could be applied to segment protection 
> because different segments can have different WTR (i.e. 
> multiple protection object could be included because race 
> condition can appear when protected segment overlap and a 
> failure on another segment occurs on another segment while 
> the other is ready to the reverted).
> 
> example:--A---B---C---D--
>           |   +   |   +
>            -E-+---    +
>               +       +
>               +++++++++
> 
> B-C fails -> recovery segment B-D, then A-B fails 
> 

Agreed, e2e protection seems to be straightforward, while for segment
protection multiple timers may be needed. 

> thanks,      
> -d.
> 
>