Re: [RTG-DIR] Routing directorate review of draft-ietf-teas-scheduled-resources-04
Jonathan Hardwick <Jonathan.Hardwick@metaswitch.com> Tue, 16 January 2018 09:47 UTC
Return-Path: <Jonathan.Hardwick@metaswitch.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75DC012FB42; Tue, 16 Jan 2018 01:47:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=metaswitch.com
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 PxHqTJqfTSz0; Tue, 16 Jan 2018 01:47:32 -0800 (PST)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0111.outbound.protection.outlook.com [104.47.42.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A1B712FB4C; Tue, 16 Jan 2018 01:47:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metaswitch.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=vn1UdNlcyXUx3XsNqPzf1XkZv4GK2eNfSwlf6Qb9CC8=; b=hPgKcNGKzNhTNavtrpYW30EA/+miWV3AJ+YHRYaaUV7PJAVH6I+7s1nJ/57Nski5NiS0PHHlEN2JiFvEYIFOWSbpEhBsLbW6vh//wBABKD4HuTE7nEI/1ZQRSPncwiPr8RFdic5ML8m/vJmwxdTeCfDkFUHIbWxfzzc0qO8uPOY=
Received: from CY4PR0201MB3603.namprd02.prod.outlook.com (52.132.99.21) by CY4PR0201MB3588.namprd02.prod.outlook.com (52.132.98.38) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.407.7; Tue, 16 Jan 2018 09:47:11 +0000
Received: from CY4PR0201MB3603.namprd02.prod.outlook.com ([fe80::90b3:9263:cb68:13be]) by CY4PR0201MB3603.namprd02.prod.outlook.com ([fe80::90b3:9263:cb68:13be%13]) with mapi id 15.20.0407.009; Tue, 16 Jan 2018 09:47:11 +0000
From: Jonathan Hardwick <Jonathan.Hardwick@metaswitch.com>
To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "rtg-ads@ietf.org" <rtg-ads@ietf.org>, "db3546@att.com" <db3546@att.com>
CC: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "draft-ietf-teas-scheduled-resources@ietf.org" <draft-ietf-teas-scheduled-resources@ietf.org>, 'TEAS WG' <teas@ietf.org>
Thread-Topic: [RTG-DIR] Routing directorate review of draft-ietf-teas-scheduled-resources-04
Thread-Index: AdOOCd1EkHs4QaYARc2anFzQnn31VAASkSQAABaw/mA=
Date: Tue, 16 Jan 2018 09:47:11 +0000
Message-ID: <CY4PR0201MB36032C5351750CDC43E1616384EA0@CY4PR0201MB3603.namprd02.prod.outlook.com>
References: <CY4PR0201MB36037AB4AE283DB918352DF284EB0@CY4PR0201MB3603.namprd02.prod.outlook.com> <029401d38e54$2374a380$6a5dea80$@olddog.co.uk>
In-Reply-To: <029401d38e54$2374a380$6a5dea80$@olddog.co.uk>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jonathan.Hardwick@metaswitch.com;
x-originating-ip: [86.132.72.20]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR0201MB3588; 7:QnVi9J15ACazyDLupfB/tkbY1FACVw5xWVPHAjCeTsKoC1SXcA730Iyh9OI0vHDn2uwWE0qPgNNDdZxLjwkiGjBWFmLoS/EMUzAx2xztmJeXMbhFxEJ1lLG3r1NcjnfTIs8OfIsQpVuvzU4gx/mOUDE0Z/a1UrPFjfDibsr9dyUQn4jLATm/UnmyJux9oskU7SGfs6VXRXhL6PjzUN5ODrl8i2w38+2HFxESK6V4WiugOMQSBudnXamRYZCrAtql
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 7fb5fca3-b084-43ea-7b2e-08d55cc61def
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:CY4PR0201MB3588;
x-ms-traffictypediagnostic: CY4PR0201MB3588:
x-microsoft-antispam-prvs: <CY4PR0201MB35884043E28EA3B1875FF2E784EA0@CY4PR0201MB3588.namprd02.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(278428928389397)(97927398514766);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3231023)(944501161)(3002001)(6041268)(20161123564045)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011); SRVR:CY4PR0201MB3588; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:CY4PR0201MB3588;
x-forefront-prvs: 0554B1F54F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39850400004)(39380400002)(376002)(366004)(346002)(13464003)(37854004)(199004)(189003)(3280700002)(25786009)(3660700001)(305945005)(66066001)(97736004)(7736002)(81166006)(2900100001)(74316002)(5660300001)(8676002)(81156014)(8936002)(14454004)(68736007)(230783001)(2950100002)(33656002)(4326008)(105586002)(106356001)(72206003)(6246003)(478600001)(53546011)(6436002)(59450400001)(9686003)(2201001)(3846002)(55016002)(6116002)(2906002)(76176011)(229853002)(54906003)(102836004)(5250100002)(2501003)(316002)(6506007)(53936002)(110136005)(86362001)(7696005)(99286004)(26005); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR0201MB3588; H:CY4PR0201MB3603.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: metaswitch.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: 4p4aHMx0aOTCUlGjHwgb3f9AV6dOFmearpr3CRJoNjj97JHCJZua4MMSG/AMIqOzn46bSIj21ungKosKB1k4Aw==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: metaswitch.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7fb5fca3-b084-43ea-7b2e-08d55cc61def
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jan 2018 09:47:11.6275 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR0201MB3588
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/WA0w5Pb0TQiNl-7Wkq7HY1oLiMU>
Subject: Re: [RTG-DIR] Routing directorate review of draft-ietf-teas-scheduled-resources-04
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Jan 2018 09:47:34 -0000
Hi Adrian This all looks good to me! Thanks for taking my feedback into account. Best regards Jon -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: 15 January 2018 22:57 To: Jonathan Hardwick <Jonathan.Hardwick@metaswitch.com>; rtg-ads@ietf.org; db3546@att.com Cc: rtg-dir@ietf.org; draft-ietf-teas-scheduled-resources@ietf.org; 'TEAS WG' <teas@ietf.org> Subject: RE: [RTG-DIR] Routing directorate review of draft-ietf-teas-scheduled-resources-04 Hello again, Jon. Reiterating my thanks for your review. In line... > Section 2.5 > > I found the following sentence to be misplaced, because it is the > first sentence in this section that talks about LSP reservation > requests, and it appears in the middle of a paragraph that is discussing scheduling state. > > | Multiple periods, possibly > | of different lengths, may be associated with one reservation request, > | and a reservation might repeat on a regular cycle. > > LSP reservation requests are then not mentioned again until the final > paragraph, where it says that you must keep them in a database, too. OK. That took me a bit to work out, but this might do the job... OLD There are multiple ways to realize this information model and different ways to store the data. The resource state could be expressed as a start time and an end time as shown above, or could be expressed as a start time and a duration. Multiple periods, possibly of different lengths, may be associated with one reservation request, and a reservation might repeat on a regular cycle. Furthermore, the current state of network reservation could be kept separate from the scheduled usage, or everything could be merged into a single TS database. This scheduling state information can be used by applications to book resources for future or now, so as to maximize chance of services being delivered. Also, it can avoid contention for resources of LSPs. Note that it is also necessary to store the information about future LSPs. This information is held to allow the LSPs to be instantiated when they are due and using the paths/resources that have been computed for them, but also to provide correlation with the TS-TE resource reservations so that it is clear why resources were reserved allowing pre-emption and handling release of reserved resources in the event of cancellation of future LSPs. NEW There are multiple ways to realize this information model and different ways to store the data. The resource state could be expressed as a start time and an end time as shown above, or could be expressed as a start time and a duration. Multiple reservation periods, possibly of different lengths, may be need to be recorded for each resource. Furthermore, the current state of network reservation could be kept separate from the scheduled usage, or everything could be merged into a single TS database. An application may make a reservation request for immediate resource usage, or to book resources for future use so as to maximize the chance of services being delivered and to avoid contention for resources in the future. A single reservation request may book resources for multiple periods and might request a reservation that repeats on a regular cycle. A computation engine (that is, a PCE) may use the scheduling state information to help optimise the use of resources into the future and reduce contention or blocking when the resources are actually needed. Note that it is also necessary to store the information about future LSPs as distinct from the specific resource scheduling. This information is held to allow the LSPs to be instantiated when they are due and using the paths/resources that have been computed for them, but also to provide correlation with the TS-TE resource reservations so that it is clear why resources were reserved allowing pre-emption and handling release of reserved resources in the event of cancellation of future LSPs. END > Please explain and differentiate more clearly between the database of >scheduled resources and the database of LSP reservation requests. You >should say what information is contained in each, and how the >information in the latter relates to the information in the former. I >suggest you delete the above quoted sentence and then expand the final >paragraph to give more details on the LSP reservation request database. > > Actually, now I have read further, section 3.2 already does this very > well, so I think it would be best to combine 2.5 with it. Mutters into beard ;-) There is a fine line. The databases are *a* realisation of how the data may be stored. We don't want to push too far into how an implementation actually stores the information that has to be held. With the rewrite above, I propose also adding a forward pointer to 3.2. ADD See Section 3.2 for further discussion of the distinction between scheduled resource state and scheduled LSP state. END > Section 3.1 > > In the discussion of the issues of centralizing the scheduling state > database, the third bullet appears not to be an issue, but a > mitigation of bullet 2. I think it should be merged into bullet 2. Hmmm. It was intended to set up an issue (starting in a similar way to bullet 2), but somehow the issue never got written, and that is probably because there isn't an issue. I propose to strike bullet 3. > In the final bullet, you say that the central server must have full > control of reservations, but I think you should take the extra step > and justify this statement. If a node sets up its own RSVP-TE LSP > without contacting the server, then it may invalidate some plans that the server has already made. > The server will eventually find out about the new reservation, but (a) > it might take too long to find out and (b) the server will have no > idea how long the reservation is going to persist for. I think you > are saying that, for reasons > (a) and (b), all reservations must be scheduled by the server without exception. > Correct? Well, not quite. The problems you identify as (a) and (b) are real, but could be reconciled provided the central server can collect the information from the network. So, when the text says... but the problem of collecting the information from the network is only solved if the central server has full control of the booking of resources and the establishment of new LSPs. The intention was to highlight the challenge of collecting the information. But the text didn't do that :-( So... OLD o Of course, a centralized system must store information about all of the resources in the network. In a busy network with a high arrival rate of new LSPs and a low hold time for each LSP, this could be a lot of state. This is multiplied by the size of the network measured both by the number of links and nodes, and by the number of trackable resources on each link or at each node. The challenge may be mitigated by the centralized server being dedicated hardware, but the problem of collecting the information from the network is only solved if the central server has full control of the booking of resources and the establishment of new LSPs. NEW o Of course, a centralized system must store information about all of the resources in the network. In a busy network with a high arrival rate of new LSPs and a low hold time for each LSP, this could be a lot of state. This is multiplied by the size of the network measured both by the number of links and nodes, and by the number of trackable resources on each link or at each node. This challenge may be mitigated by the centralized server being dedicated hardware, but there remains the problem of collecting the information from the network in a timely way when there is potentially a very large amount of information to be collected and when the rate of change of that information is high. This latter challenge is only solved if the central server has full control of the booking of resources and the establishment of new LSPs so that the information from the network only serves to confirm what the central server expected. END > Section 3.2 > > This treads much of the same ground as section 2.5 and does it much > better. I suggest merging the two, or making 2.5 very brief and > giving a forward reference to 3.2. See above. > Section 4.1 > > I think it would be useful to note in paragraph 2 that the update to > the TEDB may trigger a re-optimization of the TEDB, potentially > changing a previously computed reservation for existing LSP requests, either by pre-empting them or by moving their planned paths. > And this might involve some sort of update sent back over interface (a). > > Similarly, in the final paragraph, if an LSP request is cancelled then > it may trigger a re-optimization of the TEDB such that previously > requested LSPs are re-planned or become viable. Yes (modulo s/re-optimization of the TEDB/re-optimization of the LSPs/) But I don't want to interrupt the flow of 4.1. How about... ADD 4.1.1. Reoptimization After TED Updates When the TED is updated as indicated in Section 4.1, the PCE may perform reoptimization of the LSPs for which it has computed paths. These LSPs may be already provisioned in which case the PCE issues PCEP Update request messages for the LSPs that should be adjusted. Additionally, the LSPs being reoptimized may be scheduled LSPs that have not yet been provisioned, in which case reoptimization involves updating the store of scheduled LSPs and resources. In all cases, the purpose of reoptimization is to take account of the resource usage and availability in the network and to compute paths for the current and future LSPs that best satisfy the objectives of those LSPs while keeping the network as clear as possible to support further LSPs. END > References > Please update: > draft-ietf-pce-pceps -> RFC 8253 > draft-ietf-pce-stateful-pce -> RFC 8231 Tempus fugit! Yes. Cheers, Adrian
- [RTG-DIR] Routing directorate review of draft-iet… Jonathan Hardwick
- Re: [RTG-DIR] Routing directorate review of draft… Adrian Farrel
- Re: [RTG-DIR] Routing directorate review of draft… Adrian Farrel
- Re: [RTG-DIR] Routing directorate review of draft… Jonathan Hardwick