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

Dhruv Dhody <dd@dhruvdhody.com> Sun, 28 February 2021 04:21 UTC

Return-Path: <dd@dhruvdhody.com>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC953A0BD5 for <pce@ietfa.amsl.com>; Sat, 27 Feb 2021 20:21:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.998
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dhruvdhody-com.20150623.gappssmtp.com
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 qgpuUFFwd-ZY for <pce@ietfa.amsl.com>; Sat, 27 Feb 2021 20:21:30 -0800 (PST)
Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EC6F3A0BD4 for <pce@ietf.org>; Sat, 27 Feb 2021 20:21:29 -0800 (PST)
Received: by mail-pj1-x1031.google.com with SMTP id u12so8344646pjr.2 for <pce@ietf.org>; Sat, 27 Feb 2021 20:21:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dhruvdhody-com.20150623.gappssmtp.com; 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; d=1e100.net; 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: <161423634063.30483.12164300029846461216@ietfa.amsl.com> <4278D47A901B3041A737953BAA078ADE19938E87@DGGEML532-MBX.china.huawei.com> <20210227201138.GH21@kduck.mit.edu>
In-Reply-To: <20210227201138.GH21@kduck.mit.edu>
From: Dhruv Dhody <dd@dhruvdhody.com>
Date: Sun, 28 Feb 2021 09:50:53 +0530
Message-ID: <CAP7zK5Y8yruU7f5U_6sd_it_JzaTNrsYhDYf3idRW0x0NyBD-A@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: "Pengshuping (Peng Shuping)" <pengshuping@huawei.com>, The IESG <iesg@ietf.org>, "draft-ietf-pce-pcep-extension-for-pce-controller@ietf.org" <draft-ietf-pce-pcep-extension-for-pce-controller@ietf.org>, "pce-chairs@ietf.org" <pce-chairs@ietf.org>, "pce@ietf.org" <pce@ietf.org>, Julien Meuric <julien.meuric@orange.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/6avEsJZhZ4aQvBuhXE9tC6kx4Eo>
Subject: Re: [Pce] Benjamin Kaduk's No Objection on draft-ietf-pce-pcep-extension-for-pce-controller-12: (with COMMENT)
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=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.

Thanks!
Dhruv