Re: [Pce] Review of draft-ietf-pce-stateful-pce-18

Robert Varga <nite@hq.sk> Fri, 17 February 2017 13:12 UTC

Return-Path: <nite@hq.sk>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23D7D129A4D; Fri, 17 Feb 2017 05:12:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 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=-0.001] 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 r8uhI40ZxM3l; Fri, 17 Feb 2017 05:12:24 -0800 (PST)
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 ABA72129A48; Fri, 17 Feb 2017 05:12:23 -0800 (PST)
Received: from [10.137.2.13] (chello085216197060.chello.sk [85.216.197.60]) by mail.hq.sk (Postfix) with ESMTPSA id D34BF240529; Fri, 17 Feb 2017 14:12:21 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1487337142; bh=o5jAr1OUb7BO7sKdh69cuhwaX18XoFa8MjAZFePEx0k=; h=Subject:To:References:Cc:From:Date:In-Reply-To; b=JPs7KLiK2nEMOmGRJluDEeDgv1PuAJFfh0f0JgxsP2H50zirKXs0JAzwilDjR/w4o MLyNNfjDlANQLDP6G2M1FlOZbnJLHmC3j5PaRkLadEhvJjrowOwUx28o9k8uCeYRJT Fho8lO2KNl7XhCgNTa77BbDFisiIVtECkn63PQI8=
Subject: Re: [Pce] Review of draft-ietf-pce-stateful-pce-18
To: Joel Halpern <jmh@joelhalpern.com>, gen-art@ietf.org
References: <148730267819.21972.5284047079762312692.idtracker@ietfa.amsl.com>
From: Robert Varga <nite@hq.sk>
Message-ID: <ff31899f-23f5-f3b2-41c8-89fc16586c38@hq.sk>
Date: Fri, 17 Feb 2017 14:12:12 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <148730267819.21972.5284047079762312692.idtracker@ietfa.amsl.com>
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="2m9KfO1DrPm9cwDIFXFDSXcIamgfLfetp"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/lUwm7gLEv86NcSfEV6VWGrtB49E>
Cc: draft-ietf-pce-stateful-pce.all@ietf.org, pce@ietf.org, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Feb 2017 13:12:25 -0000

On 02/17/2017 04:37 AM, Joel Halpern wrote:
> 
>     This comment may be a misunderstanding or mis-expectation on my
> part.  I would have expected one of the ways o using an active PCE is
> to have the PCE decide (under suitable circumstances) that an LSP is
> needed between two PCCs.  As far as I can tell, the text in section
> 5.8.2 and 5.8.3 prohibits that.  A PCE is only allowed to send an LSP
> Update Request (in a PCUpd message) for an LSP that has been delegated
> to it.  At that point I thought that a PCC could delegate a block of
> unsetup LSPs to the PCE.  But then looking at 5.8.2, the text states
> that for each delegation, the PCC must request an initial path.  That
> seems to prohibit delegating a block of LSPs for future updates.  Is
> the intention to prohibit the driving of LSP creation from the PCE?

I think this may be a case consistency rotting over the years this draft
has been out there, which also affects my recollection of reasoning
behind the text.

Sections 5.8.1 and 5.8.2 govern how to transition from 'passive
stateful' mode of operation, where the PCC uses PCRpt to communicate
state and PCReq to solicit updates. They are not meant (or at least not
when they were originally written) to restrict the delegation procedure.

The wording of 5.8.2's first paragraph has an implicit unstated goal of
ensuring that the LSP will be set up, i.e. the PCC first makes an
explicit request to acquire the parameters needed to signal the LSP and
then delegates the LSP, thus ensuring a computation is made.

I think it is still valid for PCC to delegate an LSP without performing
5.8.1, in which case the PCE decides when (and if) to push the
parameters required to make the LSP operational.

I do see this as a problem, as the PCC is free to revoke the delegation,
based solely on its local policy, if the PCE fails to fill in the LSP
parameters in a reasonable time frame -- reverting to either local
control or to 5.8.1 mechanics.

Regards,
Robert