Hi Cheng, Thank you for addressing my comments. We now can move on.
Cheers, Julien On 19/07/2021 11:12, Chengli (Cheng Li) wrote: > 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: [email protected] [mailto:[email protected]] > Sent: Tuesday, June 29, 2021 12:32 AM > > 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. >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
