Last Call Review of draft-ietf-pce-association-diversity-08

Request Review of draft-ietf-pce-association-diversity
Requested rev. no specific revision (document currently at 15)
Type Last Call Review
Team Routing Area Directorate (rtgdir)
Deadline 2019-08-16
Requested 2019-07-19
Requested by Deborah Brungard
Authors Stephane Litkowski, Siva Sivabalan, Colby Barth, Mahendra Negi
Draft last updated 2019-08-12
Completed reviews Rtgdir Last Call review of -08 by Emmanuel Baccelli (diff)
Secdir Last Call review of -10 by Rifaat Shekh-Yusef (diff)
Genart Last Call review of -10 by Dale Worley (diff)
Prep for Last Call
Assignment Reviewer Emmanuel Baccelli
State Completed
Review review-ietf-pce-association-diversity-08-rtgdir-lc-baccelli-2019-08-12
Posted at
Reviewed rev. 08 (document currently at 15)
Review result Has Issues
Review completed: 2019-08-12



I have been selected as the Routing Directorate reviewer for this draft.
The Routing Directorate seeks to review all routing or routing-related
drafts as they pass through IETF last call and IESG review, and sometimes
on special request. The purpose of the review is to provide assistance to
the Routing ADs. For more information about the Routing Directorate, please

Although these comments are primarily for the use of the Routing ADs, it
would be helpful if you could consider them along with any other IETF Last
Call comments that you receive, and strive to resolve them through
discussion or by updating the draft.

Document: draft-ietf-pce-association-diversity-08.txt
Reviewer: Emmanuel Baccelli
Review Date: 12/08/2019
Intended Status: Standards Track

Summary of comments:

    The procotol extension is simple, and its operation is documented
pretty well.
    The document is concise, and clear from my point of view.
    See below a couple of remarks that could be considered prior to

Major Issues:

    No major issues found.

Minor Issues:

    In Section 5 (Security): If I understand correctly, dynamically adding
a new LSP to an existing disjoint association affects the (re)computation
and the (re)characterization of all LSPs in this association. In this case,
is it entirely obvious to me that there is no specific threat using the
attack vector of adding an LSP to an existing association, when flag T is
What is the state of other LSPs in an existing association after another
LSP was added, which resulted in the required disjointness now fails?


    In Section 3 (Motivation): In my opinion, this section might benefit
from being split in two: a pure motivation section, and an applicability

    In Section 4.1: it is stated that "a PCE may be limited in the number
of LSPs it can take into account when computing disjointness" [...] "the
PCE may provide no path, a shortest path, or a constrained path based on
relaxing disjointness, etc.  The disjoint status is informed to the PCC."
Here, it would be useful to forward reference to section 4.6.

    In section 4.6: the spec seems to suppose that there exists an absolute
order ranking different levels of disjointness,
such that a PCE can simply take the decision to "reduce disjointness" to
the next best level.
I suspect that this is not always easy to rank in complex cases, if at all

Are some more flags foreseen (tbd in section 6.2 ?) for more fine-grained
characterization of "relaxed disjointness" in complex cases e.g. when
adding an LSP to an already-large disjoint association ?
I assume the answer is "not really".

Assuming the above, without becoming too ugly, specification could be more
explicit about ranking levels of disjointness which relaxing decisions
should be made, when flag T is unset.
Else, the spec could add a clarifying sentence on the difficulty of
ordering absolutely many different levels of disjointness for many LSPs, in
the same association.