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

[Benjamin Kaduk <[e-mail]>]

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 <
> [e-mail]> 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