Hi Mahend, Most of this looks good; I'll trim most things. As a side note, the quoting in your message seems to have gotten mixed up somehow, though I think that I figured out the important parts.
On Wed, Dec 18, 2019 at 09:46:02PM +0530, Mahend Negi wrote: > Hi Ben, > > Thanks for the detailed review, please find the details inline to your mail. > B/w new version is uploaded. > > htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-pce-association-diversity-13 > https://datatracker.ietf.org/doc/html/draft-ietf-pce-association-diversity-13 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-association-diversity-13 > > Thanks, > Mahendra > > On Wed, Oct 30, 2019 at 5:37 AM Benjamin Kaduk via Datatracker < > [email protected]> wrote: > [...] > 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. > > > How about - "The PCE MUST consider both the objects (including the > flags set inside the objects) as per the processing rules and aim to > find a path that meets both of these constraints." It is up to you what is best, though I had in mind a phrase including the specific words "the 'T' bit", since it seemed particularly noteworthy to me. But what is noteworthy to me is not necessarily noteworthy to anyone else, so I do not insist on anything. > 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. > > > There is a proposal to make an objects as optional to process in > stateful messages via > https://datatracker.ietf.org/doc/draft-dhody-pce-stateful-pce-optional/, > this already exist for stateless messages via RFC 5440. The above text > is simply to say that relaxation to "no disjointness" can be handled > via a common technique and out of scope of this I-D. So if I understand correctly, the relaxation would be done at the object level and would not involve specifically giving meaning to L/N/S/T of all-zeros? That makes things much more clear, and I agree that there's no need to say more in this document other than perhaps a reference to draft-dhody-pce-stateful-pce-optional. Thanks, Ben _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
