Re: [Pce] Benjamin Kaduk's Discuss on draft-ietf-pce-gmpls-pcep-extensions-14: (with DISCUSS and COMMENT)
Benjamin Kaduk <kaduk@mit.edu> Wed, 03 July 2019 23:12 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 A6CAF1206BD; Wed, 3 Jul 2019 16:12:57 -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 DKNCIe2ixwbM; Wed, 3 Jul 2019 16:12:55 -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 153C412048C; Wed, 3 Jul 2019 16:12:54 -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 x63NCnFj009065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 3 Jul 2019 19:12:52 -0400
Date: Wed, 03 Jul 2019 18:12:49 -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: <20190703231248.GF13047@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> <20190702165151.GV13810@kduck.mit.edu> <27458_1562149758_5D1C837E_27458_446_1_c6c3f7ed-dd9d-0f6b-3233-e4ceb9fad085@orange.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <27458_1562149758_5D1C837E_27458_446_1_c6c3f7ed-dd9d-0f6b-3233-e4ceb9fad085@orange.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/8G6KH6oSad_VPNdzB--b6Upzxdo>
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: Wed, 03 Jul 2019 23:12:59 -0000
Hi Julien, That's quite helpful; thanks again! -Ben On Wed, Jul 03, 2019 at 12:29:17PM +0200, julien.meuric@orange.com wrote: > Hi Ben, > > Would this address your previous comment? (Please see the text in brackets.) > > The semantic of the LOAD-BALANCING object is not changed. When the > bandwidth can be summarized into scalars (e.g., for circuit-switched > technologies, Traffic Parameters express detailed container > requirements implicitly mapping to a well-defined bandwidth), 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. > > Thanks, > > Julien > > > On 02/07/2019 18:51, Benjamin Kaduk wrote: > > 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 > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. >
- [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