Re: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE advising PCC about no path

Robert Varga <nite@hq.sk> Wed, 05 October 2016 11:45 UTC

Return-Path: <nite@hq.sk>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF8F9129699 for <pce@ietfa.amsl.com>; Wed, 5 Oct 2016 04:45:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.996
X-Spam-Level:
X-Spam-Status: No, score=-4.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hq.sk
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xm4OEvOXSm44 for <pce@ietfa.amsl.com>; Wed, 5 Oct 2016 04:45:32 -0700 (PDT)
Received: from mail.hq.sk (hq.sk [81.89.59.181]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBC6012969B for <pce@ietf.org>; Wed, 5 Oct 2016 04:45:31 -0700 (PDT)
Received: from [10.137.2.13] (46.229.239.158.host.vnet.sk [46.229.239.158]) by mail.hq.sk (Postfix) with ESMTPSA id 5450A2432C8; Wed, 5 Oct 2016 13:45:29 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1475667929; bh=YMSeqFGHQwokwO8PIKarKf5/oqBbJ15iPnv8AisX0cA=; h=Subject:To:References:From:Date:In-Reply-To; b=s+zirdJOjQ7aNf8d72vAr8j1UU636LCN73oj/uXTXkY5dS0wYUctreTqaIniVqoTY +93jjZt2tRfl4weGi1Ab5Gj9SRSc+OrXePinlQ43j4Z5r5j7FEel3Vu5SfbzbXgIGl Y2SARlMjj2VLgMaj7AlNjtOav2usSiw8PTYyM35s=
To: Dhruv Dhody <dhruv.dhody@huawei.com>, "stephane.litkowski@orange.com" <stephane.litkowski@orange.com>, Harish Magganmane <hmagganmane@juniper.net>, "Aissaoui, Mustapha (Nokia - CA)" <mustapha.aissaoui@nokia.com>, "pce@ietf.org" <pce@ietf.org>, "draft-ietf-pce-stateful-pce@tools.ietf.org" <draft-ietf-pce-stateful-pce@tools.ietf.org>
References: <D4143A39.13730%hmagganmane@juniper.net> <20738_1475483259_57F2167B_20738_1349_1_9E32478DFA9976438E7A22F69B08FF921BD96544@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <23CE718903A838468A8B325B80962F9B8C997D6C@blreml501-mbx>
From: Robert Varga <nite@hq.sk>
Message-ID: <5ed92296-8a3d-6f40-962b-82f68171f80c@hq.sk>
Date: Wed, 05 Oct 2016 13:45:21 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <23CE718903A838468A8B325B80962F9B8C997D6C@blreml501-mbx>
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="9fmkjTRwx1bQ3rmCTw2N94riqRadUmgvo"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/vOHsydn64bZgPodZC8ItmA8ZeTQ>
Subject: Re: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE advising PCC about no path
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Oct 2016 11:45:34 -0000

On 10/03/2016 04:30 PM, Dhruv Dhody wrote:
> (1) Allow Empty ERO to mean no path.
> 
> Let it be valid in all messages to mean that no intended path exists for
> this LSP.
> 
> As per -16,
> 
> - empty ERO is added in the end of synchronization marker (PCRpt). 
> 
> - The ERO may be empty if the PCE does not have a path for a delegated LSP.
> 
>  
> 
> We can add text in section 6.2 to say something like –
> 
>  
> 
> The ERO may be empty if the PCE does not have an intended path for the
> delegated LSP. 
> 
> If the local policy allows it, the PCC SHOULD signal the tear down of
> the LSP. At 
> 
> this time, PCC MAY also revoke delegation and use a locally computed
> path instead. 
> 
>  
> 
> To me this is more logical and in spirit with the rest of the document,
> also would require least amount of changes in existing implementations.

+1

Thanks,
Robert