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

"Adrian Farrel" <adrian@olddog.co.uk> Sat, 06 July 2013 22:42 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 1422021F9D08 for <ccamp@ietfa.amsl.com>; Sat, 6 Jul 2013 15:42:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.589
X-Spam-Status: No, score=-1.589 tagged_above=-999 required=5 tests=[AWL=-1.010, BAYES_00=-2.599, LOCALPART_IN_SUBJECT=2.02]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id KT2CnnFspTIk for <ccamp@ietfa.amsl.com>; Sat, 6 Jul 2013 15:41:59 -0700 (PDT)
Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com []) by ietfa.amsl.com (Postfix) with ESMTP id EC4A121F9CE2 for <ccamp@ietf.org>; Sat, 6 Jul 2013 15:41:58 -0700 (PDT)
Received: from asmtp2.iomartmail.com (localhost.localdomain []) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r66Mfvxk027674; Sat, 6 Jul 2013 23:41:57 +0100
Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com []) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r66MftJJ027667 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 6 Jul 2013 23:41:56 +0100
From: Adrian Farrel <adrian@olddog.co.uk>
To: draft-wright-ccamp-op-policy-prot-links@tools.ietf.org
Date: Sat, 06 Jul 2013 23:41:55 +0100
Message-ID: <02c101ce7a9a$04c7ac70$0e570550$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac56mV7BgEZX072NQqGt5h3I0qbFZg==
Content-Language: en-gb
Cc: ccamp@ietf.org
Subject: [CCAMP] draft-wright-ccamp-op-policy-prot-links
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: adrian@olddog.co.uk
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: Sat, 06 Jul 2013 22:42:05 -0000


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