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: '[email protected]' <[email protected]>; > [email protected] > Cc: [email protected] > 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:[email protected]] On Behalf Of [email protected] > Sent: Saturday, May 29, 2021 1:47 AM > To: [email protected] > Cc: [email protected] > 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. _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
