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/I
