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

Julien Meuric <> Wed, 10 July 2013 15:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 799EA21F9D4E for <>; Wed, 10 Jul 2013 08:40:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.89
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZTeIqV1IZ11X for <>; Wed, 10 Jul 2013 08:40:52 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2C4C421F944F for <>; Wed, 10 Jul 2013 08:40:52 -0700 (PDT)
Received: from (localhost.localdomain []) by localhost (Postfix) with SMTP id DA0794103E9 for <>; Wed, 10 Jul 2013 17:40:50 +0200 (CEST)
Received: from (unknown []) by (Postfix) with ESMTP id D504A4103E5 for <>; Wed, 10 Jul 2013 17:40:50 +0200 (CEST)
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Wed, 10 Jul 2013 17:40:50 +0200
Received: from [] ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Wed, 10 Jul 2013 17:40:50 +0200
Message-ID: <>
Date: Wed, 10 Jul 2013 17:40:49 +0200
From: Julien Meuric <>
Organization: Orange
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7
MIME-Version: 1.0
References: <02c101ce7a9a$04c7ac70$0e570550$> <>
In-Reply-To: <>
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-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 
- 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".