Re: [Teas] draft-zhuang-teas-scheduled-resources

"Adrian Farrel" <adrian@olddog.co.uk> Tue, 19 July 2016 16:12 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 9F9D712D7D6 for <teas@ietfa.amsl.com>; Tue, 19 Jul 2016 09:12:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Level:
X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 r1rg2QYJbWrc for <teas@ietfa.amsl.com>; Tue, 19 Jul 2016 09:12:20 -0700 (PDT)
Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CE9912D599 for <teas@ietf.org>; Tue, 19 Jul 2016 09:07:01 -0700 (PDT)
Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id u6JG6hug004825; Tue, 19 Jul 2016 17:06:43 +0100
Received: from 950129200 (jplon-nat14.juniper.net [193.110.55.14]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id u6JG6fX5004810 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 19 Jul 2016 17:06:42 +0100
From: Adrian Farrel <adrian@olddog.co.uk>
To: "'Zhuangyan (Yan)'" <zhuangyan.zhuang@huawei.com>, 'Daniele Ceccarelli' <daniele.ceccarelli@ericsson.com>, draft-zhuang-teas-scheduled-resources@tools.ietf.org
References: <AM2PR07MB09949D9B0FF462A582AA3AB2F0360@AM2PR07MB0994.eurprd07.prod.outlook.com> <9B4BC45FDEDDD84F813E9E4A5BAF87859422AA6E@nkgeml513-mbx.china.huawei.com>
In-Reply-To: <9B4BC45FDEDDD84F813E9E4A5BAF87859422AA6E@nkgeml513-mbx.china.huawei.com>
Date: Tue, 19 Jul 2016 17:06:44 +0100
Message-ID: <00a501d1e1d7$8bfdcf60$a3f96e20$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A6_01D1E1DF.EDC7DCB0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGVZEd6TwZTYTYlD7c4/u6zvL+3ggEjBUmmoI/CGEA=
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22462.000
X-TM-AS-Result: No--14.582-10.0-31-10
X-imss-scan-details: No--14.582-10.0-31-10
X-TMASE-MatchedRID: mGV7xPP3pcVbJCKOm3VRCYfAYSb4KlgZFyF2sm/fFKdCUd+qZJ6IfOXn 2SeMoYDGyNkakgF4d97iHyvyXeXh5l+PJNkR/r/XY8r/ndGdDsWXAgiYw74zF/lsGNsZMn6oedu IxPm+q2/rjQjLn1VUHJYsKSXWWrsH4+ZcrqvCDkGTMTaQzhvoenAicheHY/jvY0qxD7njIzBW3V cAc19Kwea1JKfA+jfKF6z9HGHKwNuxD5+pk86RnEENV4Lwnu7BDxuhWpfXGhqQYfW/c5IPuONyX lKYpPkkT0fSF3jYZn7AjK1KJglnOvHzb2VwPI7ecawgRHFhmOpau+u2d9DSuG4/eoumkzRYrK3z 9FFd0Cav7ipErSF5OdxajlW+zwxCI9yVcHNDU7baqqH/oHw+kQ0yil/owZRAu7MLnfc0u3vfwAi GiDpmaBnrFEMoRsxoCPKPqEbU3ZMntMB2hZik53Q8D+SLaQjsHEkRfST+Ts4uI29Z9XjQN0R2oo afExxgMaCTQC8f3+Gd27eF5UDFow/i8FY2vTOBIDp4740OYDElncPTMo+HsfXTJA26jU4ll+5ww vuICnpzUF5L8npo310yuDrT1H0Eo7heNWkyUV2f6WkmZi4Ro3uW2rIm8eCn8k6NRrEpcqoZIoMi CNT2eTLj310JtDLwiguiJuCNURfVY9jEIdWup2AfN+t90cS3hzQHk5Qv+7XMffEoeWe1yhLit4d 6V8mTocPszYb3KEzjrayXo0o3MIfsPVs/8Vw6pRezBf/GshLUGg7QVcvSyP/55Kkc+9/6c91xMY NqHkWBkjWfpo1TNt/wYmMFcJSIhZ0tF529HXybKItl61J/yZUdXE/WGn0FfeZdJ1XsorhRIJJOd tCgUnnN0DN7HnFmgOqgFy7Ot3Fxh1eYPblYvWchW3X/6WUXzNSsLvrfiKWGT9bgVhThf4kfuVON hC7xNGgiZFIhXAHf2BTBfC459KB69D0wnZd8ftwZ3X11IV0=
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/jj27zlTwZ7oG_fjdPMQX8t0mhio>
Cc: 'TEAS WG' <teas@ietf.org>
Subject: Re: [Teas] draft-zhuang-teas-scheduled-resources
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: adrian@olddog.co.uk
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: Tue, 19 Jul 2016 16:12:30 -0000

Hi,
 
See [AF].
 
Adrian
 
I did a review of the draft and I believe it is well written and provides a good
overview of the problem statement and the frameworks.
There are some minor issues that can be addressed in further versions, like for
example the sentence below which I don't believe is true:
 
   TE-LSPs in existing networks are provisioned using RSVP-TE as a
   signaling protocol [ <https://tools.ietf.org/html/rfc3209> RFC3209][RFC3473]
or by direct control of network
   elements such as in the Software Defined Networking paradigm.
 
[AF] I am a little worried about what is not true in this sentence. Can you
clarify? Are you suggesting that one of these techniques is not used, or are you
suggesting that there are other ways to set up TE-LSPs?
 
 
But these are not relevant to the main topic of the draft and can be addressed
in the future. 
My other comments are:
 
1.       It is not clear why the LSP-DB time aware is needed for path
computation. The only reason that comes to my mind is the same reason that lead
to the definition of the LSP-DB for stateful PCE, but I don't understand why it
is needed to have a time aware LSP-DB and a time aware TED is not enough.
The time-based TED is not enough in the time-based system. We still have to
trace back to the LSP.
In conventional system, when an LSP is withdrawn, it is torn down and the
network released the resources. While in a time-based system, when an LSP that
has not yet been set up is withdrawn, we don't know what resource to release (in
the time-based TED) because we don't know what path the LSP took.
 
[AF] Perfect answer :-)
You could call this "time-stateful" if you want.
 
2.       Section 3.2 - Why did you decide to have the time indicated as a
discrete number of slots? Wouldn't it be easier to make it a continuum?
For discrete slots in section 3.2, the bandwidth requirements differs in these
slots so the idea is to reserve different bandwidth at respective slots.
 
[AF] Yeah. even when we have a continuum we really describe it in slots (e.g.,
units of seconds). The question to address is the amount of data needed to store
the state, and the level of granularity that is needed. If, for example, you
allowed a granularity of one second then you could have an LSP every odd second,
but not every even second, and that would take quite a lot of storage.
 
3.       Figure in section 4: I don't understand the need to have d) for LSRs
and e) for routers.also LSRs can speak BGP-LS. I would just leave LSRs.
The idea here is also include routers which might not be a LSR here.
 
4.       Section 4.2. - I wouldn't leave the recovery out of scope as
implementation specific. Some options may need dedicated protocol extensions.
Moreover if we want a PCE from vendor A to speak with a network from vendor B we
need to state how the PCE builds the Time based TED.
Yes, a good point to discuss.
 
[AF] I hoped that the text of 4.2 did not put it out of scope. But it does
say...
 
   Next, the PCE must construct a time-based TED to show scheduled
   resource usage.  How it does this is implementation specific: it may
   recover a time-based TED previously saved to non-volatile storage, or
   it may reconstruct the time-based TED from information retrieved from
the LSP-DB previously saved to non-volatile storage. 
 
What we intended is that the *mechanism* for constructing the time-based TED is
implementation specific. That is, how you create this form the information
retrieved from the network and from the time-based LSP-DB is up to the
implementer. 
 
If protocol extensions are needed, then for what? They would be to suck data
from somewhere. But the network nodes don't have this information.