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

Ben Wright <> Wed, 10 July 2013 08:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1AD3121F9F89 for <>; Wed, 10 Jul 2013 01:18:45 -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 i8FaPfmVHFR7 for <>; Wed, 10 Jul 2013 01:18:39 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 142F621F9F5E for <>; Wed, 10 Jul 2013 01:18:39 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.2.342.3; Wed, 10 Jul 2013 09:18:02 +0100
Received: from ([fe80::d5d5:c683:a3be:3a19]) by ([fe80::b06d:4d13:5f63:3715%19]) with mapi id 14.02.0342.003; Wed, 10 Jul 2013 09:18:08 +0100
From: Ben Wright <>
To: "" <>, "" <>
Thread-Topic: [CCAMP] draft-wright-ccamp-op-policy-prot-links
Thread-Index: Ac56mV7BgEZX072NQqGt5h3I0qbFZgCRmqqA
Date: Wed, 10 Jul 2013 08:18:07 +0000
Message-ID: <>
References: <02c101ce7a9a$04c7ac70$0e570550$>
In-Reply-To: <02c101ce7a9a$04c7ac70$0e570550$>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>
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 08:18:45 -0000

Hi Adrian, 

Thanks for your input. 

On point 1, this is likely to be controlled by carrier policy.  There are a couple of use cases for this. 

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

Are these the sort of deployment example you were thinking of?  I can add these details to the I-D if that helps? 

On point 2, thanks for pointing me at RFC4783.  I think that solves the issue - the node detecting a failure could use error value protectionPathFailure (60) to signal the fault and clear that when the fault condition clears.  You are correct that we could also run end-to-end OAM on the LSP, but that was not necessarily going to be available for some of the cases I was considering.    



-----Original Message-----
From: [] On Behalf Of Adrian Farrel
Sent: 06 July 2013 23:42
Subject: [CCAMP] draft-wright-ccamp-op-policy-prot-links


As I read this I-D, you are saying two things.

1. You want a way to advertise in an IGP that a link is supposed to have some level of inherent protection, but that that protection is not currently present.
This is, of course, easy to achieve, but not easy to understand or use. How will the path computing system understand the estimated repair time for the impaired protection? When a path is computed that wants some level of protection, it is possible that "allow impaired protection" is a computation constraint, but it would seem to be nonsense if the repair time is going to be long.

Maybe you could add some flesh to the I-D in terms of a deployment example.

2. You want a way to notify the head end of an LSP that there has been a degradation of the LSP, and a way to let it know that things are back to normal.
Have you considered:
a. running OAM on your LSP
b. using RFC 4783


CCAMP mailing list