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

["Chengli (Cheng Li)" <[e-mail]>]

Hi Julien,

Sorry for my late reply, we have addressed the comments in revision 10.  https://datatracker.ietf.org/doc/html/draft-ietf-pce-binding-label-sid-10

Please check it.

Many thanks,
Cheng





-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
Sent: Tuesday, June 29, 2021 12:32 AM
To: Chengli (Cheng Li) <[e-mail]>; [e-mail]
Cc: [e-mail]
Subject: Re: [Pce] Shepherd's Review of draft-ietf-pce-binding-label-sid

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: '[e-mail]' <[e-mail]>; 
> [e-mail]
> Cc: [e-mail]
> 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:[e-mail]] On Behalf Of 
> [e-mail]
> Sent: Saturday, May 29, 2021 1:47 AM
> To: [e-mail]
> Cc: [e-mail]
> 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.