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
- [Pce] Benjamin Kaduk's No Objection on draft-ietf… Benjamin Kaduk via Datatracker
- Re: [Pce] Benjamin Kaduk's No Objection on draft-… Mahend Negi
- Re: [Pce] Benjamin Kaduk's No Objection on draft-… Benjamin Kaduk