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

Benjamin Kaduk <kaduk@mit.edu> Tue, 24 December 2019 05:37 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A39E612004D; Mon, 23 Dec 2019 21:37:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6KreIZRxtbr; Mon, 23 Dec 2019 21:37:28 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 050CB120048; Mon, 23 Dec 2019 21:37:27 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xBO5bMqQ029215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 24 Dec 2019 00:37:24 -0500
Date: Mon, 23 Dec 2019 21:37:22 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: Mahend Negi <mahend.ietf@gmail.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-pce-association-diversity@ietf.org, Julien Meuric <julien.meuric@orange.com>, pce-chairs <pce-chairs@ietf.org>, pce@ietf.org
Message-ID: <20191224053722.GN35479@kduck.mit.edu>
References: <157239405775.10912.18424489553959713397.idtracker@ietfa.amsl.com> <CAM5Nu_w4K0=vSB8CZX639SWhs+Dgq320DhETdeB4MgMbNeJLFA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAM5Nu_w4K0=vSB8CZX639SWhs+Dgq320DhETdeB4MgMbNeJLFA@mail.gmail.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/YFfEWc0neW_5ZS2cEpFvPbDYY3s>
Subject: Re: [Pce] Benjamin Kaduk's No Objection on draft-ietf-pce-association-diversity-12: (with COMMENT)
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Dec 2019 05:37:31 -0000

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 <
> noreply@ietf.org> 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