IETF Logo Mail Archive

Re: [Teas] Mirja Kühlewind's No Objection on draft-ietf-teas-scheduled-resources-06: (with COMMENT)

"Adrian Farrel" <adrian@olddog.co.uk> Wed, 04 April 2018 18:23 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64FBF126C83; Wed, 4 Apr 2018 11:23:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 Bi-g28XydyvW; Wed, 4 Apr 2018 11:23:53 -0700 (PDT)
Received: from mta7.iomartmail.com (mta7.iomartmail.com [62.128.193.157]) (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 54A881200C1; Wed, 4 Apr 2018 11:23:50 -0700 (PDT)
Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta7.iomartmail.com (8.14.4/8.14.4) with ESMTP id w34INlto013426; Wed, 4 Apr 2018 19:23:48 +0100
Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B82EA22042; Wed, 4 Apr 2018 19:23:47 +0100 (BST)
Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs2.iomartmail.com (Postfix) with ESMTPS id A2B8522048; Wed, 4 Apr 2018 19:23:47 +0100 (BST)
Received: from 950129200 ([193.57.121.62]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id w34INke2012155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Apr 2018 19:23:47 +0100
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>
Cc: draft-ietf-teas-scheduled-resources@ietf.org, teas-chairs@ietf.org, teas@ietf.org
References: <152286371372.23998.15269289326998986785.idtracker@ietfa.amsl.com> <f76c91e50edc401dbc9e80008190de37@BLUPR05MB370.namprd05.prod.outlook.com>
In-Reply-To: <f76c91e50edc401dbc9e80008190de37@BLUPR05MB370.namprd05.prod.outlook.com>
Date: Wed, 04 Apr 2018 19:23:47 +0100
Message-ID: <032601d3cc42$139cb020$3ad61060$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Content-Language: en-gb
Thread-Index: AQEH1ZgaCG7WsaBkhB37UuMDCs5ldwKJCboQpXSPsSA=
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-23764.002
X-TM-AS-Result: No--9.240-10.0-31-10
X-imss-scan-details: No--9.240-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-23764.002
X-TMASE-Result: 10--9.239700-10.000000
X-TMASE-MatchedRID: VPleTT1nwdQ4HKI/yaqRm0NTnAhL0/m3zJmqByfAaS39Ez/5IpHqpxx1 EVPU/Uz3h05m0h4QlRxn7DLoxqKq/DQJhQ6khMBivHKClHGjjr1u/Xr6CKXiN/iynjEO4PxsDk3 wAhF7KJRkJQBS7omyWkqWBBwop/gkK4UqIMWv5c5c/msUC5wFQZl/lu28zzkBIHMhnr7X7SejxY yRBa/qJX3mXSdV7KK4RH9AeNSq0IbQLWxBF9DMQcRB0bsfrpPIx1FPlNAAmcA7elebIXZn3M/a7 V1toJhzwqDMCMOJKvd7xGzLranuqJ6oP1a0mRIj
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/zFJ7O2AoEBNKZBSz4cgqOhNv-4s>
Subject: Re: [Teas] Mirja Kühlewind's No Objection on draft-ietf-teas-scheduled-resources-06: (with COMMENT)
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Apr 2018 18:23:55 -0000

Hi Mirja,

> One question: I think I don't understand how the proposed framework would
> interact with non-Time-Scheduled reservations or reservations that support TS
> but don't know their end-time. If you have such reservations, you basically
> already need to block the resources of all future scheduled reservations
> because you don't know how long the requested unbounded reservation is
> needed, which could also lead to an non-optimal resource  scheduling. Could
> you please clarify this in the document or further elaborate/acknowledge 
> this problem in the doc?

You nailed it, and this "non-optimal" use of resources is exactly why resource
scheduling is proposed in the first place.

We can certainly add text on the operation of a system where some LSPs are
scheduled while other are not.

Cheers,
Adrian

v2.23.0 | Report a Bug | By Email