[Pce] Shepherd Review of draft-ietf-pce-lsp-control-request-05

Hariharan Ananthakrishnan <hari@netflix.com> Tue, 25 June 2019 01:32 UTC

Return-Path: <hari@netflix.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 3E802120219 for <pce@ietfa.amsl.com>; Mon, 24 Jun 2019 18:32:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netflix.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 YN8Nrpr8aK8i for <pce@ietfa.amsl.com>; Mon, 24 Jun 2019 18:32:08 -0700 (PDT)
Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (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 38D1F1200EC for <pce@ietf.org>; Mon, 24 Jun 2019 18:32:08 -0700 (PDT)
Received: by mail-vs1-xe32.google.com with SMTP id v129so9827161vsb.11 for <pce@ietf.org>; Mon, 24 Jun 2019 18:32:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netflix.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=0DXs02WGzuaZ8t5Tm1oJWzXmV1qP67Qe/KQplQ8GINM=; b=onigOi/9DR4gCx12SOFQGIv6CdWrdgcFX2u7NwR2ZdAwI7ry9HKKBPzWr4e7Ih5v8T vZwLaCvb+cxiVWwQB7KctXIpHOwG4vSda9renNsc1VRG0B2ChisoYiaqUaubHEw+IeNm DJPFVOvCCZWhvCEjZTA+yIZb7gHaPSt9yMy/A=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=0DXs02WGzuaZ8t5Tm1oJWzXmV1qP67Qe/KQplQ8GINM=; b=awH7BHH0Vd1QfCefqK6L22nkMLZHUAJSgk5lpHjdbLx8w9Ad5uQdObGZqiuYXRmEP3 LIOxFoitfU1YzERmB56DJ3RUjzoJVcejEqgF40GsmLW4gZTpn+aoIlBIhZcRQ/O9DNwW LjIEC4Qj+ktHwHOeFloorYO5XEq3EhFWHU0FltY5io1EWCutyHr6REhSimtXhjV1UEg9 HjAQoFFcUWSyjmb5wxFtzzlEJ25e1jvavSHbPHaWZHfwBcddlqep8J1UjfYAWwaXGviV /ULgsr3rFZTRvQWi/54dTrg/TTCtIV3vQV1Bk2md6P5niqH7vYy89vUG6xoB2CqfTd81 aykw==
X-Gm-Message-State: APjAAAW9xVBOv8hSg0U56Gp6Wb4Xf5KaGKqdImaxkykLrsmhaRIT7l58 QY899UZtpXW64moxRW6cTS9wwgdGODaugK1JlmIr7OwQicKHCQ==
X-Google-Smtp-Source: APXvYqyQfHLBypv2qIgjYwEn70Hs0ORUOwUPuXWwe8UOHtMo//Hpg5wQqhP3KqKtW0Uo2hQD31eneyWoca7HqTK7Tpc=
X-Received: by 2002:a67:ed83:: with SMTP id d3mr53360128vsp.58.1561426327066; Mon, 24 Jun 2019 18:32:07 -0700 (PDT)
MIME-Version: 1.0
From: Hariharan Ananthakrishnan <hari@netflix.com>
Date: Mon, 24 Jun 2019 18:31:56 -0700
Message-ID: <CAL70W4ryzq3c5e5Qe72gMsyKN-NTdXCRt8oEgiCY7qJjSv36ng@mail.gmail.com>
To: pce@ietf.org
Content-Type: multipart/alternative; boundary="00000000000091964b058c1be58c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/vITc6h-2B-lgeTp6-mqn8AUwwCA>
Subject: [Pce] Shepherd Review of draft-ietf-pce-lsp-control-request-05
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, 25 Jun 2019 01:32:10 -0000

-------
Header:
In general should we use "Stateful PCE" or "stateful PCE" ? I see in RFC
8231 we use "Stateful PCE"

OLD:
Ability for a stateful Path Computation Element (PCE)

NEW:
Ability for a Stateful Path Computation Element (PCE)

--------
Abstract:
OLD:
A stateful Path Computation Element (PCE)

NEW:
A Stateful Path Computation Element (PCE)

-------------
Section 4:
To make it more clear, it would be good to state that C and D flags are
mutually exclusive in PCUpd message.

OLD:

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.


NEW:

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 thePCE, i.e. if

the D flag is set in the PCUpd message, then C flag SHOULD NOT be set.


--------------

I dont see Adrian's suggestion being implemented in Section 8 in the
latest draft. It would be good to have this apart from the Security
Considerations.


SUGGESTED:

Not sure whether it belongs in 8.1 or 8.3 or 7...
The Security considerations section suggests dropping delegation
requests if the PCC is swamped. I think you need to configure the
threshold for swamping, and to recommend that the issue be logged.

IMPLEMENTED:

-----------------

Thanks,
Hari