Hi Mahendra, This revision looks good. Thanks.
Julien On 05/07/2019 06:40, Mahendra Singh Negi wrote: > 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: julien.meu...@orange.com [mailto:julien.meu...@orange.com] > Sent: 28 June 2019 20:53 > > 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. > _________________________________________________________________________________________________________________________ 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 Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
