Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304)

"Adrian Farrel" <adrian@olddog.co.uk> Thu, 02 August 2012 21:33 UTC

Return-Path: <adrian@olddog.co.uk>
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 1003011E808E for <ccamp@ietfa.amsl.com>; Thu, 2 Aug 2012 14:33:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.256
X-Spam-Level:
X-Spam-Status: No, score=-2.256 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, J_CHICKENPOX_21=0.6]
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 NZok5p4AnYxr for <ccamp@ietfa.amsl.com>; Thu, 2 Aug 2012 14:33:22 -0700 (PDT)
Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id DEC3F21F89D9 for <ccamp@ietf.org>; Thu, 2 Aug 2012 14:33:21 -0700 (PDT)
Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q72LWg32004269; Thu, 2 Aug 2012 22:32:42 +0100
Received: from 950129200 (dhcp-11f1.meeting.ietf.org [130.129.17.241]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q72LWZZ0004232 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 2 Aug 2012 22:32:39 +0100
From: Adrian Farrel <adrian@olddog.co.uk>
To: "'Zafar Ali (zali)'" <zali@cisco.com>, ccamp@ietf.org
References: <20120731163915.6B942621A0@rfc-editor.org> <024801cd6f84$ea1d5710$be580530$@olddog.co.uk> <B6585D85A128FD47857D0FD58D8120D39E9045@xmb-rcd-x14.cisco.com> <01cf01cd70f1$3e459830$bad0c890$@olddog.co.uk> <B6585D85A128FD47857D0FD58D8120D39F57B7@xmb-rcd-x14.cisco.com>
In-Reply-To: <B6585D85A128FD47857D0FD58D8120D39F57B7@xmb-rcd-x14.cisco.com>
Date: Thu, 02 Aug 2012 22:32:34 +0100
Message-ID: <01de01cd70f6$58503690$08f0a3b0$@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: AQJG0ydQ2iZ1PPA/LaXiFWLC86ukfAJY9gBGAdMGi+8Ce6l5JwH40YBglg89ZyA=
Content-Language: en-gb
Cc: jplang@ieee.org, dimitri.papadimitriou@alcatel-lucent.be, dbrungard@att.com
Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304)
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: Thu, 02 Aug 2012 21:33:23 -0000

Oh dear.

First, let me re-assert...

The discussion of whether you might want to do it (that we are having now) is
orthogonal to whether it is possible. I have no issue that it is possible, and I
don't think any changes are needed to any documents to enable it or to say that
it is possible. 

Now to your details...

> 1. We are at time t0.
> 2. Working LSP is setup on THE nominal path (P) with setup/ holder
> priority (s,h). For simplicity assume P is explicitly configured by SP.
> 3. At time t1 > t0, a resource, say link L fails, along the nominal Path (P).
> 4. Ingress tears down working LSP.

Better not?
You do this and you are not doing mb4b.

> 5. A restore LSP or protecting LSP starts to carry traffic.
> 6. Link L comes back up at t2 > t1.
> 7. Some other LSP(s) with setup/ hold priority better than working
> LSP setup/holder priority (s,h) claims resources from L.
> 8. Nominal Path P is no longer available for working LSP and this is the
> only Path SP wants the working LSP to take.

If the setup/holding priorities are higher, then these new LSPs would take the
resources in any case.
Probably, the interesting case for you is that the new LSPs have identical
(s,h).

> 9. Reversion cannot be applied as working LSP stays down.

Correct.

Now consider...

1a. We are at time t0.
2a. Some other LSP(s) with setup/ hold priority better than working
LSP setup/holder priority (s,h) claims resources from L.
3a. Working LSP is attempted on THE nominal path (P) with setup/ holder
priority (s,h).
4a. Nominal Path P is no longer available for working LSP and this is the
only Path SP wants the working LSP to take.
5a. Service cannot be set up as working LSP stays down.

My point being: when you decided that you did not want to use protection, you
signed up to a particular service level. Of course you would like to apply
reversion, but it is not essential.

Alternatively, when you decided to allow other LSPs to be able to use "your"
network resources, you signed up to a way of operating your network where that
can happen.

A