Re: [Pce] Shepherd's Review of draft-ietf-pce-binding-label-sid

julien.meuric@orange.com Mon, 28 June 2021 16:32 UTC

Return-Path: <julien.meuric@orange.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 BA6283A0DA1; Mon, 28 Jun 2021 09:32:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.825
X-Spam-Level:
X-Spam-Status: No, score=-0.825 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, FORGED_MUA_MOZILLA=2.309, NICE_REPLY_A=-0.338, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.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 RL9Qc-fSXzob; Mon, 28 Jun 2021 09:32:11 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.40]) (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 4926E3A0DA5; Mon, 28 Jun 2021 09:32:11 -0700 (PDT)
Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfedar21.francetelecom.fr (ESMTP service) with ESMTPS id 4GDCn35Kmhz7tZ9; Mon, 28 Jun 2021 18:32:07 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1624897927; bh=53buhcXNIXa2KDmLDTxl3VGg8ImuUeakNjID22UHN4s=; h=Subject:To:From:Message-ID:Date:MIME-Version:Content-Type: Content-Transfer-Encoding; b=npvGrsbPAvqOPHwd0Om8trVmdrh2GC7lUYQH4OHyBsdYpfJwFIXFaHc6TOEUj7CG5 hwCI8jyrGB5uodO83X5ENhNaFoeqo3qm+u3XKMxcsuStqCLFWVo5IyG+LykibYcGzE D5WcaxbwmVBqdfCTbPIIk5QuINjCA5dwmxUMH2nLAXCTtpSe+ijyempas3Jtxr7fKX GISBVbNnenU/0tRAr/uIl1Z7rNnLgHz25Trgj+E8rFRW60GzcAmxDIKqWTOFmdyq3v dALjbf0i70UzUO4PzBlnhX6k1XDX5rz24k4q1DEelAmFgTcKj8W6EMpHyPCcDslLBB siprfkziXbffg==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfedar01.francetelecom.fr (ESMTP service) with ESMTPS id 4GDCn34466zBrLp; Mon, 28 Jun 2021 18:32:07 +0200 (CEST)
Received: from [10.192.150.121] (10.114.13.247) by exchange-eme6.itn.ftgroup (10.114.13.29) with Microsoft SMTP Server (TLS) id 14.3.498.0; Mon, 28 Jun 2021 18:32:06 +0200
To: "Chengli (Cheng Li)" <c.l@huawei.com>, "draft-ietf-pce-binding-label-sid@ietf.org" <draft-ietf-pce-binding-label-sid@ietf.org>
CC: "pce@ietf.org" <pce@ietf.org>
References: <1fac71ae-2c0b-d0ab-2829-12f45b2c54e9@orange.com> <e817928c50084382a5d2515e77cb0b55@huawei.com>
From: <julien.meuric@orange.com>
Organization: Orange
Message-ID: <32730_1624897927_60D9F987_32730_104_1_c3f38cb5-6e51-e6b6-2199-e973d65b4546@orange.com>
Date: Mon, 28 Jun 2021 18:32:06 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <e817928c50084382a5d2515e77cb0b55@huawei.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Originating-IP: [10.114.13.247]
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/FNp9YX1rUp78J7CmqCdlmYe0EOw>
Subject: Re: [Pce] Shepherd's Review of draft-ietf-pce-binding-label-sid
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, 28 Jun 2021 16:32:17 -0000

Hi Cheng,

Thanks for the update and sorry for the late feedback.

I've spotted a couple of nits:
- In the abstract, s/It further specify/It further specifies/
- In the intro:
    * I'd put the word "either" after the word "using" (cf. below);
    * a space was mistakenly dropped on "aPath".

About the issue left open below, the text currently says "The PCE SHOULD
allocated [...] and respond". Either you should mention what happens
when this SHOULD doesn't apply or you may consider upgrading to MUST.

Regards,

Julien


On 03/06/2021 09:54, Chengli (Cheng Li) wrote:
> Hi Julien,
>
> We have updated to document to address your comments, please check.
>
> URL:            https://www.ietf.org/archive/id/draft-ietf-pce-binding-label-sid-09.txt
> Status:         https://datatracker.ietf.org/doc/draft-ietf-pce-binding-label-sid/
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-pce-binding-label-sid
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-binding-label-sid-09
>
> Only one comment left: 
>
> - The paragraph about by-PCE allocation should say what happens otherwise, i.e. error behavior.(Section 8)
>
> I don't know what kind of error  will happen, it seems not error will occur.
>
> Thanks for the deep review!
> Cheng 
>
>
>
>
>
> -----Original Message-----
> From: Chengli (Cheng Li) 
> Sent: Saturday, May 29, 2021 9:18 AM
> To: 'julien.meuric@orange.com' <julien.meuric@orange.com>om>; draft-ietf-pce-binding-label-sid@ietf.org
> Cc: pce@ietf.org
> Subject: RE: [Pce] Shepherd's Review of draft-ietf-pce-binding-label-sid
>
> Hi Julien,
>
> Many thanks for your comments! Will address the comments and then post the new revision for discussion ASAP.
>
> Respect,
> Cheng
>
>
>
>
>
> -----Original Message-----
> From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of julien.meuric@orange.com
> Sent: Saturday, May 29, 2021 1:47 AM
> To: draft-ietf-pce-binding-label-sid@ietf.org
> Cc: pce@ietf.org
> Subject: [Pce] Shepherd's Review of draft-ietf-pce-binding-label-sid
>
> Dear authors,
>
> Please find below the review of the aforementioned document.
>
> _Summary_
> The document looks ready for publication, but the fixes below should be considered.
>
> _Issues_
> None.
>
> _Nits_
> ------
> Abstract
> ---
> - The phrase "network opacity" feels like a negative objective. How about "network confidentiality"?
> - s/RSVP-TE signaled Traffic/RSVP-TE-signaled Traffic/
> - s/Label Switching Path/Label Switched Path/
>
> ------
> 1. Introduction
> ---
> - s/either set up using the RSVP-TE signaling protocol or Segment Routing/set up using either the RSVP-TE signaling protocol or Segment Routing/
> - s/headend node/head-end node/  [x2, for consistency along the I-D]
> - s/an Segment Routing Policy/a Segment Routing Policy/
> - s/an Segment Routed (SR) Policy/a Segment Routing (SR) Policy/
> - s/enables instantiation/enables the instantiation/
> - s/type of interfaces or tunnel/type of interface or tunnel/
> - s/SID-list/SID list/
> - s/Path Computation Element Protocol/PCE communication Protocol/
> - s/a network controller (acting as a PCE) /a PCE (acting as a network controller)/
> - s/SID allocated by it/SID it allocated/ OLD
>    A PCC could report the binding label/SID allocated by it to the
>    stateful PCE via Path Computation State Report (PCRpt) message.
> NEW
>    A PCC could report to the stateful PCE the binding label/SID it
>    allocated via a Path Computation LSP State Report (PCRpt) message.
>
> - s/Path Computation Update Request (PCUpd) message/Path Computation LSP Update Request (PCUpd) message/
> - s/an MPLS label or SID/an MPLS label or a SID/
> - s/PCE based/PCE-based/
>
> ------
> 3. Terminology
> ---
> - "TLV" is flagged as "well know" in the RFC Editor's list
> (https://www.rfc-editor.org/materials/abbrev.expansion.txt): it can safely be removed from this section (otherwise, it should have been expanded at 1st occurrence in the introduction).
> - "PCE" is similarly flagged, but PCC and PCEP aren't, so it can be kept (adding a period at the end of the line).
> - s/Path Computation Element Protocol/Path Computation Element communication Protocol/
>
> ------
> 4. Path Binding TLV
> ---
> - s/TLV is called/TLV called/
> - Since it's already allocated, Figure 2 may include the codepoint, i.e.
> "Type = 55".
> - s/TLV comprise of:/TLV comprises:/
> - s/and first 20 bits/and the first 20 bits/
> - s/a 16 octet IPv6 address/a 16-octet IPv6 address/
> - s/Note that, multiple/Note that multiple/
> - s/Following flag/The following flag/
> - s/For the BT as 0/When the BT is 0/  [idem w/ 1 and 2]
> - s/the 32-bits represent/the 32 bits represent/
> - s/the 128-bits represent/the 128 bits represent/
> - s/This section specify/This section specifies/
> - s/The Binding Value consist of/The Binding Value consists of/
> - s/The 128-bits IPv6 address/The 128-bit IPv6 address/
>
> ------
> 5. Operation
> ---
> - s/via PCRpt message/via a PCRpt message/
> - s/send PCErr with/send a PCErr with/
> - s/existing instances/the existing instances/
> - s/the old binding value/the former binding value/
> - s/the old TE-PATH-BINDING TLV/the former TE-PATH-BINDING TLV/
> - s/Note that, other instances/Note that other instances/
> - s/a specific binding value(s)/a (or several) specific binding value(s)
> - s/Note that in case of an error,/Note that, in case of an error,/
> - s/can carry/can include/
> - s/request withdrawal/request the withdrawal/  [x2]
> - s/the old binding value/the former binding value/
> - s/the old TE-PATH-BINDING TLV/the former TE-PATH-BINDING TLV/
> - s/making the length field of the TLV as 4/bringing the Length field of the TLV to 4/
> - s/request PCC/request a PCC/
>
> ------
> 8. PCE Allocation of Binding label/SID
> ---
> - s/on its own accord/of its own accord/  [x2]
> - s/A PCC would set this bit/A PCC MUST set this bit/
> - s/A PCE would set this bit/A PCE MUST set this bit/
> - s/towards PCC/towards the PCC/
> - s/a PCE would set this bit to 0/a PCE MUST set this bit to 0/
> - s/a PCE could set/a PCE MUST set/
>
> - OLD
> A PCC could request that the PCE allocate the binding label/SID by setting P=1, D=1, and including...
>   NEW
> To request that the PCE allocate the binding label/SID, a PCC MUST set P=1, D=1, and include...
>
> - s/The PCE would allocate/The PCE SHOULD allocate/
> - The paragraph about by-PCE allocation should say what happens otherwise, i.e. error behavior.
> - s/out of scope of/out of the scope of/
>
> ------
> 9. Implementation Status
> ---
> - Huawei: "An experimental code-point is used and plan to request early code-point allocation from IANA after WG adoption." If the implementation doesn't use the early allocated code point, I wonder if it was worth the effort.
> - Cisco: "An experimental code-point is currently used." Currently in April 2021? Same comment as above.
>
> ------
> 11. Manageability Considerations
> ---
> - s/the policy based on which PCC needs to allocates /the policy the PCC needs to apply when allocating/
> - s/Mechanisms defined/ The mechanisms defined/  [x4]
> - s/to PCEP extensions defined/to the PCEP extensions defined/
>
> ------
> 12. IANA Considerations
> ---
> - The new Error-Type entry should include Error-value 0 as Unassigned.
>
> ------
> 14. References
> ---
> - When reading section 7, draft-ietf-pce-segment-routing-ipv6 really felt like a normative reference: it should be moved to section 14.1.
>
> ------
>
>
> Cheers,
>
> Julien
>
>


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.