[Pce] draft-ietf-pce-controlled-id-space review

Boris Hassanov <bhassanov@yahoo.com> Tue, 11 June 2024 12:04 UTC

Return-Path: <bhassanov@yahoo.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 6048FC151071 for <pce@ietfa.amsl.com>; Tue, 11 Jun 2024 05:04:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.107
X-Spam-Level:
X-Spam-Status: No, score=-7.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQiC9xIQu2qo for <pce@ietfa.amsl.com>; Tue, 11 Jun 2024 05:04:07 -0700 (PDT)
Received: from sonic319-28.consmr.mail.bf2.yahoo.com (sonic319-28.consmr.mail.bf2.yahoo.com [74.6.131.83]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AB05C1519AE for <pce@ietf.org>; Tue, 11 Jun 2024 05:04:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1718107446; bh=nC0zHfkwxrHRLihn6JNX+egmyIUZQK91+eXmvAAjH5o=; h=Date:From:To:Subject:References:From:Subject:Reply-To; b=M8ZAO5H4K8Ej6YeavBzs0HkAxXf5Q6IXhXi5gvRbBy1sxoIqN11DkN+sHlFAKmWUukIhh8muEv1HSgmmU7WtUgFzc618J8KW7F6lSlKmqzIXYfC+183K/ljDXByVoJHYLrjEZM/1h2aC+M317TG25z4HBoB9cYhM8ynoV/0HASMmCaNHRpIDgT4qNfaqY30mSszasbuARahmDnkJvSstJ2Rd+27RCafrZ641RoZ0deKvMgIq3yp8UqI88QVv+UFOfQ2Qn15tgeF/t2IIMU5u1oqmoASUR4V0WtuQ96VekxrX4YJN46KOicmMoLienF8zJXmEgRZ0VVy5KJ1G2mz44w==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1718107446; bh=nedYWVQ5aCYGNhoNLGIsBaKsZ47qML87ZYy3EvbWXVI=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=jUCbxhJLJ/Uc9RDU2/MxAIuY8SSJIOKAQnMljAljW5CUTg6d6s8r3xOqVUexhu4seAAFlj/0KpmYHvbVXLqB5n+JLrTnQ9FCQ/LizfmgsNrXh35Ir7OQnWxxPqj4xpTh6QvlLfOQPjv07cnQHczzAYJwKs10h3PKMZohh3r8bj5dnxeQYreYEumdSivKC/myXY4UjXpaanfu9Rzz0Mrldgc9ICdhz1jjRCMrxp3HsJ/1OuEH73rMgbDjbp+pNczWoBY4A11e/it1WHXZvFBcIMWUUps6SN/jPQc/sIApoI1c4YXlOsT1eCB3gDk1j7dp/5nwTrBjJCgNujJY8MSAPw==
X-YMail-OSG: xoytkncVM1mB2F_DWEZewvKP7Z_vaAzDfUnfHo8rIut2PodNlxoiilaPhQ4aNrv Gu3LRisl.lwFsaQcsQKYaT20loHzTbN.OI6YFJnw_WdXDxWFvqHDpj7ArqGGslJvMhI1.PvT43Ct WIb0LrPKCzVG_pTTEQ0voYYbZacKlvDeWhFQF_6B_FP.XKN1IXUakQ_E6YWZ0r82gmn2U4_akwwl Z6XQysazxVxaMgv7PPyh_9.c8qwS7OqkxaYvkelvsnuA2pryer68mLHMqGBqkzzeBM0ZUbVtKXpB 0_fgSzjA1U3sxg3PYz9QiovlVX7hOJi5PnhVF_SW86Zwa8TAipCedHjy4ERMwQkVAGuNc7ecDZ5C _GWiUQcpgiInHAaheaQkr4t6nmcYrkdv.HZ.FlkROvFrjRGPS244ER9CkMNO4DbSB8jZGJFdBKOY eLyOq.hr6Cu1aKb8m5Mkdj1.OiCIX8nED6R0qwDlYtPNxUcnZKN2Zbz2p_XaU5fbhF37w7UYTqZH Ke9N_iAUD6sHL5E9Udk2326L1_kSQFyRpNkWI6gUoP1SanzYeukJF0qnNqeOtJM5B87ontSuD5JS fNMlo8dXskgPqPM0x0tAOzrgfu9byAS0kX5Zc0R3hhP6cg.KHG37oD44n.Hl8Ug2mUk7thsp788N YKesyWVRrhQUJGd97xBYF0HY_VDOzNpv7BNLBKH7IxOTXCGXxHhc6XlCHoVEo1V58QwivI8bvpMH krVu3zaU_fmnEaLdfFLO2XQsHGIfkhpdwIMYrMAtgwlqP1R16J_JlRKPPdZpp4n2rb0nr2PtcTw7 YTQTBfqnyU8MMVzp0c9EaCIfUPgNFrM5PXyxgz1.eiIrozFRzymTFUpneKlZMjsbAqfHcaIMslVG aARg_ie9lL.KQxbmcaRBA2oJL6oHd4YILkWVoyX45tzdXg_iENG6wBXLRTz0YDGpq0qsorwI8.Ur GeQNmzpiLcqYoNZauLDPyFHc2_LB1k0TffEPPvRNL1iHgVDQtlnBce26EHeiYCjNwJ2gSRMhMnyO SSFIAAtjkl1nZ531XHPUxVi4ooYlctJLkjsPo15nH83W6v7Tyvfh2olSpI0TolHlvUhzJMPpH1Iu 4S_9MbD1vg_t1SqONjbWqM7fI7RYFkpboNvc1mz7rvzGXWQwdAU.ASgGc2sSlZD7qnagu6tynBz7 hLLgxcSpOS2m7ti6RNO9chYHhNDRliQYy17qkzXS853RiaN9h0oeKgdqOJNhnM7eOSKEEiPlvv7x ZOWVOQzHpxcxCza7uAeUsvmkA.WY8M3214O0NbwMXMyvuksk5e7ue68PM3Ip2Ayp.AXh9G1oZxt8 JLbBfEu_Nu0HW0E2yFExzbgvBuigvp2RIC5oXiG2vsJw7I5SZxWM86covN.KyaQJH2BkXxRzNQn6 3.YyNOZWcm3QGhd6O8UqXlvCSck20JV1p41nA3W75lZRLp7GF48um2Tw4qyJEcHjLFuN3Te_PSwb PMHz55r4jI_Vhs.frfrtd0LXIEM6NcSZD2NigUgpNgd0YqQ50QTKPWUt.sy1TsGbs5lRzNdnvQU. v7XpTyBjgjseVc.SOTl6iFpuhJYfJI17i0IziEL_wbZ9zExf2JofKW12F0Lcv4.jlosb8qYYm0Zm LAPlepw7uDUL2P9odSFyRCI9EyyuUe2FnGsR9BE3REwMv0lJwxm4hhLEHZGM4JSvsyiPxGfAdLRL 0UUCECtW4.cHoW83Jbt1NNIa3Ye7FUCY1tbI0n6Dz7U0y7Jus6wCZeLUPRtX0v5YS7nrbl7izvnV n5aivHatjcxFZH5xc8zZU84vgisbjQ0Ql.1J7AD7REtkhSEtFA3hL9pk4dzi4djbHUIflYGpvJL9 uEHBdFC8nGEp_lq9SfsrDImBvw_qZcjOcOlrH72USsTQkdw7ASb9nv8chQg3EgFJ9uzEzoANsZY7 xreTU2df0IXY2qRvdEyFAeuDD.4b1dXYUM4ZyhE4QFcbilbQrIbSNcU4AEJy.3LP2rTt.kRySEcJ oVRWQEDzdpwiiOHUFCD3wNzYicBPRcD8TBi07WsmdBQiQ3KY6dp1zRo4jiY39PnAWwD_zfKUAtbE xfXlPFm7hxfwSELdvaOatoD_77r2s0AWRuYy9dXkf5usxR2jYyGhNQsUYEz8AT3uergUmXu_Mn3w ESjtK9PSrCq_Dnq.8Z_p0IDqC4Tw4ilGutI1D.1LBqrAmMUxrrKT5g..AStf3RqnoD8CCPDujkzf RBempOg--
X-Sonic-MF: <bhassanov@yahoo.com>
X-Sonic-ID: 65e6d11c-cfdd-425c-b904-abf2569eddce
Received: from sonic.gate.mail.ne1.yahoo.com by sonic319.consmr.mail.bf2.yahoo.com with HTTP; Tue, 11 Jun 2024 12:04:06 +0000
Date: Tue, 11 Jun 2024 12:03:30 +0000
From: Boris Hassanov <bhassanov@yahoo.com>
To: "pce@ietf.org" <pce@ietf.org>
Message-ID: <1991352543.2452570.1718107410986@mail.yahoo.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_2452569_1981346095.1718107410984"
References: <1991352543.2452570.1718107410986.ref@mail.yahoo.com>
X-Mailer: WebService/1.1.22407 YMailNorrin
Message-ID-Hash: Z4LEKNXXBJSJ2RVLGVFQJA6SQTQ22GSE
X-Message-ID-Hash: Z4LEKNXXBJSJ2RVLGVFQJA6SQTQ22GSE
X-MailFrom: bhassanov@yahoo.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-pce.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Pce] draft-ietf-pce-controlled-id-space review
List-Id: Path Computation Element <pce.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/hSv3G9sL0mGSQV9Mz2hM9qS3Syw>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Owner: <mailto:pce-owner@ietf.org>
List-Post: <mailto:pce@ietf.org>
List-Subscribe: <mailto:pce-join@ietf.org>
List-Unsubscribe: <mailto:pce-leave@ietf.org>

Hi all,
I missed the WG LC for the draft, thus being late but anyway -  I made the review below and share my thoughts too. I support  this draft due to its importance, i.e.  during my work on an in-house SDN controller with PCE capability, I did a lot of PCEP testing for 4 major network equipment vendors.  All of them have different SRGB/SRLB ranges so we had to add additional complexity for defining each vendor type and hardcode those ranges. Such static approach is not good  in a long term. That is why it is a very practical and useful solution.My comments (mainly cosmetic) about the  text and suggestions  for a change are after -> sign.
SY,Boris

Review : Path Computation Element Communication Protocol (PCEP) extension to advertise the PCE Controlled Identifier Space                                                     draft-ietf-pce-controlled-id-space-00



Abstract In some use cases, such as PCECC or Binding Segment Identifier (SID) for Segment Routing (SR), there are requirements for a stateful PCE to make allocation of labels, SIDs, etc. ->  In some use cases, such as PCECC or Binding Segment Identifier (SID) for Segment Routing (SR) provisioning,  there are requirements for a stateful PCE to allocate the labels, SIDs, etc. 
These use cases require PCE aware of various identifier spaces from where to make allocations on behalf of a PCC. -> These use cases require PCE to be aware of various identifier spaces from where to make allocations on behalf of a PCC. 
This document describes a generic mechanism for a PCC to inform the PCE of the identifier space set aside for the PCE control via PCEP.  -> This document describes a generic mechanism for a PCC to inform the PCE about the identifier space which is outside of the PCE control via PCEP. (IMO it sounds a bit clearer.)

1.  Introduction For supporting stateful operations, [RFC8231] specifies a set of extensions to PCEP to enable stateful control of LSPs within and across PCEP sessions in compliance with [RFC4657]. ->  For supporting stateful operations, [RFC8231] specifies a set of extensions for PCEP to enable stateful control of LSPs within and across PCEP sessions in compliance with [RFC4657].
Furthermore, [RFC8281] describes the setup, maintenance, and teardown of PCE-initiated LSPs under  the stateful PCE model without the need for local configuration on the PCC, thus allowing for a dynamic network that is centrally controlled and deployed. -> Furthermore, [RFC8281] describes the setup, maintenance, and teardown of PCE-initiated LSPs under the stateful PCE model,without the need for local configuration on the PCC, thus allowing for a dynamic network communications which are centrally controlled and deployed.
This documnet adds the capability to advertise the label range via a PCEP extension. ->  This document adds the capability to advertise the label range via a PCEP extension. (misprint in 'document')
4.  Overview
 A PCC can include a corresponding ID-CONTROL-SPACE TLVs in the OPEN Object to inform the  corresponding ID space information that it wants the PCE to control. ->  A PCC MAY include a corresponding ID-CONTROL-SPACE TLVs in the OPEN Object to inform the corresponding ID space information that it wants the PCE to control. This is an optional TLV, the PCE could be aware of the ID space from some other means outside of PCEP.-> This is an optional TLV, the PCE MAY be aware of the ID space from some other means outside of PCEP.
This section does not have an explicit description what if PCE does not support ID-CONTROL-SPACE TLV, should it send PCErr or just ignore it?
5.1.2.  FUNCT-ID-CONTROL-SPACE TLV
The length equals to LB length + LN length in the SID Structure. -> LB (Locator Block ?) and LN abbreviations need to be explained here or in separate section for used abbreviations.
P.S.I also support Samuel's comment about  defining an addition sub-type of delegated space and a synchronization issue in case of several PCEs, it sounds reasonable and useful.

The end of review.


On Tuesday, June 4, 2024 at 11:29:02 AM GMT+3, Boris Hassanov <bhassanov@yahoo.com> wrote:

Hi Dhruv and all!Sorry for delay, will review on this week.

Thank you.
SY,Boris