Path Computation Element Communication Protocol (PCEP) Extension for Label Switched Path (LSP) Diversity Constraint Signaling

Note: This ballot was opened for revision 10 and is now closed.

Deborah Brungard Yes

(Ignas Bagdonas) No Objection

Alissa Cooper (was Discuss) No Objection

Comment (2020-01-24 for -13)
Thanks for addressing the Gen-ART review comments.

Roman Danyliw No Objection

Comment (2019-10-30 for -12)
Section 6.  Per “Also, as stated in [I-D.ietf-pce-association-group], much of the information carried in the Disjointness Association object, as per this document is not extra sensitive”, I appreciate that the language of “not extra sensitive” comes from Section 8 of draft-ietf-pce-association-group and this text is merely trying to reiterate this observation.  However, I would recommend not making any assumptions about the particular environments by stating the following:

Also, as stated in [I-D.ietf-pce-association-group], much of the information carried in the Disjointness Association object, as per this document is not extra sensitive.  It often reflects information that can also be derived from the LSP Database, but association provides a much easier grouping of related LSPs and messages.  The disjointness association could provide an adversary with the opportunity to eavesdrop on the relationship between the LSPs.

Also, as stated in [I-D.ietf-pce-association-group], much of the information carried in the Disjointness Association object reflects information that can also be derived from the LSP Database, but association provides a much easier grouping of related LSPs and messages.  The disjointness association could provide an adversary with the opportunity to eavesdrop on the relationship between the LSPs and understand the network topology.

Benjamin Kaduk No Objection

Comment (2019-10-29 for -12)
Thanks for this generally well-written document!  Most of my comments are
pretty minor, but please do note the edge case in objective function
handling, the question about which TLVs are allowed when the ASSOCIATION
object is carried in which messages, the notation clarification question,
and the question about what "completely relax the disjointness constraint"

Please check the TBD<N> placeholders; it looks like (e.g.) TBD8 is used for
both a NO-PATH-VECTOR TLV bit and for an error code (but I didn't
double-check the others).

As a general comment (but mostly for my own curiousity), I'm curious whether
you predict much usage of the DAG association type with none of the L/N/S/T
bits set in the configuration, effectively using the association to carry
the new objective function(s) from this document.

Section 5.1

   A disjoint group can have two or more LSPs, but a PCE may be limited
   in the number of LSPs it can take into account when computing
   disjointness.  If a PCE receives more LSPs in the group than it can
   handle in its computation algorithm, it SHOULD apply disjointness
   computation to only a subset of LSPs in the group.  The subset of
   disjoint LSPs will be decided by PCE as a local policy.  Local

Just to double-check: this "only apply disjointness to a subset, using local
policy" behavior is preferred to returning an error for the last LSP
attempting to join the group?  I do see that the relaxation of disjointness
is reported back via the DISJOINTNESS-STATUS-TLV, so at least there
shouldn't be surprises about what's (not) happening, unless the PCE decides
to not send that TLV for some reason.

   peer receives a PCEP messages for LSPs belonging to the same disjoint
   group but having an inconsistent combination of T, S, N, L flags, the
   PCEP peer MUST NOT try to add the LSPs in disjoint group and MUST
   reply with a PCErr with Error-type 26 (Association Error) and Error-
   Value 6 (Association information mismatch).

nit: s/in disjoint group/to the disjoint group/

   A particular LSP MAY be associated to multiple disjoint groups, but
   in that case, the PCE SHOULD try to consider all the disjoint groups
   during path computation if possible.  Otherwise a local policy MAY
   define the computational behavior.  If a PCE does not support such a
   path computation it MUST NOT add the LSP into association group and
   return a PCErr with Error-type 26 (Association Error) and Error-Value
   7 (Cannot join the association group).

It's interesting that "be in multiple disjoint groups" gets error-on-failure
semantics but (above) "too many LSPs in a single group" gets
degrade-and-report semantics.  But it's clearly documented, so I don't see
any problems per se.

Section 5.2

It looks like we only talk about which messages carry the
DISJOINTNESS-STATUS-TLV; is the implication that the other TLVs are not
restricted in which message can carry them a correct one?  (Also, that
DISJOINTNESS-CONFIGURATION-TLV must be present even in PCRep?)

   The disjoint group MUST carry the following TLV:

Since we're talking about protocol elements now, I'd suggest to explicitly
say "TBD1 Disjoint Association Type group" or something else that clearly
identifies the association-group as a protocol element.

   In addition, the disjoint group MAY carry the following TLV:

nit: "TLVs" plural.

   If a PCEP speaker receives a disjoint-group without DISJOINTNESS-
   CONFIGURATION-TLV, it SHOULD reply with a PCErr Error-type=6
   (Mandatory Object missing) and Error-value=TBD8 (DISJOINTNESS-

I suggest being more explicit about (e.g) "ASSOCIATION object of type TBD1",
since "disjoint-group" is somewhat of a colloquialism.

Seciion 5.3

   An objective function (OF) MAY be applied to the disjointness
   computation to drive the PCE computation behavior.  In this case, the
   OF-List TLV (defined in ([RFC5541]) is used as an optional TLV in the
   Association Group Object.  Whereas the PCEP OF-List TLV allows
   multiple OF-codes inside the TLV, a sender SHOULD include a single
   OF-code in the OF-List TLV when included in the Association Group,
   and the receiver MUST consider the first OF-code only and ignore
   others if included.

This usage seems a little weird (albeit unlikely to be problematic), since
RFC 5441 uses the OF-List TLV to indicate what OFs are supported, and has it
carried in the OPEN object, with a dedicated OF object used to indicate the
particular OF requested/used for a given path computation.  Repurposing the
TLV to now be a container for the requested OF for a specific computation
feels like a qualitatively different usage than the original one.

      *  A path P passes through K links {Lpi,(i=1...K)}.

      *  A set of paths {P1...Pm} have L links that are common to more
         than one path {Lpi,(i=1...L)}.

Can you double-check the notation here?  In the first quoted item it seems
that Lpi indicates the i-th link on path P, but in the second it looks like
Lpi indicates the i-th link in common across paths P1...Pm.  I'd suggest
using a different term for the different meaning.

      *  A path P passes through K links {Lpi,(i=1...K)} belonging to
         unique M SRLGs {Spi,(i=1..M)}.

What is the relationship between K and M?  Is it always true that M <= K?

      *  A set of paths {P1...Pm} have L SRLGs that are common to more
         than one path {Spi,(i=1...L)}.

[same comment about terminology reuse]

      *  A path P passes through K nodes {Npi,(i=1...K)}.

      *  A set of paths {P1...Pm} have L nodes that are common to more
         than one path {Npi,(i=1...L)}.

[same comment about terminology reuse]

   If the OF-list TLV is included in the Association Object, the OF-code
   inside the OF Object MUST include one of the disjoint OFs defined in
   this document.  If this condition is not met, the PCEP speaker MUST
   respond with a PCErr message with Error-Type=10 (Reception of an
   invalid object) and Error-Value=TBD9 (Incompatible OF code).

Looking at edge cases, I think that the MUST-level requirements allow for me
to send an OF-list TLV with two items the first of which is nonsense (i.e.,
not one of these three), and the second of which is one of these three.  The
recipient would be obligated to use the first one in the list (by the
previous text "the receiver MUST consider the first OF-code only") despite
it being nonsensical.  We should probably try to close that edge case,
though there are several approaches to choose from and I don't have a sense
for what might cause us to prefer one over the other.

Section 5.4

   SVEC object.  The PCE MUST consider both the objects as per the
   processing rules and aim to find a path that meets both of these
   constraints.  In case no such path is possible, the PCE MUST send a
   path computation reply (PCRep) with a NO-PATH object indicating path
   computation failure as per [RFC5440].  It should be noted that the

I would consider reminding the reader that the 'T' bit controls how strictly
the PCE needs to interpret the DAG constraints, and thus that it's possible
for the PCE to degrade the request without needint to return NO-PATH in such

Section 5.5

   into account the disjointness constraint.  Setting P flag changes the
   relationship between LSPs to a one-sided relationship (LSP 1 with P=0
   depends of LSP 2 with P=1, but LSP 2 with P=1 does not depend of LSP
   1 with P=0).  Multiple LSPs in the same disjoint group may have the P

nits: "Setting the P flag", "depends on LSP 2"

I suggest specifying "link disjoint" for at least the example using Figure 4
(if not the one using Figure 3 as well), since the paths
PE1->R1->R4->R2->PE2 and PE3->R3->R4->PE4 are not node-disjoint.

Section 5.6

   There are some cases where the PCE may need to completely relax the
   disjointness constraint in order to provide a path to all the LSPs
   that are part of the association.  A mechanism that allows the PCE to
   fully relax a constraint is considered by the authors as more global
   to PCEP rather than linked to the disjointness use case.  As a
   consequence, it is considered as out of scope of the document.

I'm not sure how to interpret this.  Is it supposed to prevent a PCE from
falling back to "no disjointness" (e.g., all of L/N/S/T are clear in
DISJOINTNESS-STATUS-TLV)?  If so, I would have expected this limitation to
be spelled out more clearly much earlier in the document.

Section 6

I suggest also mentioning the security considerations of RFC 7470, as we
have very little control over what information goes in
VENDOR-INFORMATION-TLV.  (Not that there's a whole lot of content there, but
maybe it will get people thinking.)

I might also consider mentioning again that certain combinations of flags
(notably, the 'T' bit) can result in unsatisfiable requests.  But that's
only somewhat a "security" consideration; security aspects only really come
into play for it if someone is spoofing that T bit, and we already recommend

Section 8.1

   Range MUST be allowed to be set by the operator.  Operator SHOULD be
   allowed to set the local policies to define various disjoint

nit: The operator"

Section 8.2

   associations configured or created dynamically.  Further
   implementation SHOULD allow to view disjoint associations reported by
   each peer, and the current set of LSPs in this association.  The PCEP

nit: "Furthermore, implementations"

Section 8.4

   Mechanisms defined in this document do not imply any new operation
   verification requirements in addition to those already listed in

We don't think that someone should check that the computed LSPs actually
supply the disjointness properties they're claimed to provide?

Section 10.2

I guess a strict reading of
would require RFC 7470 to be a normative reference, but that doesn't really
seem like the right thing to do for this specific case.

On the other hand, a RECOMMENDation for RFC 8253's use does feel like it
would place it as a normative reference.

(Suresh Krishnan) (was Discuss) No Objection

Comment (2020-01-15 for -13)
Thanks for addressing my DISCUSS and COMMENT points.

Warren Kumari No Objection

Comment (2019-10-30 for -12)
No email
send info
Supporting Alissa's DISCUSS.

(Mirja Kühlewind) No Objection

Barry Leiba No Objection

Comment (2019-10-29 for -12)
No email
send info
Ben has this well in hand, and I’ve nothing to add.

Alvaro Retana No Objection

Comment (2019-10-28 for -12)
(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/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

(Adam Roach) No Objection

Éric Vyncke No Objection

Comment (2019-10-30 for -12)
Thank you for the work put into this document. The document is easy to read. I just have a minor comment (feel free to ignore it) about section 1: an early definition of 'disjoint group' would be welcome (at least for readers, like myself, who are not familiar with PCE). Even if section 3 provides more information.



Magnus Westerlund No Objection