Re: [Pce] Benjamin Kaduk's No Objection on draft-ietf-pce-pcep-extension-for-pce-controller-12: (with COMMENT)

Dhruv Dhody <> Sun, 28 February 2021 04:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3EC953A0BD5 for <>; Sat, 27 Feb 2021 20:21:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.998
X-Spam-Status: No, score=-4.998 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qgpuUFFwd-ZY for <>; Sat, 27 Feb 2021 20:21:30 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::1031]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1EC6F3A0BD4 for <>; Sat, 27 Feb 2021 20:21:29 -0800 (PST)
Received: by with SMTP id u12so8344646pjr.2 for <>; Sat, 27 Feb 2021 20:21:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=wTrCDLmFsTqdA8WdwQj+l2sSsnLeXrD1E4bf5/q2HEc=; b=hJ47sTNIab/PPzyF57fzdqBg9pmI0hj6aex7n93CSZER1LRCBuQxAbazOjBl/3RMey DLIPwwEM1+iZYO7ZABb5hxHU0+obgtFjhjR1Z/3QV48qxv3Xr+HlobT1cMMEJJ+9sRhN Z9i9PC20hM8ha9fNdolpCMetDFfLOPHaOmPzAbFMj5Wqlm1Wolbi/p14YKkNjEVuyUin +zgbOqXnWHSd/a6yEmmmCdHzL070MX029VjXv20iXNEdlLtEFZhvafCwVpUw4qV6QJLZ 8iM1k+/emF6TygRlPCPp8wGz2wSbPXbxPWGFZhfJKEOL9rYTPVMTa0bySErZ7QatxsvP erNw==
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=wTrCDLmFsTqdA8WdwQj+l2sSsnLeXrD1E4bf5/q2HEc=; b=ZFosPVicJp5fZto5pcEpjTLrUrjwXMddy5o0R4N3upiGFkWvREhaCLBZGPg2uZBSsq 9XGLYpJ2mhrVjw40JFR2IobP4ZA3M7mq3lojYqjhtwkx8UPA/9bNxtdfsNTKCuS0fTam 0ICRJeZOKaLdlAPeYmrGbksPLFd2rL5WSO41XUnkZJSw1AnjWx9TrjSVi3RepR61hbtg E90xZqho9daLOeJcHMZezPdts3lcbXCBJo8IzvlyyIkeh36zJEWwSibpogMnLRWSbsKg kiqT2F2Snd7zWsEg7vXYtRCvxA7FwiuMKjB2Q8aYM4mgWO7z8Gq+Ur4PZPtq+wk/D5JY exWw==
X-Gm-Message-State: AOAM533kYAEqolhGwJYmVofAOAR5Bp9fuQmk7/8NOeC70RGMRmI5WmVi X1wZjId3BDT1ANU2teZ2w8RMDgHOcmRYi+JGQTnTPQ==
X-Google-Smtp-Source: ABdhPJxaCkhyuGmxVQJ4h5NBf2qvzfnPxY2Hgc6g92nWrH054bxMQ5iChove8Cr5amVV2K6dl0kZh29hD/MxRXIPs+s=
X-Received: by 2002:a17:902:9691:b029:e3:dd4b:f6bb with SMTP id n17-20020a1709029691b02900e3dd4bf6bbmr9697891plp.77.1614486089400; Sat, 27 Feb 2021 20:21:29 -0800 (PST)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Dhruv Dhody <>
Date: Sun, 28 Feb 2021 09:50:53 +0530
Message-ID: <>
To: Benjamin Kaduk <>
Cc: "Pengshuping (Peng Shuping)" <>, The IESG <>, "" <>, "" <>, "" <>, Julien Meuric <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Pce] Benjamin Kaduk's No Objection on draft-ietf-pce-pcep-extension-for-pce-controller-12: (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: Sun, 28 Feb 2021 04:21:32 -0000

Hi Ben, Authors,

> > I note in a few places in the section-by-section comments that the figures seem to indicate a 'D' flag in PCInitiate and PCUpd messages, and the only D flag I see mentioned in the prose is the Delegate flag in a PCRpt.  This seems particularly important to check and get right (though I admit that I could just be missing something).
> >
> > Shuping> Yes, D flag is the Delegate flag. Changed the text so that it is applicable for other PCEP messages as well - "The ingress PCC and PCE MUST also set D (Delegate) flag (see [RFC8231]) and C (Create) flag (see [RFC8281]) in the LSP object in the initial exchange."
> It's good to have the prose and figure consistent, but I'm still a little
> confused as to whether it's needed to set the D flag for PCInitiate and
> PCUpd -- RFC 8281 does not appear to say anything at all about the flag in
> those messages (whether to set it or clear it), so I guess the only
> guidance we have is what implementations of 8281 do in practice.  If they
> do set the D flag, then continuing to do so (and documenting that) makes
> sense, but otherwise it's not clear to me that there is a reason to change
> things in this document.

My suggestion to the authors would be to remove D=1 from the figures
for the PCInitiate message and match that to the prose as well. The
behavior here is not new and it should simply refer to RFC8281.

D=1 for PCUpd is fine and should stay as per RFC8231.