[Pce] Review of draft-zhang-pce-resource-sharing-10
"Adrian Farrel" <adrian@olddog.co.uk> Thu, 26 September 2019 07:39 UTC
Return-Path: <adrian@olddog.co.uk>
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 9989E120816; Thu, 26 Sep 2019 00:39:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham 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 sCs7Wb4rPPzJ; Thu, 26 Sep 2019 00:39:39 -0700 (PDT)
Received: from mta8.iomartmail.com (mta8.iomartmail.com [62.128.193.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D10812084B; Thu, 26 Sep 2019 00:39:36 -0700 (PDT)
Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta8.iomartmail.com (8.14.4/8.14.4) with ESMTP id x8Q7dXw3012803; Thu, 26 Sep 2019 08:39:34 +0100
Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 839B02203B; Thu, 26 Sep 2019 08:39:33 +0100 (BST)
Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs1.iomartmail.com (Postfix) with ESMTPS id 6E9632203A; Thu, 26 Sep 2019 08:39:33 +0100 (BST)
Received: from LAPTOPK7AS653V ([87.112.72.158]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id x8Q7dSVx022810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 26 Sep 2019 08:39:32 +0100
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: draft-zhang-pce-resource-sharing@ietf.org
Cc: pce@ietf.org
Date: Thu, 26 Sep 2019 08:39:24 +0100
Organization: Old Dog Consulting
Message-ID: <00bc01d5743d$89693c20$9c3bb460$@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: AdV0PBwa8hOvLNhiTAKngPKw4ETJNg==
Content-Language: en-gb
X-Originating-IP: 87.112.72.158
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-24934.005
X-TM-AS-Result: No--18.786-10.0-31-10
X-imss-scan-details: No--18.786-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24934.005
X-TMASE-Result: 10--18.785500-10.000000
X-TMASE-MatchedRID: SZwsnQS1TAc/9d9Rtcc0Q6JVTu7sjgg1lFGUu7DBzhhtHpq0YbBRi2eG LC9y2ysxOHQMPkdZKVOJQE6dtGxyOUyO27FZOPGv7LuOEAY9BqT27Syjew41+LKeTtOdjMy61IT 6ihIyptbD+zC17DiLSqoqVJT6t2qTChTObk4Cb7/jxJDUku2PNhZSD+Gbjz3I7649n0TgA4k9Mh AW8ZTOY/F4AdJnW02pyhxVty87JW1zt4swJJfEYQPZZctd3P4BEDnDEqNPduqZfDRE1uqSgtWZD ZFp9sK+XZ9uwiJ9BzHiVHZUU4QDnpmvObnpEDjcFEiDvEGKJxbJ5SXtoJPLyDi//dZ3YI25tdBA /Ye69J0XxDANc7MuDgG+x76r1ZOgvUDyWU5LV4OdonALKgiNvKwmLjb7urxINadzXMzmvfo/sJJ rvRfE1Gitp0rwRDpPWYQ/NVzpo5Bo/KGUV8ExqIvNlIrJDKnMunSyiaV8TbP78VtsEK4eICyW7M C1GOnhzFzAoAIAqP6+ScOGRvQ7A8TGhdajQJfFgLf5GeDY2qMOZNXmvnJaen8ozV5Wwb505sZTw YHfBM7aaz6XaPMQyiifxa8hl4apkbfFSBkmVVc05OiRm60IbgeCHewokHM/pUhsal26H0dRLTER hRg1g2re8N4zYSDbg25QWLQyM7uZRBKsj/jrq8y6PPK75b2BPJb7oABYhT+fcVJ8cL8ZO3/WDu2 EM8cZB5lYfN/XeVp5xMgAEHdrO09OXLef1sAMM8XTtgUzttOaIhErJt0dLAbYcy9YQl6ebxTyq4 Bg+pCh9bMmqe83MQdiJPnMXEw20yMP1QZOu5KeAiCmPx4NwLTrdaH1ZWqCii7lXaIcF/Ww7M6dy uYKg/cUt5lc1lLgtT4piLWpY7p+3BndfXUhXQ==
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/kH9gKq-t-CZB-QrkBMet-tf2NHM>
Subject: [Pce] Review of draft-zhang-pce-resource-sharing-10
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: Thu, 26 Sep 2019 07:39:43 -0000
Hi, Now I'm no longer one of the PCE chairs, I have a little more time for reviewing works in progress. This document popped up as a candidate because it has been around for a long time and is now on its eleventh version. (It's also not too long, which makes it attractive.) I hope these comments are useful. Best, Adrian === Title OLD Extensions to Path Computation Element Protocol (PCEP) to Support Resource Sharing-based Path Computation NEW Extensions to the Path Computation Element Protocol (PCEP) to Support Resource Sharing-based Path Computation END --- Boilerplate You should reorganise the header sections to match with the current best practice. That it: Title File name Abstract Status of this memo Copyright Table of contents The requirements language should be moved to Section 1.1 or Section 2 where you should use the latest form of words... The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. That also gives you an additional Normative reference for 8174. --- Optional plurals. In English you do not need say things like "use common piece(s)". You can use the unequivocal plural and it is understood that it is optional. So you should say "use common pieces". Please s/(s)/s/ throughout the document. --- In the Abstract you have a use of "PCEP" before the expansion of the term. --- The last words of the Abstract are: which is a special case in the association path computation. This is slightly confusing because you haven't established what "association path computation" is. I suggest you might change the Abstract to read something like: Resource sharing in a network means two or more Label Switched Paths (LSPs) use common piece(s) of resource along their paths. This can help save network resource and is useful in scenarios such as LSP recovery or when two LSPs do not need to be active at the same time. A Path Computation Element (PCE) is responsible for path computation with such requirement. Existing extensions to the Path Computation Element Protocol (PCEP) allow one path computation request for an LSP to be associated with other (existing) LSPs through the use of the PCEP Association Object. The resource-sharing-based path computation with better efficiency can be achieved together with the association object in PCEP. This document extends PCEP to support resource sharing-based path computation as another use of the Association Object. --- Section 1 OLD provides an alternative way for providing NEW is a way to provide END Since "passive" and "active" have not yet been mentioned... OLD Unless specified, this document assumes a PCE mentioned is a stateful PCE (either passive or active). NEW Unless specified, this document assumes a PCE mentioned is a stateful PCE. END --- Global search and replace "a LSP" to "an LSP" --- In Section 1 you have: Furthermore, if there is resource sharing between new LSP and existing LSP, the two LSPs cannot exist simultaneously, the new LSP will replace the existing LSP(s). I know why you say this, because (obviously) you can't double-book resources. But I think that you can relax the requirement here especially for the case of protection and restoration. All you actually need is that both LSPs can't be active (i.e., carry traffic) at the same time. Actually, a little while later you talk about make-before-break where (obviously) both LSPs can exist at the same time. Of course, this is not a concern for the PCE, just for the LSP head-end, so perhaps it isn't a requirement to state here. Maybe just state it as an observation in this paragraph. But you will need to clean up the hole text, I think. For example, a little later you have: However, these objects are used to describe the relationship with two simultaneous LSPs, instead of a new one and an old one, which is different with the object proposed in this draft. ...and you say that like only one of the two LSPs will exist at any time, but (again) that is not consistent with MBB or other forms of protection. So this could be clarified to mean "used to carry traffic". --- In Section 1 but also the same slice of bandwidth in TDM networks. While true, this appears to be limiting to TDM where, I think, you intend the document to apply to any technology. So how about: but also the same slice of bandwidth in the network. --- Throughout the document, where you have written "this draft" say "this document" to future-proof yourself against becoming an RFC. Similarly s/proposed/defined/ --- Section 1 As mentioned in [RFC8231], the PLSP-ID is unique during a PCEP session between PCC and PCE. Such identification is helpful in supporting the above resource sharing requirement for standardization of stateful PCEs. With a unique identifier, the configuration of PCCs is greatly simplified. Instead of determining all the resources to be shared, the PCC could request resource sharing directly from PCE. This might be better as... As mentioned in [RFC8231], the PLSP-ID provides a unique identifier for an LSP during a PCEP session between PCC and PCE. Such identification is helpful in supporting the resource sharing requirement for stateful PCEs because it greatly simplifies the operation of a PCC. Instead of the PCC determining all the resources to be shared, the PCC can request that the PCE share the resources of a specific LSP: the stateful PCE is able to determine those resources itself. --- Section 1 In a multi-layer network, Label Switched Paths (LSPs) in a lower No need to expand "LSP" a second time, here. --- There is some misalignment of the sides of the stateful PCE in Figure 1 --- Section 2.1 If resources are shared between the old and new LSPs, there will be some 'interruption' when the traffic is switched from the old LSP to the new LSP. and later On the other hand, in some scenarios there are different policies, for example the LSP should be restored without any interruption with best effort. Well, didn't link N2-N3 just fail? So the interruption is probably already quite significant. You do go on to say An example can be found in Fig. 1 without failure on N2-N3 link, instead, an online re-optimization is needed for the working LSP (N1-N2-N3) from the stateful PCE. So I think you need to sort out two cases: 1. Repair after failure 2. Re-routing for optimization (or other reasons) For these, you may want to explain the benefits of shared resources: - may not be enough resource in the network to set up the 2nd LSP - may want to keep the 2nd LSP on the shortest path and might not be enough resources to do that - may want to reduce network programming time - may have some resource continuity (such as lambda) constraints But also the drawbacks: - switch-over in MBB may take longer because multiple nodes have to act to effect the switch - switch-over coordination may be harder because switching nodes are remote from the LSP end-points Your example LSP1 and LSP2 do highlight this successfully. --- I wonder whether Section 2.1 should also include notifying the PCE of which resources to avoid. That would certainly include the failed link (I am not sure that we can assume that the PCE has learned about the failure [through the IGP] as fast as the PCC learned about it through fault notification or signalling), but it might also include non-failed in case of rerouting [such as before planned maintenance]). --- The top of LSR H5 has become detached in Figure 2 --- The diagonals in Figure 3 are hard on the eye. Can you use single lines? Maybe... +----------------------+ | P-PCE | +----------+-----------+ / | \ / | \ / | \ / | \ / | \ / | \ +------+ +---+---+ +------+ |C-PCE1| |C-PCE2 | |C-PCE3| +------+ +-------+ +------+ ______________ ______________________ ______________ / \ / \ / \ | +---+ +---+ | | +---+ +---+ +---+ | | +---+ +---+ | | | A +-----+ B +-+--+--+ D +---+ E +---+ H +-+--+-+ J +----+ L | | | +---+ +---+ | | +---+ +---+ +---+ | | +---+ +-+-+ | | \ | | / \| | / | | \ | | / + | / | | \ | | / |\ | / | | \ +---+ | | +---+ | \| +---+ | | \| C +-+--+--+ G | | +----| K | | | +---+ | | +---+ | | +---+ | \_______________/ \______________________/ \______________/ --- In 3.1 you have: A sharing group should have multiple LSPs. The number of LSPs and the criteria for how LSPs share among each other are implementation dependent. Local path computation policies apply to different PCE and PCC, some examples can be found in section 2. I wonder whether "implementation dependent" might be better as "dependent on local policy". --- Section 3.2 has: The PCEP Resource Sharing group MUST carry the following TLV. It MAY be carried within a PCReq message from the network element (or other PCCs) so as to indicate the desired resource sharing requirements to be applied by the stateful PCE during path computation. It feels like a contradiction between the "MUST" and the "MAY". --- The figure in 3.2 seems to have surplus blank lines inserted. --- Section 3.2 Flags L, N, and B all say that the PCE "should prioritise" something. That is OK, but what happens if more than one bit is set? How are the prioritisations prioritised? --- Section 3.3 - If the Resource Sharing TLV is unknown/unsupported, the PCE will follow procedures defined in [RFC5440]. That is, the PCE sends a PCErr message with error type 3 or 4 (Unknown / Not supported object) and error value 1 or 2 (unknown / unsupported object class / object type), and the related path computation request is discarded. - If Resource Sharing TLV are unknown/unsupported and the P bit is set, the PCE MUST send a PCErr message with error type 3 or 4 (Unknown / Not supported object) and error value 4 (Unrecognized/Unsupported parameter), and the related path computation request MUST be discarded as defined in [RFC5440]. Now I'm confused! Is this a TLV or an Object? And how are these two paragraphs compatible? (I think it is a TLV.) --- Section 3.3 - If the resource sharing TLV is extracted correctly, the PCE MUST apply the requested resource sharing requirement. Yes, OK. Except that you have said this is subject to local policy which could (of course) mean that no sharing is done or even attempted. --- Section 3.3 Can you expand RSO on first use. --- According to WG policy, you'll need to include an "Implementation Status" section. Put it in now, even if you only say that you are not aware of any implementations at the moment. --- I'd love to see a Manageability Considerations section. It isn't compulsory, but it has become normal for the PCE WG. And you have some management things to talk about as you mention policies, and also as you have to coordinate alerts/fault reports from the network. You also have "The RSO flags may be locally configured..." --- Section 5.1 uses "TBA" but the txt uses "TBD" Please align these. --- Section 5.1 needs a little more detail to correctly direct IANA to the registry. You need some text such as... IANA maintains a registry called the "Path Computation Element Protocol (PCEP) Numbers" registry with a subregistry called the "Association Type Field" subregistry. IANA is requested to make an assignment from that subregistry as follows: Type | Name | Reference -----+----------------------+--------------- TBD1 | Sharing Association | [this.I-D] --- The heading of Section 5.2 has become indented --- Section 5.2 This section seems a bit jumbled. Have a look at Section 7.2 of draft-ietf-pce-association-diversity. You have numbered the bits from 0 as the right-hand bit, but the figure in section 3.2 has them numbered in the opposite way. You need to be consistent or include an explanation. Again, modeling on draft-ietf-pce- association-diversity might help. --- It would be helpful if you included the filename in the reference [H-PCE]. I think this is draft-ietf-pce-stateful-hpce. --- The Contributors section is hiding inside the Authors' Addresses and I missed it. I think that is just an indentation problem.
- [Pce] Review of draft-zhang-pce-resource-sharing-… Adrian Farrel
- [Pce] 答复: Review of draft-zhang-pce-resource-shar… Zhenghaomian