Re: [Pce] Benjamin Kaduk's Discuss on draft-ietf-pce-gmpls-pcep-extensions-14: (with DISCUSS and COMMENT)
Benjamin Kaduk <kaduk@mit.edu> Tue, 02 July 2019 16:52 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 9BF8612063B; Tue, 2 Jul 2019 09:52:09 -0700 (PDT)
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 q7td_6_GyLbp; Tue, 2 Jul 2019 09:52:07 -0700 (PDT)
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 094A112060A; Tue, 2 Jul 2019 09:51:57 -0700 (PDT)
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 x62GpqT6007176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 2 Jul 2019 12:51:55 -0400
Date: Tue, 02 Jul 2019 11:51:52 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: julien.meuric@orange.com
Cc: Adrian Farrel <adrian@olddog.co.uk>, 'The IESG' <iesg@ietf.org>, draft-ietf-pce-gmpls-pcep-extensions@ietf.org, pce-chairs@ietf.org, pce@ietf.org
Message-ID: <20190702165151.GV13810@kduck.mit.edu>
References: <155498315544.12722.1073746104492266680.idtracker@ietfa.amsl.com> <046301d4f061$646ee470$2d4cad50$@olddog.co.uk> <20190411184842.GN18549@kduck.mit.edu> <13331_1561728394_5D16158A_13331_219_1_5b5e922c-95a9-7a13-4c15-507ede8927e4@orange.com> <20190629005125.GG10013@kduck.mit.edu> <13959_1561974305_5D19D621_13959_289_1_c3d7e7d8-ebcd-eb2f-d0cb-1028fed19d20@orange.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <13959_1561974305_5D19D621_13959_289_1_c3d7e7d8-ebcd-eb2f-d0cb-1028fed19d20@orange.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/UCLVQQUjFplaithK398gySJMbuI>
Subject: Re: [Pce] Benjamin Kaduk's Discuss on draft-ietf-pce-gmpls-pcep-extensions-14: (with DISCUSS and 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, 02 Jul 2019 16:52:10 -0000
On Mon, Jul 01, 2019 at 11:45:04AM +0200, julien.meuric@orange.com wrote: > Hi Ben, > > Thank you for following up. Please see [JM] below. > > > On 29/06/2019 02:51, Benjamin Kaduk wrote: > > Hi Julien, > > > > On Fri, Jun 28, 2019 at 03:26:33PM +0200, julien.meuric@orange.com wrote: > >> Hi Ben, > >> > >> Apologies for the late response. > > I probably wouldn't have been able to reply much before now anyway -- I've > > been quite busy (and have some other documents' authors waiting for > > feedback as well). > > > >> Let us focus on your first DISCUSS comment which is the main one. You > >> raised a legitimate point that we acknowledge. After discussion, we > >> propose to modify the end of section 2.4 as follows: > >> > >> OLD > >> > >> The semantic of the LOAD-BALANCING object is not changed. If a PCC > >> requests the computation of a set of TE-LSPs so that the total of > >> their generalized bandwidth is X, the maximum number of TE-LSPs is N, > >> and each TE-LSP must at least have a bandwidth of B, it inserts a > >> BANDWIDTH object specifying X as the required bandwidth and a LOAD- > >> BALANCING object with the Max-LSP and Min Bandwidth Spec fields set > >> to N and B, respectively. > >> > >> NEW > >> > >> The semantic of the LOAD-BALANCING object is not changed. When the > >> bandwidth can be expressed as scalars (e.g., for circuit-switched > >> technologies), if a PCC requests the computation of a set of TE-LSPs > >> so that the total of their generalized bandwidth is X, the maximum > >> number of TE-LSPs is N, and each TE-LSP must at least have a > >> bandwidth of B, it inserts a BANDWIDTH object specifying X as the > >> required bandwidth and a LOAD-BALANCING object with the Max-LSP and > >> Min Bandwidth Spec fields set to N and B, respectively. > >> > >> For technologies based on statistical multiplexing (e.g., InterServ, > >> Ethernet), the exact bandwidth management (e.g., Ethernet's Excessive > >> Rate) is left to the PCE's policies, according to the operator's > >> configuration. If required, further documents may introduce a new > >> mechanism to finely express complex load balancing policies within > >> PCEP. > >> > >> > >> Would that update address that part of your DISCUSS? (The remaining > >> parts will be straightforward once this one is resolved.) > > I seem to have forgotten some of the details of what fields are in the > > various objects, but let's see what I can say regardless of that. > > I think the general approach of specifying behavior when there's an obvious > > scalar bandwidth and leaving the choice to the PCE in other cases is a good > > approach. > > > > For the specifics, we probably don't want to say "when the bandwidth can be > > expressed as a scalar" and "for technologies based on statistical > > multiplexing" just in case there ends up being some third category, so the > > second paragraph could start off as something like "In all other cases, > > including for technologies based on statistical multiplexing [...]". > [JM] You're right. That's a safer wording, easy to include. > > > It also seems like for the first case, we would be able to use the > > un-modified RFC 5440 BANDWIDTH and not need the generalized form? But > > perhaps I misremember/misunderstand... > [JM] This is indeed what the current wording suggests, so I propose to > change "expressed by scalars" with "summarized into scalars". The idea > here is to accommodate existing constructs from RSVP-TE signaling, which > are compound objects allowing to specify more detailed information than > aggregated values. E.g., a single 10 Gb/s circuit vs. a group of 4 x 2.5 > Gb/s containers. > That would lead us to the following text: > > The semantic of the LOAD-BALANCING object is not changed. When the > bandwidth can be summarized into scalars (e.g., for circuit-switched > technologies), if a PCC requests the computation of a set of TE-LSPs > so that the total of their generalized bandwidth is X, the maximum > number of TE-LSPs is N, and each TE-LSP must at least have a > bandwidth of B, it inserts a BANDWIDTH object specifying X as the > required bandwidth and a LOAD-BALANCING object with the Max-LSP and > Min Bandwidth Spec fields set to N and B, respectively. > > In all other cases, including for technologies based on statistical > multiplexing (e.g., InterServ, Ethernet), the exact bandwidth > management (e.g., Ethernet's Excessive Rate) is left to the PCE's > policies, according to the operator's configuration. If required, > further documents may introduce a new mechanism to finely express > complex load balancing policies within PCEP. > > Is it better? That is better; thank you. The only other comment I have would be to ask if it's worth saying something in the first paragraph about how "other link-technology-specific parameters are not included in the bandwidth calculation" (with my apologies for probably using the wrong terminology; this is not my area of expertise). -Ben
- [Pce] Benjamin Kaduk's Discuss on draft-ietf-pce-… Benjamin Kaduk via Datatracker
- Re: [Pce] Benjamin Kaduk's Discuss on draft-ietf-… Adrian Farrel
- Re: [Pce] Benjamin Kaduk's Discuss on draft-ietf-… Benjamin Kaduk
- Re: [Pce] Benjamin Kaduk's Discuss on draft-ietf-… julien.meuric
- Re: [Pce] Benjamin Kaduk's Discuss on draft-ietf-… Benjamin Kaduk
- Re: [Pce] Benjamin Kaduk's Discuss on draft-ietf-… julien.meuric
- Re: [Pce] Benjamin Kaduk's Discuss on draft-ietf-… Benjamin Kaduk
- Re: [Pce] Benjamin Kaduk's Discuss on draft-ietf-… julien.meuric
- Re: [Pce] Benjamin Kaduk's Discuss on draft-ietf-… Benjamin Kaduk
- Re: [Pce] Benjamin Kaduk's Discuss on draft-ietf-… Cyril Margaria