Re: [Pce] Review of draft-ietf-pce-stateful-hpce
<daniel@olddog.co.uk> Mon, 10 June 2019 12:21 UTC
Return-Path: <dk@danielking.net>
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 729E212017F for <pce@ietfa.amsl.com>; Mon, 10 Jun 2019 05:21:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=danielking-net.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 jIsvV_gdol-Z for <pce@ietfa.amsl.com>; Mon, 10 Jun 2019 05:21:11 -0700 (PDT)
Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (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 5B55C120181 for <pce@ietf.org>; Mon, 10 Jun 2019 05:21:11 -0700 (PDT)
Received: by mail-wm1-x332.google.com with SMTP id z23so7953519wma.4 for <pce@ietf.org>; Mon, 10 Jun 2019 05:21:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielking-net.20150623.gappssmtp.com; s=20150623; h=sender:from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=Jmf2s2ddsjbDIIw9A6SbO8eoGANS/gMesNB3yDJqeXU=; b=lmqvORvmF4OzzqjUkJF/PI8UHOXHNtsHGMaGUjcc/x17Zx/wKFBzjZV/CG5MO5t9Yu lcIeF2/AwvbpTYcp2IoIeDgqbsvmKXgMK5He7zRNUua8/B1P6vGFW3t7JyTJR/uNC8Sp xCCbOqRPGlFuHZNuvtSy3GSWt/QFtwn7nG0+EZALsOkTlN2cqqPO61oHotrBTcb+hpxc HuKuaaZIZFqKqVaSByh20nFbl2KeEqmqOvD8VoteGS1Hdi/Ly3zrh1hAKleNHl4/gyud K71TEl36K6BoBuwaEcZ/LUviHUDoJ+jUi09i4DHrbJwA1625J+wTHIG10ALCQgko8ewo bsRA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:references:in-reply-to:subject :date:message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=Jmf2s2ddsjbDIIw9A6SbO8eoGANS/gMesNB3yDJqeXU=; b=UY5XSuWs6CRpEkHqqOiG4Y/p9d7OnOp07F6irB0LKLeVbq+Y42u5E3lSYrIiDNO5WS 1V7/IpYeMOjrs5yM7u02eslotWk2dis+2U7e8r5YO3ymmiI61AnVjjU/EJ1Da61pSqiN 1OX3d5VRDwNsLRZ7dNPyXdUyJLC7GzIFjdlHZsFAbVmItmgVk3nCANuk30FIT09n7gY0 0NIB2dqtJVz6VScVLc3EmfB6r4rCC4UxCchuDjV9XEabvDHvzZonTKsLrQ+BZUtzu0mM XY9I3gOvCovFm7VtbfhlYm5/T6yjH+jN+eJ9opqSrgcPIrHRlvT32vi4/+V/ZIK4H/5R J2MA==
X-Gm-Message-State: APjAAAV1RbMSj1T3cGlJxT6iC+E8RU5EWEOxzLTZThZNqw2IKEbhRHBf UwhvB/JP3a53esyX824dZJovR/8MrEeqaQ==
X-Google-Smtp-Source: APXvYqw9qm7PPIunJ37IuP9Q0qxVqDqrlxBhgdctIA4IAKfqf68efLVrox91/mQ7mPNOwFz1r6MGTw==
X-Received: by 2002:a1c:a483:: with SMTP id n125mr12931425wme.3.1560169269410; Mon, 10 Jun 2019 05:21:09 -0700 (PDT)
Received: from CIPHER (host86-157-191-178.range86-157.btcentralplus.com. [86.157.191.178]) by smtp.gmail.com with ESMTPSA id a67sm4739630wmh.40.2019.06.10.05.21.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Jun 2019 05:21:08 -0700 (PDT)
Sender: Daniel King <dk@danielking.net>
X-Google-Original-Sender: "Daniel King" <dk@danielking.net>
From: daniel@olddog.co.uk
To: adrian@olddog.co.uk
Cc: pce@ietf.org
References: <03d201d4e328$4bc1b510$e3451f30$@olddog.co.uk>
In-Reply-To: <03d201d4e328$4bc1b510$e3451f30$@olddog.co.uk>
Date: Mon, 10 Jun 2019 13:21:06 +0100
Message-ID: <00d401d51f86$faa87380$eff95a80$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQFYtmVQGFhQT++Z0ZpUouVGFIPdJ6eNnmJQ
Content-Language: en-gb
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/Pmq1cXIURqC-ABQOtlaP0PUWUaY>
Subject: Re: [Pce] Review of draft-ietf-pce-stateful-hpce
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, 10 Jun 2019 12:21:13 -0000
Hi Document Shepherd, Thank you for your detailed review, comments and suggested text. The authors believe we have addressed all the open issue with the last two revisions of the I-D. If you would be so kind as to scan through the changes it would be very much appreciated. Please also find a number of comments inline below (DK>>). BR, Dan. -----Original Message----- From: Pce <pce-bounces@ietf.org> On Behalf Of Adrian Farrel Sent: 25 March 2019 16:32 To: draft-ietf-pce-stateful-hpce@ietf.org Cc: pce@ietf.org Subject: [Pce] Review of draft-ietf-pce-stateful-hpce Hi, Good afternoon. My name is Adrian and I'll be your Document Shepherd for this journey. As this draft is progressing through working group last call, I thought I would do my review now and save a little time later. These comments may seem a little negative, but I hope you can address them with small changes. Thanks, Adrian === Abstract s/deployment of Stateful PCE(s)/deployment of Stateful PCEs/ DK>> Done --- Section 1 para 1 needs a reference to 5440 DK>> Done --- 1. s/for stateful PCE(s) in/for stateful PCEs in the/ DK>> Done --- 1. The initial section of the document focuses on end to end (E2E) inter-domain TE LSP. Section 3.3.1 describe the operations for the Per Domain LSP that could be stitched. Maybe... Sections 3.1 and 3.2 focus on end to end (E2E) inter-domain TE LSPa. Section 3.3.1 describes the operations for stitching Per Domain LSPs. DK>> Done --- I am not certain that you need to use upper case terms in this document. I found "SHOULD" in sections 6 and 7.2, and "MAY" twice in seciton 3.1 and once in section 3.3.1. Also "RECOMMENDED" in section 6. Is this really appropriate in a document that is describing an approach, not specifying bits on the wire or implementation behavior? That would allow you to dispose of section 1.1 and the two references. DK>> Done --- Section 3 While the terms PE and CE are defined and used unambiguously, I suspect that they will cause some confusion because they are such well known terms in networking. DK>> Done. We now use C-PCE towards P-PCE (EC-EP) or from a P-PCE towards C-PCE (EP-EC). --- 3. All PCE types herein (i.e., PE or CE) are assumed to be 'stateful PCE'. Is it not plausible to have a stateless C-PCE working with a stateful P-PCE? I think that the relationship of child to parent is similar to the relationship of PCC to PCE, but when we talk about a stateful PCE we don't also talk about a stateful PCC. So when you say that the C-PCE must be stateful, you are necessarily talking about its relationship with its PCCs. If you are determined to limit the scope of this document to PCE hierarchies where both the parent and child are stateful (you are allowed to make this choice if that's what the WG wants) then you need to make this clear in the Abstract and Introduction. DK>> Done --- Am I confused about delegation? You have... The P-PCE has no information about the content of the child domains. Clearly the C-PCE will report the path of the LSP (segment) that crosses the domain for which it is responsible, but how can the P-PCE make any change to that LSP without visibility into the child domain? But you go on to talk about delegation as if it could work: such as... LSP Control Delegation (CE-PE,PE-CE): a C-PCE grants to the P-PCE the right to update LSP attributes on one or more LSPs When you draw the similarity between PCC-PCE and C-PCE-P-PCE delegation as... Note that this hierarchy is recursive and thus a Label Switching Router (LSR), as a PCC could delegate the control to a PCE, which may delegate to its parent, which may further delegate it to its parent (if it exist or needed). Similarly update operations could also be applied recursively. .... I think that you miss that the PCC and PCE can both see the TED, but the C-PCE and P-PCE have very different visibility into the domain. DK>> Done. We clarified the text. --- 3. Just clarity... OLD [I-D.ietf-pce-hierarchy-extensions] defines the H-PCE capability TLV that should be used in the OPEN message to advertise the H-PCE capability. [RFC8231] defines the stateful PCE capability TLV. The presence of both TLVs represent the support for stateful H-PCE operations as described in this document. NEW [I-D.ietf-pce-hierarchy-extensions] defines the H-PCE Capability TLV that is used in the OPEN message to advertise the H-PCE capability. [RFC8231] defines the Stateful PCE Capability TLV used in the OPEN message to indicate stateful support. The presence of both TLVs in an OPEN message indicates the support for stateful H-PCE operations as described in this document. END DK>> Done. Thanks. --- 3. I feel that this paragraph is confusing. I think the referenced draft also needs some work on the terms stateful and synchronization, but we can focus on the document at hand. OLD [I-D.litkowski-pce-state-sync] describes the procedures to allow a stateful communication between PCEs for various use-cases. The procedures and extensions as described in Section 3 of [I-D.litkowski-pce-state-sync] are also applicable to Child and Parent PCE communication. The SPEAKER-IDENTITY-TLV (defined in [RFC8232]) is included in the LSP object to identify the Ingress (PCC). The PLSP-ID used in the forwarded PCRpt by the C-PCE to P-PCE is same as the original one used by the PCC. NEW [I-D.litkowski-pce-state-sync] describes the procedures to allow communication between stateful PCEs that serve the same domain. The procedures and extensions as described in Section 3 of [I-D.litkowski-pce-state-sync] are also applicable to Child and Parent PCE communication. The SPEAKER-IDENTITY-TLV (defined in [RFC8232]) is included in the LSP object to identify the Ingress (PCC). The PLSP-ID used in the forwarded PCRpt by the C-PCE to P-PCE is same as the original one used by the PCC. END However, this has made [I-D.litkowski-pce-state-sync] a normative reference. I suspect you don't want to go there. That will mean you need to write the normative text here (which may be a bit more of a rewrite) and simply add... Similar procedures are used in [I-D.litkowski-pce-state-sync] to synchronize state between stateful PCEs that serve the same domain. Furthermore, the term "Ingress" in unclear. You probably do not mean the ingress of the LSP, per se. You probably mean the ingress of the LSP in the domain that the C-PCE serves. You also have the term "ingress PCE" (in 3.1) which is such a useful term that you should probably call it out with a definition. DK>> Done. --- 3.1 s/applicable to PCEP session/applicable to a PCEP session/ DK>> Done. --- 3.1 OLD Taking the sample hierarchical domain topology example from [RFC6805] as the reference topology for the entirety of this document. NEW We use the sample hierarchical domain topology example from [RFC6805] as the reference topology for the entirety of this document. It is shown in Figure 1. END DK>> Done. --- 3.1, 3.2, 3.3, and 3.3.1 It is confusing to have steps 1 to 11 as per 6805 and then introduce new steps 1 to 4 in 3.1. We need to: - not confuse these with steps 1 to 4 of 6805 - understand where in the sequence the steps are preformed Furthermore, "initial" steps 1 to 8 are introduced in 3.2. Are these in place of steps 1 to 4 in 3.1 or in addition? And where in the sequence are they performed? How do they relate to steps 1 to 8 of 6805. There is some slightly better description in 3.2, but only steps 1 and 2 seem to be truly "initial". It all needs some more clarity. DK>> Done with updated text for clarity. By the time I got to 3.3.1 I really couldn't work out the steps at all. DK>> We changed the procedure numbering mechanism, it will hopefully be clearer to the reader. --- 3.2 OLD To update an LSP, a PCE send to the PCC, an LSP Update Request using a PCUpd message. NEW To update an LSP, a PCE sends an LSP Update Request to the PCC using a PCUpd message. END DK>> Done --- 3.3. PCE Initiation Operation Maybe... 3.3. PCE Initiation of LSPs DK>> Done --- 4.1 How about this for a slightly tidier figure 2? +----------+ | Parent | /| PCE | / +----------+ / / Stateful / / P-PCE / / / / Stateful+-----+ / / C-PCE | PCE |/ / Hi | Hi | / +-----+ / +---+ +---+ / +---+ +---+ + LSR +--+ LSR +........................+ LSR +--+ LSR + + H1 + + H2 + / + H3 + + H4 + +---+ +---+\ +-----+/ /+---+ +---+ \ | PCE | / \ | Lo | / Stateful \ +-----+ / C-PCE \ / Lo \+---+ +---+/ + LSR +--+ LSR + + L1 + + L2 + +---+ +---+ DK>> Excellent. Thanks. --- 4.1 You have... All procedures described in Section 3 are applicable to inter-layer path setup as well. I wonder if you want to explain that the layers are considered as separate domains. DK>> Done. --- 4.2 OLD [RFC8453] describes framework for Abstraction and Control of TE Networks (ACTN), where each Provisioning Network Controller (PNC) is equivalent to C-PCE and P-PCE is the Multi-Domain Service Coordinator (MDSC). The Per domain stitched LSP as per the Hierarchical PCE architecture described in Section 3.3.1 and Section 4.1 is well suited for ACTN. NEW [RFC8453] describes a framework for the Abstraction and Control of TE Networks (ACTN), where each Provisioning Network Controller (PNC) is equivalent to a C-PCE, and the P-PCE is the Multi-Domain Service Coordinator (MDSC). The Per Domain stitched LSP as per the Hierarchical PCE architecture described in Section 3.3.1 and Section 4.1 is well suited for ACTN. END DK>> Done. Again, thanks for text. --- 4.2 OLD In ACTN framework, Customer Network Controller (CNC) can request the MDSC to check if there is a possibility to meet Virtual Network (VN) requirements (before requesting for VN provision). The H-PCE architecture as described in [RFC6805] can supports via the use of PCReq and PCRep messages between the P-PCE and C-PCEs. NEW In the ACTN framework, a Customer Network Controller (CNC) can request the MDSC to check whether there is a possibility to meet Virtual Network (VN) requirements before requesting for the VN to be provisioned. The H-PCE architecture as described in [RFC6805] can support this function using PCReq and PCRep messages between the P-PCE and C-PCEs. END DK>> Done. --- 5.1 I think you need to rephrase this section. I don't think there is any clear meaning to an LSP being involved in H-PCE. But some of this issue can't be resolved until you have worked out what it is that a stateful H-PCE actually does. As previously noted, it would not appear to have access to the per-domain TEDs, so what is it doing with an LSP that is reported or delegated to it? Given what 5.2 says, reporting LSPs (not for delegation, but simply reporting them) seems entirely pointless! DK>> Updated text for clarity. --- I noticed that the Table of Contents doesn't match the actual sections starting from Section 5. Possibly sections 4 and 5 were supposed to be merged DK>> Fixed. --- 6. says The LSP state in the PCRpt message SHOULD continue to use this. Can you explain when a PCRpt might deviate from this "SHOULD"? DK>> Done. --- 6. Thus securing the PCEP session (between the P-PCE and the C-PCE) using mechanism like TCP Authentication Option (TCP-AO) [RFC5925] or Transport Layer Security (TLS) [RFC8253] is RECOMMENDED. What does 'like' mean? Is there anything specific you have in mind? DK>> Fixed. --- You have I-D.ietf-pce-pcep-yang in your references section, but no actual reference to it. DK>> Done. --- A number of references need to be promoted to Normative consistent with how you have used them in this document. RFC 4655 RFC 5520 RFC 5925 RFC 8232 RFC 8253 I-D.litkowski-pce-state-sync I-D.ietf-pce-hierarchy-extensions I-D.dugeon-pce-stateful-interdomain DK>> Done, and moved informative to normative where needed. Thanks, Dan and the other authors. _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce