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

Benjamin Kaduk <> Tue, 24 December 2019 05:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A39E612004D; Mon, 23 Dec 2019 21:37:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.199
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id R6KreIZRxtbr; Mon, 23 Dec 2019 21:37:28 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 050CB120048; Mon, 23 Dec 2019 21:37:27 -0800 (PST)
Received: from ([]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (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 <>
To: Mahend Negi <>
Cc: The IESG <>,, Julien Meuric <>, pce-chairs <>,
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <>
Subject: Re: [Pce] Benjamin Kaduk's No Objection on draft-ietf-pce-association-diversity-12: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Path Computation Element <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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:
> A diff from the previous version is available at:
> Thanks,
> Mahendra
> On Wed, Oct 30, 2019 at 5:37 AM Benjamin Kaduk via Datatracker <
>> 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
> 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