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

Benjamin Kaduk <> Thu, 03 October 2019 18:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3DB6C1200CE; Thu, 3 Oct 2019 11:04:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UoJDBnSv5TXX; Thu, 3 Oct 2019 11:04:07 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E68E8120025; Thu, 3 Oct 2019 11:04:06 -0700 (PDT)
Received: from ([]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.14.7/8.12.4) with ESMTP id x93I3XAp031898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 3 Oct 2019 14:03:36 -0400
Date: Thu, 3 Oct 2019 11:03:33 -0700
From: Benjamin Kaduk <>
Cc: "Vigoureux, Martin (Nokia - FR/Paris-Saclay)" <>, Dhruv Dhody <>, "" <>, "" <>, The IESG <>, pce-chairs <>, Hariharan Ananthakrishnan <>
Message-ID: <>
References: <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <>
Subject: Re: [Pce] Martin Vigoureux'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: Thu, 03 Oct 2019 18:04:10 -0000

Hi Deborah,

On Tue, Oct 01, 2019 at 10:24:05PM +0000, BRUNGARD, DEBORAH A wrote:
> As it seems there are still some questions on "update or not", I'll try to add some additional context. As we know, it is difficult to define "update", so each working group has their context for it. For TEAS, CCAMP, MPLS, PCE, if it is a new capability, which is making use of previously reserved bits, we have not considered it an update, otherwise every new RFC would be an update of the base RFC.
> Here's an example of exactly this (a quick scan by me, I'm sure there are many more across all the groups):
> The PCE-CAP-FLAGS sub-TLV was defined in RFC5088 (bits 9-31 were reserved). RFC 8623 defined stateful P2MP and defined new capability bits (from the reserved group) using 13, 14, 15. It was not considered an update of RFC5088 (OSPF extensions for PCE Discovery), or RFC8306 (P2MP TE LSPs for PCEP), or RFC8281 (base document with extensions to support stateful PCE). And RFC5088 was not an update of OSPF (RFC2328 and RFC2740). And RFC8281 was not an update to RFC5440 PCEP base spec). As you can see, this would result in a very big waterfall if all these were considered updates. An implementor of the base spec, with no interest in these new capabilities, would need to read all the updates just to be sure the base is not impacted. We wouldn't have any implementations, everyone would still be readingūüėä
> In this document, these new values are using several more of the previously reserved values. Only implementors of this new capability need to be aware of these assignments, so among PCE folks, it is not considered an update.
> Dhruv already responded to Ben on the PLSP-ID. It is the same as these flags, only those wanting to implement this new capability need to be aware of it. And it is backwards compatible with the base spec.

This all makes sense to me, and I see the reasoning behind not using
Updates: for them.  I'm not sure that our discussion here has covered the
relaxation of error handling, though -- we have "this MUST NOT trigger the
error handling as specified in [RFC8231]" in one place, and IIRC a similar
thing in one other place.  In some sense, this is overriding RFC 8231 and
an implementation of this spec is no longer compliant with the base RFC
8231 specification.  So, I wonder if the Updates: tag is needed in order to
"legitimize" this weakening of the requirements, as otherwise we have two
specifications which are formally in conflict with each other, one of which
is needed in order to use the other.