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

Dhruv Dhody <> Fri, 04 October 2019 06:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 26C3112004E; Thu, 3 Oct 2019 23:41:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=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 XxVMOVrlsRS8; Thu, 3 Oct 2019 23:41:31 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 43E87120018; Thu, 3 Oct 2019 23:41:31 -0700 (PDT)
Received: by with SMTP id v2so11160660iob.10; Thu, 03 Oct 2019 23:41:31 -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; bh=9xo+hLkvu2XecD0Y2FxDbCxlMMg2TexQ5WamYcve+F8=; b=I3crnUJa8A8MNwNd8XAsI/uRFU9zAS2IRPH15tpYdrqGNxK68RkudU3j6pzjCXEaLg vjhJFoyvhBFt5ngRIh3JPwL5RUTQ6RNwtwDbvV8t8YM9uzKmDZ3reyzIHqzHYtVZraw6 Wo1kumPB3kIXu9d6DB1W+Yuncw568C7QQ4NS/wFWrPZBn/H5dqDRk3IMGhTMi0In81CK WHnb1xkpM7LFxMQIzgZ5+K3mTYIe9M9Q9TdEvby/gq5wa/+Ut+GuxiYNDoFhtT+XiHiV OMiomM4eL7tcuyhvCVIXl2BoddF61ak5PgpxbAL5mLK6/v9vOaMcmHLWsWwkRZAvrRAB L2vg==
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; bh=9xo+hLkvu2XecD0Y2FxDbCxlMMg2TexQ5WamYcve+F8=; b=tILx48EL45WDFHC61ZIwkGRWrVZeCbpD+RmldKBDC4glvQMjC4hD10IG5PiOSekFlJ bR9k/td0QDAQ9kHjsCcLsUhJUNVk5wuldIliyeH5TsIJQJVExw0HzI0/rEVSvr2opmxD J9w5T6i1zOXoZSYvhetqJJ7LQRJJRP3pqMCyAzRvyLhviMWdlHcF8J1QDAASSt2fCwsQ FqrQLUOW5dppvWmL1xlZkbooBuJ5lHdQjoySv0uqcv2NM5sk05npmxTA01v3+UJI7+9a 5eWfZLlKVxf2u7oREhSvtOmT/SB8ACPoSBzFa03k1JrQSViN5F/O4RpkXTTfM6bn62yQ eCgg==
X-Gm-Message-State: APjAAAV3DmB566HuT+QbUs8XrdbY/MZ1JKBaJ4c738SWZ3tVfYt0s0fh xZW9pICR4ApbA9Wrvz8hSZdVXqN+5zqYv5zM7yQ=
X-Google-Smtp-Source: APXvYqzW3epLjeV/wzhlXvFF5VmvGd1R4sSyWE2ViQPMq7zd5PjXW63bihkw1X1FtzH2lIQ7HLpuOHA/6pKmrTfimEI=
X-Received: by 2002:a92:d84a:: with SMTP id h10mr5717607ilq.1.1570171290290; Thu, 03 Oct 2019 23:41:30 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
From: Dhruv Dhody <>
Date: Fri, 4 Oct 2019 12:10:53 +0530
Message-ID: <>
To: Benjamin Kaduk <>
Cc: "BRUNGARD, DEBORAH A" <>, "Vigoureux, Martin (Nokia - FR/Paris-Saclay)" <>, "" <>, "" <>, The IESG <>, pce-chairs <>, Hariharan Ananthakrishnan <>
Content-Type: multipart/alternative; boundary="000000000000fea61a05940ffdbb"
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: Fri, 04 Oct 2019 06:41:33 -0000

Hi Ben,

On Thu, Oct 3, 2019 at 11:34 PM Benjamin Kaduk <> wrote:

> 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.
IMHO this is similar to a protocol extension of an existing protocol
message (with an updated parsing rules represented as RBNF). The base
protocol (RBNF) might consider the extension as mangled as per the rules of
the base RFC and trigger error but the extension overrides that.

In this case, the error handling text was added as a helpful note to an
implementer of this feature: to make sure that at the time of parsing, one
should check for the C flag first before doing RFC8231 check on PLSP-ID. An
existing RFC 8231 implementation (that does not implement this feature
requires) no change.

Maybe the current text goes overboard. We could reword this -

   The PLSP-ID of 0
   indicates that the PCE wants control over all LSPs originating from
   the PCC.  A PCC that receives a PCUpd message with C Flag set to 1
   and PLSP-ID of 0 MUST NOT trigger the error condition for unknown
   PLSP-ID in an LSP update request as per [RFC8231].
   The PLSP-ID of 0
   indicates that the PCE wants control over all LSPs originating from
   the PCC.  An implementation of this feature needs to make sure to
   check for the LSP control feature (C flag set to 1) before any check
   for PLSP-ID (as prescribed in [RFC8231]).


> Thanks,
> Ben