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

Dhruv Dhody <dhruv.ietf@gmail.com> Tue, 01 October 2019 08:16 UTC

Return-Path: <dhruv.ietf@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 9FACF12082C; Tue, 1 Oct 2019 01:16:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 gEfMhZlTvXmo; Tue, 1 Oct 2019 01:16:01 -0700 (PDT)
Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 A4DBF120115; Tue, 1 Oct 2019 01:16:01 -0700 (PDT)
Received: by mail-io1-xd29.google.com with SMTP id c25so45558337iot.12; Tue, 01 Oct 2019 01:16:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=KRJD18iAP37ZFDaMdTF7L1zaezzEFuTNKtB/mpur/mA=; b=dCWgZa5ZAuNfeJH5oGm3MbWXvTJVoCf+z6miDI2oREAlCTuxswhU/L+fdsP1+CUAfY G+U1kf7pQo7+J7jtGFCxKgnhua9+wLDAU6LZZCl/xHczqNzc53+x4381fhcqRH7lN2sC 3fY3f87Giuxooy+rMNFVnmm6L+7ME4BaWttmUM6egpcXIqhIpJOFJPEbmGDeiWnVCBcZ ViCB7f9OnqKdsi/7hUgUDVujRN7SCYt7JBNwnRBNbfQVUGEgXRapC7TVkrYjLEYe9bzW w6sIbf2K23N4X3qdYm6pTjbf4vVfG6YKZ3EysAjEAwaA+bamszZtUaHQKQsZZGK5rhiw rs1w==
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=KRJD18iAP37ZFDaMdTF7L1zaezzEFuTNKtB/mpur/mA=; b=ExAoUrbZ7wkb8rwqmqZRuofa1lnmHsaWCZf2CK4ohJtVINpDvrNHyxRnjYFbUfCBMB Ei+d9ZsRxkT3C2GUkuTv2QR5H5AlLSm8wecm3N2TW50SP/lJbEu0oLPRF6LGKpt41+sn PXRL92jJvbx4Wsjj0S9fFgWp7VYyWmoPgD+tbbQS9OOPEMDxM1BSll+AcufMVaQoJd6K dYVXz+Gayrd90hY4lJ3sA66EoAcv2244JKCs5QYP6QuwCaLCQz/iXTDcTEkkPMh1VM2o 3DjtDzH8Q0sWSKQIv7krHRX7Z5HfCvDgN3ClNu5RBDOuOXq7HqRLtcEFA2nCHpxVJ/vI ejmA==
X-Gm-Message-State: APjAAAU2zh0NMO8Nt1FCpVf2akY3vC+3OWoEiqzPvpyg1Ta5q1SOOMAF 6eTnXAHSToje5NbnzLoWl2Ujq4c/oSvh9NNq3oM=
X-Google-Smtp-Source: APXvYqyfKEuIaov5m1GgGxCP1B0VD9dula5MU5SSrvN9KSlRWv8WuwG2gbWrZAE7PDLfIftyV2y2qGK2iLTUH5TvYsM=
X-Received: by 2002:a92:458a:: with SMTP id z10mr24680786ilj.279.1569917760829; Tue, 01 Oct 2019 01:16:00 -0700 (PDT)
MIME-Version: 1.0
References: <156947917508.29034.2649004397929023444.idtracker@ietfa.amsl.com> <CAB75xn4dFO1QRb1zmDiUitHYjtqfce+DscBbVSMbi7YF=Ac9EA@mail.gmail.com> <CALaySJJFsf=due-W3ynnsV0hBfAWNLsRW_x_tw_iZeo86cxdJg@mail.gmail.com>
In-Reply-To: <CALaySJJFsf=due-W3ynnsV0hBfAWNLsRW_x_tw_iZeo86cxdJg@mail.gmail.com>
From: Dhruv Dhody <dhruv.ietf@gmail.com>
Date: Tue, 1 Oct 2019 13:45:24 +0530
Message-ID: <CAB75xn6Qh=aSniDRVaJvBnYnYa2z+W69+oUVCoLpyUBYX2CM9w@mail.gmail.com>
To: Barry Leiba <barryleiba@computer.org>
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/6VYAST9Te7s_lDbb8Ifu4IekDlY>
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: Tue, 01 Oct 2019 08:16:12 -0000

Hi Barry,

This makes sense. Thanks for the explanation.

Thanks,
Dhruv

On Mon, Sep 30, 2019 at 7:39 PM Barry Leiba <barryleiba@computer.org> wrote:
>
> > > — 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