Re: [Pce] Alvaro Retana's No Objection on draft-ietf-pce-lsp-control-request-09: (with COMMENT)

Dhruv Dhody <> Mon, 30 September 2019 11:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C962C120227; Mon, 30 Sep 2019 04:29:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SGbRdCR0RmcA; Mon, 30 Sep 2019 04:29:19 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D084F12021D; Mon, 30 Sep 2019 04:29:19 -0700 (PDT)
Received: by with SMTP id v2so37184164iob.10; Mon, 30 Sep 2019 04:29:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=b7NKr6WQbFTBM60WAI26th4y45jHQvo5LqcztiOk6EE=; b=ZEqUUOsPFPQ9WxnKdcvKwHbReJxzngW0FkjaiJWFUHWzpYSrOT6YUGAca5j1IZPRTH vebRTDpP35wgQOeFkeyJRQ30NiyBObkmkVr1kk0YrFRlvTeZizVOWZbp+VV4I2M+NXDL wMGZ2RRpUgqWfOUi0D4S4cIBlG6A0CFHMjOY0UNATbMPeRrzou39Xdyh9UyQxSLwL5jc OoU9WjXe6d8dJWMXHGF2qzGvsLKEecnnlcBJ3swfvr2alkJaMo0TuX/QxKIVj1hwd5zg Q7ishyWI0QgiAd2sasKrrAGg9jqXSMM+Jwqp1egIVM4e5w//jHVb/lTHnQKNnh+Mekat Te6w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=b7NKr6WQbFTBM60WAI26th4y45jHQvo5LqcztiOk6EE=; b=LwJxUbctdoIN34e/NcTjklJAM6GMxfMhlQMqSgl5/jauJ5PaFBbQ6XcJhSt0yjn025 zJOvkMAFdpIA1tZYBezWPg/kRw4IPCOoOek4+EeWA2S3h/y0wIryJdY+fG/UbXTdbub1 u/q5d1jeCZj+SxyjksEeTHFb0z6V4Ccgy5TuxEh0eEAwRarTcMhLeUL5JowNKqPHXCm8 DjlKwjGBONFmyZSqw1RIJJPwaTowy2T2W6REDSykvHavVu2cY0TJNETrYx3ZtwIYjuF6 oJE8sgNRemYG1mr/TED20srRHAXE2prEM7712T/nl2uBsBdRo6PPqg7Yz3DF2zp3e6yW aimQ==
X-Gm-Message-State: APjAAAWu7bAoCK+IJgHeoKa/RmuZhTK/ouZPR7vvjUijmWQ6uB8bzuEu oNfhFZeEUFoXIaIvAvmCmYpQ+6s6NEd3gx25zgU=
X-Google-Smtp-Source: APXvYqzdwoj5l0ufJKl+9MLw03YCmS1HYZeAlbn6CWHrs5NjovrjjEFeV3b7Ngj/pRKL2thq/bX31yvesyZKRO9nOPY=
X-Received: by 2002:a5d:9dd4:: with SMTP id 20mr20752656ioo.1.1569842958984; Mon, 30 Sep 2019 04:29:18 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Dhruv Dhody <>
Date: Mon, 30 Sep 2019 16:58:42 +0530
Message-ID: <>
To: Alvaro Retana <>
Cc: The IESG <>,, Hariharan Ananthakrishnan <>, pce-chairs <>,
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Pce] Alvaro Retana's No Objection on draft-ietf-pce-lsp-control-request-09: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Path Computation Element <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 30 Sep 2019 11:29:22 -0000

Hi Alvaro,

Let me take a stab at this. Authors can join in -

On Fri, Sep 27, 2019 at 3:38 PM Alvaro Retana via Datatracker
<> wrote:
> Alvaro Retana has entered the following ballot position for
> draft-ietf-pce-lsp-control-request-09: No Objection
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> Please refer to
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> I have a substantive comment and then some nits/editorial notes.
> (1) It seems to me that any PCE can request control of an LSP.  Even if the
> sessions are authenticated and encrypted, how does the PCC determine if it's ok
> for the requesting PCE to ask for control?  §8.1 says that an "implementation
> SHOULD allow the operator to configure the policy based on which it honors the
> request to control the LSPs".  If the implementation doesn't allow the
> configuration of policy, then it is possible for a rogue PCE to ask for control
> of an LSP, and for the PCC to grant it.  Why is the ability to configure this
> policy not REQUIRED?  I believe this case should be explicitly called out as a
> vulnerability.

Thanks for pointing this out. Since RFC 8231 uses SHOULD wrt policy, I
would consider not changing that. We can highlight that the PCC is the
ultimate arbiter on if the delegation should be made and to which PCE.
Even after delegation, the PCC can take back control anytime. But at
the same time blindly accepting control request could be a problem!

I propose this text in Security section -

   A PCC is the ultimate arbiter of delegation.  As per [RFC8231], a
   local policy at PCC is used to influence the delegation.  A PCC can
   also revoke the delegation at any time.  A PCC MUST NOT blindly trust
   the control requests and SHOULD take local policy and other factors
   into consideration before honoring the request.

> (2) Abstract: s/A Path Computation Client (PCC) has set up LSPs/A Path
> Computation Client (PCC) that has set up LSPs
> (3) §1: s/which PCE to delegate the orphaned LSP/which PCE to delegate the
> orphaned LSP to
> (4) §1: s/a simple extension, by using this a PCE can/a simple extension, by
> using it a PCE can
> (5) In §3 the new C Flag is called the "LSP-Control Request Flag", but §7.1
> only uses "LSP-Control".  Please be consistent; the more descriptive name is
> probably better.

These all looks like reasonable requests, authors - please update!