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

Ben Wright <> Fri, 12 July 2013 08:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 91CDD21F9D3B for <>; Fri, 12 Jul 2013 01:28:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6EjyEebhSXne for <>; Fri, 12 Jul 2013 01:28:33 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 837D221F9D49 for <>; Fri, 12 Jul 2013 01:28:31 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.2.342.3; Fri, 12 Jul 2013 09:28:11 +0100
Received: from ([fe80::d5d5:c683:a3be:3a19]) by ([::1]) with mapi id 14.02.0342.003; Fri, 12 Jul 2013 09:28:30 +0100
From: Ben Wright <>
To: Julien Meuric <>, "" <>
Thread-Topic: [CCAMP] draft-wright-ccamp-op-policy-prot-links
Thread-Index: Ac56mV7BgEZX072NQqGt5h3I0qbFZgCRmqqAACbrrYAAV3oEEA==
Date: Fri, 12 Jul 2013 08:28:29 +0000
Message-ID: <>
References: <02c101ce7a9a$04c7ac70$0e570550$> <> <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Verizon - Vishnu Shukla <>, "李俊杰(Junjie Li)" <>, "" <>
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: Fri, 12 Jul 2013 08:28:38 -0000

Hi Julien,

Thanks for your comments.  Your point of view is, of course, completely valid.

Let me try to rephrase the use case for R1.  I've received input from some carriers who see a need for a policy which means that they are *not* prepared to let certain services traverse a protection-impaired link, no matter how temporary the impairment is likely to be.  Path computation would therefore need to take the impairment status of each link into account for those services only.

On R2, the required policy is that there are certain services that must not be at risk from being taken out by a second failure on a protection-impaired link, even though that means re-routing the traffic when a failure occurs.  You are correct that traffic would not normally be re-routed from a working connection, but my understanding is that these services are very much a special case.

I'm interested in whether these requirements are of wider interest, so thanks for your feedback.



-----Original Message-----
From: [] On Behalf Of Julien Meuric
Sent: 10 July 2013 16:41
Subject: Re: [CCAMP] draft-wright-ccamp-op-policy-prot-links

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".



CCAMP mailing list