Benjamin Kaduk 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: ---------------------------------------------------------------------- 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" means. 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. of T, S, N, L flags in the DISJOINTNESS-CONFIGURATION-TLV. If a PCEP 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- CONFIGURATION-TLV missing). 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. MSL [...] * 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. MSS [...] * 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] MSN [...] * 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 cases. 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 TLS. 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 [RFC5440]. 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 https://www.ietf.org/blog/iesg-statement-normative-and-informative-references/ 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. _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
