Re: [CCAMP] draft-wright-ccamp-op-policy-prot-links

Julien Meuric <julien.meuric@orange.com> Wed, 10 July 2013 15:40 UTC

Return-Path: <julien.meuric@orange.com>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 799EA21F9D4E for <ccamp@ietfa.amsl.com>; Wed, 10 Jul 2013 08:40:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.89
X-Spam-Level:
X-Spam-Status: No, score=-5.89 tagged_above=-999 required=5 tests=[AWL=0.359, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZTeIqV1IZ11X for <ccamp@ietfa.amsl.com>; Wed, 10 Jul 2013 08:40:52 -0700 (PDT)
Received: from p-mail1.rd.orange.com (p-mail1.rd.orange.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id 2C4C421F944F for <ccamp@ietf.org>; Wed, 10 Jul 2013 08:40:52 -0700 (PDT)
Received: from p-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id DA0794103E9 for <ccamp@ietf.org>; Wed, 10 Jul 2013 17:40:50 +0200 (CEST)
Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail1.rd.orange.com (Postfix) with ESMTP id D504A4103E5 for <ccamp@ietf.org>; Wed, 10 Jul 2013 17:40:50 +0200 (CEST)
Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 10 Jul 2013 17:40:50 +0200
Received: from [10.193.71.100] ([10.193.71.100]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 10 Jul 2013 17:40:50 +0200
Message-ID: <51DD8081.4040306@orange.com>
Date: Wed, 10 Jul 2013 17:40:49 +0200
From: Julien Meuric <julien.meuric@orange.com>
Organization: Orange
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7
MIME-Version: 1.0
To: ccamp@ietf.org
References: <02c101ce7a9a$04c7ac70$0e570550$@olddog.co.uk> <B3B6FD81D3159A45B5421AF9DD500F88D6D2E5C4@ENFICSMBX1.datcon.co.uk>
In-Reply-To: <B3B6FD81D3159A45B5421AF9DD500F88D6D2E5C4@ENFICSMBX1.datcon.co.uk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 10 Jul 2013 15:40:50.0993 (UTC) FILETIME=[DB127210:01CE7D83]
Subject: Re: [CCAMP] draft-wright-ccamp-op-policy-prot-links
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Jul 2013 15:40:57 -0000

Hi Ben.

Please see below.


On 07/10/2013 10:18, Ben Wright wrote:

[...]
> - Some carriers have policies which mean they are prepared to let some services traverse a link which is temporarily protection-impaired, with the assumption that the link will be repaired at some point.
I agree 100 %. The key-word here is *temporarily*. On the opposite 
TE-LSPs are typically provisioned for rather long times. As a result, I 
do not believe that adding a supplementary short-life link-protection 
state (i.e. "protection-impaired") would bring actual value to initial 
path computation. It is a matter of time scale.
When it comes to traffic re-routing triggered by a failure, traffic 
recovery matters above all and an available link should typically be 
considered, whatever transient state a protected link may be facing.
>    
> - Carrier policy can choose to place some services (for which no protection is required) over a protection-impaired link but avoid using that link for other less-valuable services.  This prevents less valuable services using resources on links which, if repaired, could be used to carry protected traffic.
I guess you meant "for which protection is required". The situation is 
not supposed to last for long. Should provisioning happen over a 
degraded network anyway and chose that link, constrained routing remains 
a proactive way to addresses the issue, re-routing (only once!) is a 
reactive one.

I have also read the I-D and especially the "operator requirements" section:
- R1 brings me back to my comment above: I do not feel comfortable in 
constraining path computation by temporary situations that do no affect 
traffic.
- R2 looks really odd to me: except for planed maintenance, I fail to 
see why someone would want to temporarily re-route a perfectly flowing 
traffic, which means accept the traffic impact (twice, even if sub-50 
ms...) and the risk that the new path is not better than the former. 
What prevails on operational networks is typically: "do no touch 
something working properly".

Regards,

Julien