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

Barry Leiba <barryleiba@computer.org> Mon, 30 September 2019 14:09 UTC

Return-Path: <barryleiba@gmail.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 8BEC91200CC; Mon, 30 Sep 2019 07:09:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.478
X-Spam-Level:
X-Spam-Status: No, score=-1.478 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.172, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
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 4g4mon46ma2u; Mon, 30 Sep 2019 07:09:51 -0700 (PDT)
Received: from mail-io1-f50.google.com (mail-io1-f50.google.com [209.85.166.50]) (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 5A2D01200BA; Mon, 30 Sep 2019 07:09:51 -0700 (PDT)
Received: by mail-io1-f50.google.com with SMTP id q10so38733714iop.2; Mon, 30 Sep 2019 07:09:51 -0700 (PDT)
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=B+5XP2xCzYRcwgZ1T2gZzpEbXZ0uSbkIhnBjDq7uDPM=; b=AOjJfkUWA08FutPag9JPiaE3CuBjopXNwbHUpeAQogVv5b8om2+4gE54Q/xE/mPE7b tRd3NuKQQQ7DLyjl8rf6uyIa3P6Q31erUj+fQdY6klVD5jFrGttUW+VnJZ6/yp1FScjZ zRYT+EpnZTpxsypjeervs7ZIKnEpbdU0F7RBynh4tYBHFjF7MgebmPe6nmoYiRQB3FBV BsUv7oInqwSxX3SZLGtdSbCrvlg+X83DBlz3Bc1hN58BADxzmYby3bCaHoTOp1TsVqgr PThUFrkjml+AMoxZdQHLwhU0bl4wriqNM1rSkOWpyAUSYszzjMxnSvXLRPnOc8SaOWVm tC4g==
X-Gm-Message-State: APjAAAVYFsTDQtyK/2ei2PNXdRuV4fRHGK13bc/IcrcgfhnvHzzrIycJ bmsZ4z74Ingm0ol37uNmvrWbIAqXc8zIQAreUrw=
X-Google-Smtp-Source: APXvYqxKuS+L6njGpvky7kG3uneATapichKPu5BGR12C2R3NJCzS4JdGNreS+xzgnRdsrRTFnis57C1NcvbSz6lX1zI=
X-Received: by 2002:a02:1c02:: with SMTP id c2mr19575320jac.118.1569852590359; Mon, 30 Sep 2019 07:09:50 -0700 (PDT)
MIME-Version: 1.0
References: <156947917508.29034.2649004397929023444.idtracker@ietfa.amsl.com> <CAB75xn4dFO1QRb1zmDiUitHYjtqfce+DscBbVSMbi7YF=Ac9EA@mail.gmail.com>
In-Reply-To: <CAB75xn4dFO1QRb1zmDiUitHYjtqfce+DscBbVSMbi7YF=Ac9EA@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
Date: Mon, 30 Sep 2019 10:09:39 -0400
Message-ID: <CALaySJJFsf=due-W3ynnsV0hBfAWNLsRW_x_tw_iZeo86cxdJg@mail.gmail.com>
To: Dhruv Dhody <dhruv.ietf@gmail.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-pce-lsp-control-request@ietf.org, Hariharan Ananthakrishnan <hari@netflix.com>, pce-chairs <pce-chairs@ietf.org>, pce@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/8AYMDFyTbuErjAGlg9XF7YrIh_g>
Subject: Re: [Pce] Barry Leiba's No Objection on draft-ietf-pce-lsp-control-request-09: (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: Mon, 30 Sep 2019 14:09:52 -0000

> > — Section 4 —
> >
> >    The D Flag and C
> >    Flag are mutually exclusive in PCUpd message.  The PCE SHOULD NOT
> >    send control request for LSP which is already delegated to the PCE,
> >    i.e. if the D Flag is set in the PCUpd message, then C Flag SHOULD
> >    NOT be set.
> >
> > I’m confused: “mutually exclusive” means that they can’t both be set.  So why
> > SHOULD NOT and not MUST NOT?  (You’re also missing a few articles here: ”a
> > PCUpd message”, “a control request”, “an LSP”, and “the C Flag”.
> >
>
> I think the reason for SHOULD NOT was because when a PCC receives this
> - it would simply ignore it!
> This did not rise to the level of error usual for MUST NOT!
>
> If you feel that the above isn't a good enough reason, changing would
> not cause any harm either.

If the working group thinks that SHOULD NOT is right, it should stay
that way -- I just questioned the combination of "mutually exclusive"
and "SHOULD NOT".  So here are my thoughts:

1. If there is no reason they should ever be set together, then it
should be MUST NOT.

2. If there might be a reason to set them together -- it's difficult
to meet the conditions in some way, or whatever -- then SHOULD NOT is
OK.

3. If you keep it as SHOULD NOT, I think you should change the
"mutually exclusive" sentence to be less strong.

It sounds to me like MUST NOT is the right thing here -- that there's
never a reason to set them both together, and that it doesn't make
sense in the protocol to have them both set.  So even though the
receiver can ignore the situation, MUST NOT still applies.

Barry