Re: [Pce] Alvaro Retana's No Objection on draft-ietf-pce-association-diversity-12: (with COMMENT)

[Alvaro Retana <[e-mail]>]

Thanks for addressing my comments!

Alvaro.

On December 19, 2019 at 11:14:40 AM, Mahend Negi ([e-mail])
wrote:

Hi Alvaro,

Thanks for the detailed review, all the comments are addressed in the new
version.

New version:
https://tools.ietf.org/html/draft-ietf-pce-association-diversity-13
https://datatracker.ietf.org/doc/html/draft-ietf-pce-association-diversity-13

Diff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-association-diversity-13

Regards,
Mahendra

On Tue, Oct 29, 2019 at 1:56 AM Alvaro Retana via Datatracker <
[e-mail]> wrote:

> Alvaro Retana has entered the following ballot position for
> draft-ietf-pce-association-diversity-12: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-pce-association-diversity/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> (1) §5.1: I-D.ietf-pce-association-group is not explicit about the
> "capability
> exchange mentioned in this piece of text:
>
>                  This capability exchange for the Disjointness
>    Association Type (TBD1) MUST be done before using the disjointness
>    association.  Thus the PCEP speaker MUST include the Disjointness
>    Association Type in the ASSOC-Type-List TLV before using the Disjoint
>    Association Group (DAG) in PCEP messages.
>
> It seems to me that the exchange implies sending and receiving the
> Assoc-type,
> but then the second sentence implies sending to be enough.  What is the
> expected behavior?  Please reword.
>
> (2) §5.2 says, while defining the T flag, says that "if disjoint paths
> cannot
> be found, PCE SHOULD return no path", but §5.6 reads:
>
>    When the T flag is set (Strict disjointness requested), if
>    disjointness cannot be ensured for one or more LSPs, the PCE MUST
>    reply to a Path Computation Request (PCReq) with a Path Computation
>    Reply (PCRep) message containing a NO-PATH object.
>
> There is a conflict between the SHOULD and the MUST.
>
> (3) TBD1 is used with 3 different names: "Disjoint Association Type (DAT)",
> "Disjointness Association Type" and "Disjoint-group Association".  Please
> be
> consistent.
>
> (4) [nits]
>
> s/DISJOINTNESS-CONFIGURATION-TLVSection 5.2/DISJOINTNESS-CONFIGURATION-TLV
> (Section 5.2)
>
> s/SHOULD NOT try to add/SHOULD NOT add
>
> s/with example inA Section 5.5/with an example in Section 5.5
>
> s/by Section 5.5either/by either
>
> s/Setting P flag/Setting the P flag
>
> s/case of network event/case of a network event
>
>
>