Hi Julien, Many thanks for the detailed review comments, we have fixed all the comments and new version is posted, please find the new-version and version-diff links below:
Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-pce-association-diversity Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-association-diversity-08 To answer your question: Complementary question: why an optional behavior (SHOULD) instead of mandatory (MUST)? -> Yes MUST is appropriate and updated in the new version. Thanks, Mahendra -----Original Message----- From: [email protected] [mailto:[email protected]] Sent: 28 June 2019 20:53 To: [email protected] Cc: [email protected] Subject: Shepherd Review of draft-ietf-pce-association-diversity-07 Hi authors, Please find below my detailed comments on draft-ietf-pce-association-diversity. I originally started to review -06. Thanks for posting -07 after Dhruv's comments, as it addressed some on mine as well. The main technical concern lies in section 4.6, in case no solution is found by the PCE. Section 4.3, about SVEC, relies on PCRep with NO-PATH, which is consistent with existing PCEP specification. IMHO, section 4.6 is confusing and incomplete. What about the following? OLD [...] the PCE SHOULD reply with a PCUpd message containing an empty ERO. In addition to the empty ERO Object, the PCE MAY add the NO-PATH-VECTOR TLV [...] NEW [...] the PCE MUST reply to a request (PCEReq) with a PCRep message containing a NO-PATH object. In case of network event leading to an impossible strict disjointness, the PCE SHOULD send a PCUpd message containing an empty ERO to the corresponding PCCs. In addition to the NO-PATH or the empty ERO object, the PCE MAY add the NO-PATH-VECTOR TLV [...] Complementary question: why an optional behavior (SHOULD) instead of mandatory (MUST)? Nits: ------ Global and usual nit: the flag name. The I-D has a collection of X flag/X-flag/X-Flag/flag X/etc that needs consistency. Many PCEP documents use "X flag". ------ Title --- - s/communication Protocol (PCEP) extension for signaling LSP diversity constraint/Communication Protocol (PCEP) Extension for LSP Diversity Constraint Signaling/ ------ Abstract --- - s/Communication Protocol/communication Protocol/ - s/knows that LSPs in the same group/knows that the LSPs in the same group/ - s/needs to/need to/ ------ 2. Terminology --- - s/Communication Protocol/communication Protocol/ ------ 3. Motivation --- - s/above, consider that/above, let us consider that/ - s/difficult. Whereas, computation/difficult, whereas computation/ - s/These messages uses/These messages use/ - s/the disjoint path computation/a disjoint path computation/ - s/disjoint group-ids/disjoint group IDs/ - s/should allow to overcome/allows to overcome/ - s/association source could/the association source could/ ------ 4. Protocol extension --- - s/Protocol extension/Protocol Extension/ - s/Association group/Association Group/ - s/TLVs - Global Association Source or Extended Association ID are included/TLVs - Global Association Source or Extended Association ID - are included/ - s/to uniquely identifying/to uniquely identify/ - s/Association object -/Association object:/ - s/[I-D.ietf-pce-association-group] specify/[I-D.ietf-pce-association-group] specifies/ - s/in the PCEP messages/in PCEP messages/ - s/Refer [I-D.ietf-pce-association-group]/Refer to [I-D.ietf-pce-association-group]/ - s/more LSPs. But a PCE/more LSPs, but a PCE/ - s/in how many LSPs/in the number of LSPs/ - s/vendor specific behavioral information/vendor-specific behavioral information/ - OLD When unset, PCE is allowed to relax disjointness by using either applying a requested objective function or any other behavior if no objective function is requested (e.g.: using a lower disjoint type (link instead of node) or relaxing disjointness constraint fully) NEW When unset, the PCE is allowed to relax disjointness by either applying a requested objective function (cf. section 4.4 below) or using any other behavior if no objective function is requested (e.g. using a lower disjoint type (link instead of node) or fully relaxing disjointness constraint). - s/The flags L, N, and S/The L, N and S flags/ - s/The flag P/The P flag/ - s/the flag T/the T flag/ - s/both SVEC and ASSOCIATION object/both SVEC and ASSOCIATION objects/ - s/in SVEC object/in the SVEC object/ - s/with NO-PATH object/with a NO-PATH object/ - s/Disjointness objective functions/Disjointness Objective Functions/ - s/The PCEP OF-List TLV allow/Whereas the PCEP OF-List TLV allows/ - s/Incompatible OF codes/Incompatible OF code/ - s/listed below -/listed below:/ - The last example at the end of section 4.4 shows that the specification doesn't prohibit redundant constraints. I would be nice to add a sentence explicitly stating that in the previous paragraph. - s/P-flag considerations/P Flag Considerations/ - s/fulfill the customer requirement/fulfill customer's requirements/ - s/Consider, this customer/Let us consider that this customer/ - s/( and/(and/ - s/allows a simple expression that/allows to simply express that/ - s/If PE->PE2/If PE1->PE2/ - Many P-flag/P-Flag to be fixed in section 4.5. - s/Disjointness computation issues/Disjointness Computation Issues/ - s/T-bit/T flag/ [x2] ------ 5. Security Considerations --- - s/which do not/which does not/ - s/defines following new PCEP TLVs/defines the following new PCEP TLVs/ - s/PCEP-ERROR codes/PCEP-ERROR Codes/ - s/defines new Error-Type and Error-Value/defines new Error-Value within existing Error-Type/ - s/Incompatible OF codes/Incompatible OF code/ ------ 8. Acknowledgements --- - s/to author of/to the authors of/ ------ Thanks, 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
