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

"Ong, Lyndon" <Lyong@Ciena.com> Thu, 02 August 2012 22:18 UTC

Return-Path: <prvs=3561bf1d5b=lyong@ciena.com>
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 C0AC021E80CB for <ccamp@ietfa.amsl.com>; Thu, 2 Aug 2012 15:18:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.062
X-Spam-Level:
X-Spam-Status: No, score=-102.062 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 7HQNIugysRry for <ccamp@ietfa.amsl.com>; Thu, 2 Aug 2012 15:18:42 -0700 (PDT)
Received: from mx0a-00103a01.pphosted.com (mx0a-00103a01.pphosted.com [67.231.144.234]) by ietfa.amsl.com (Postfix) with ESMTP id 764C821E80C9 for <ccamp@ietf.org>; Thu, 2 Aug 2012 15:18:42 -0700 (PDT)
Received: from pps.filterd (m0000419 [127.0.0.1]) by mx0a-00103a01.pphosted.com (8.14.4/8.14.4) with SMTP id q72MG8cq009688; Thu, 2 Aug 2012 18:18:33 -0400
Received: from mdwexght01.ciena.com (LIN1-118-36-28.ciena.com [63.118.36.28]) by mx0a-00103a01.pphosted.com with ESMTP id 16g11gr63d-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 02 Aug 2012 18:18:32 -0400
Received: from MDWEXCHCGSIHT01.ciena.com (10.4.140.106) by MDWEXGHT01.ciena.com (10.4.140.138) with Microsoft SMTP Server (TLS) id 8.3.192.1; Thu, 2 Aug 2012 18:18:33 -0400
Received: from MDWEXGMB02.ciena.com ([::1]) by MDWEXCHCGSIHT01.ciena.com ([::1]) with mapi; Thu, 2 Aug 2012 18:18:33 -0400
From: "Ong, Lyndon" <Lyong@Ciena.com>
To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "'Zafar Ali (zali)'" <zali@cisco.com>, "ccamp@ietf.org" <ccamp@ietf.org>
Date: Thu, 02 Aug 2012 18:18:28 -0400
Thread-Topic: [CCAMP] [Technical Errata Reported] RFC4872 (3304)
Thread-Index: AQJG0ydQ2iZ1PPA/LaXiFWLC86ukfAJY9gBGAdMGi+8Ce6l5JwH40YBglg89ZyCAAAst0A==
Message-ID: <A0B4FC0A5EFBD44585414760DB4FD2749F1BBD64@MDWEXGMB02.ciena.com>
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> <01de01cd70f6$58503690$08f0a3b0$@olddog.co.uk>
In-Reply-To: <01de01cd70f6$58503690$08f0a3b0$@olddog.co.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
X-TM-AS-Product-Ver: SMEX-10.0.0.1412-7.000.1014-19082.000
X-TM-AS-Result: No--21.462000-8.000000-31
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.260, 0.0.0000 definitions=2012-08-02_08:2012-08-02, 2012-08-02, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1208020262
Cc: "jplang@ieee.org" <jplang@ieee.org>, "dimitri.papadimitriou@alcatel-lucent.be" <dimitri.papadimitriou@alcatel-lucent.be>, "dbrungard@att.com" <dbrungard@att.com>
Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304)
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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 22:18:43 -0000

Hi Adrian,

I'm glad that you say that this (LSP rerouting with reversion) is possible within the existing text, hopefully we can all accept this as conclusive.
Probably this issue would have been clearer if there was a formal definition of "implies" in RFC 2119!


Cheers,

Lyndon

-----Original Message-----
From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Adrian Farrel
Sent: Thursday, August 02, 2012 2:33 PM
To: 'Zafar Ali (zali)'; ccamp@ietf.org
Cc: jplang@ieee.org; dimitri.papadimitriou@alcatel-lucent.be; dbrungard@att.com
Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304)

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

_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp