[Pce] Benjamin Kaduk's Discuss on draft-ietf-pce-stateful-pce-lsp-scheduling-22: (with DISCUSS and COMMENT)
Benjamin Kaduk via Datatracker <noreply@ietf.org> Fri, 07 August 2020 02:24 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: pce@ietf.org
Delivered-To: pce@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2483A0CFE; Thu, 6 Aug 2020 19:24:07 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-pce-stateful-pce-lsp-scheduling@ietf.org, pce-chairs@ietf.org, pce@ietf.org, Adrian Farrel <adrian@olddog.co.uk>, adrian@olddog.co.uk
X-Test-IDTracker: no
X-IETF-IDTracker: 7.12.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <159676704653.18651.9315612770740538972@ietfa.amsl.com>
Date: Thu, 06 Aug 2020 19:24:07 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/wh6-PwuYCqB6WD7eu-ekt9nz6vU>
Subject: [Pce] Benjamin Kaduk's Discuss on draft-ietf-pce-stateful-pce-lsp-scheduling-22: (with DISCUSS and COMMENT)
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 07 Aug 2020 02:24:07 -0000
Benjamin Kaduk has entered the following ballot position for draft-ietf-pce-stateful-pce-lsp-scheduling-22: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-lsp-scheduling/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for addressing my first two discuss points from the -19; it looks like the last one is still remaining (please note that I had a typo in my original ballot on the -19, referring to a section 3.3 when 7.3.3 was intended): Section 6.6 refers to the "LSP-ERROR-CODE TLV (Section 7.3.3) which is not defined in this document, rather, the reference should be to § 7.3.3 of RFC 8231. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have some new comments after reviewing the diff from -19 to -22. (Signs indicate that processing of my previous comments is still underway; if there's a need to refer to them they are available in the email archives and in the 'history' tab for the document in the datatracker.) Section 4.1 For a scheduled LSP crossing multiple domains from an ingress domain to an egress domain. There is a PCE responsible for each of these domains. The PCE for the ingress domain is called ingress PCE. The PCE for the egress domain is called egress PCE. The state of the LSP MUST be synchronized among these PCEs. After a path for the LSP is computed, a PCRpt message with the scheduled LSP information MUST be sent to every PCE along the path from the ingress PCE to the egress PCE. After receiving the PCRpt message, the PCE MUST update its SLSP-DB according to the scheduled LSP information. The ingress PCE acting as a PCC sends its next hop PCE the PCRpt message. After receiving the PCRpt message, the next hop PCE acting as a PCC sends its next hop PCE the PCRpt message. This continues until the egress PCE receives the PCRpt message. A bunch of nits here. How about % Additional requirements apply when a scheduled LSP crosses multiple % domains, from an ingress domain to an egress domain. There is a PCE % responsible for each of these domains. The PCE for the ingress % domain is called the ingress PCE. The PCE for the egress domain is % called the egress PCE. The state of the LSP MUST be synchronized % among all PCEs along the path. To achieve this, after a path for the % LSP is computed, a PCRpt message with the scheduled LSP information % MUST be sent to every PCE along the path from the ingress PCE to the % egress PCE. After receiving the PCRpt message, each PCE MUST update % its SLSP-DB according to the scheduled LSP information. The ingress % PCE acting as a PCC sends its next hop PCE the PCRpt message. After % receiving the PCRpt message, the next hop PCE acting as a PCC sends % its next hop PCE the PCRpt message. This continues until the egress % PCE receives the PCRpt message. Section 4.3 o The stateful PCE MUST update its local scheduled LSP-DB and scheduled TED with the scheduled LSP. Besides, it MUST send a PCRpt message with the scheduled LSP to its next hop PCE along the path of the LSP, so as to achieve the scheduling traffic engineering information synchronization. nit: I think s/Besides/Additionally/ Section 5.1 During a PCEP session has been established, a PCC and a PCE indicates its ability to support LSP scheduling during the PCEP session establishment phase. [...] Some nits here; maybe: % During the PCE session establishment phase, a PCC and PCE indicate % their ability to support LSC scheduling. [...] Section 5.2 Only one SCHED-LSP-ATTRIBUTE TLV SHOULD be present in the LSP object. In case more than one SCHED-LSP-ATTRIBUTE TLV is found, the first instance is processed and others ignored. The SCHED-PD-LSP-ATTRIBUTE TLV is the same as the SCHED-LSP-ATTRIBUTE TLV regarding to its presence in the LSP object. The new text here has changed what I interpret it to mean. I interpret the text in the -22 as allowing for an LSP that includes one SCHED-LSP-ATTRIBUTE and one SCHED-PD-LSP-ATTRIBUTE TLV in the same LSP, whereas the text from the -19 seemed to indicate that if (e.g.) I had a periodic scheduling TLV then the regular SCHED-LSP-ATTRIBUTE was forbidden. After just a cursory amount of thought, it seems like there is not a useful way to interpret both TLVs at the same time, which would make this text change a regression, but I may be missing something. Section 5.2.2 STATEFUL-PCE-CAPABILITY TLV carried in open message. If the TLV is received by a peer when both bits were not set, the peer MUST ignore the TLV and generate a PCEP Error (PCErr) with a PCEP-ERROR object having Error-type = 4 (Not supported object) and Error-value = 4 (Unsupported parameter). (nit) English has this unfortunate property where the "not set" in "both bits were not set" can be interpreted as a synonym for "unset", which would make "both bits were not set" mean that this is describing the case where B=0 and PD=0. What we actually mean is "anything other than (B=1,PD=1)", which might be expressed as "If the TLV is received by a peer when either (or both) bit is not set".
- [Pce] Benjamin Kaduk's Discuss on draft-ietf-pce-… Benjamin Kaduk via Datatracker
- Re: [Pce] Benjamin Kaduk's Discuss on draft-ietf-… Huaimo Chen
- Re: [Pce] Benjamin Kaduk's Discuss on draft-ietf-… Benjamin Kaduk