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

"Adrian Farrel" <> Fri, 22 July 2016 09:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BA39012DF3B for <>; Fri, 22 Jul 2016 02:43:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.619
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YRpB11gHEzAn for <>; Fri, 22 Jul 2016 02:43:06 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 927E712DF41 for <>; Fri, 22 Jul 2016 02:43:05 -0700 (PDT)
Received: from (localhost.localdomain []) by (8.13.8/8.13.8) with ESMTP id u6M9gSxo031994; Fri, 22 Jul 2016 10:42:28 +0100
Received: from 950129200 ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id u6M9gR9v031962 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 22 Jul 2016 10:42:27 +0100
From: Adrian Farrel <>
To: 'Daniele Ceccarelli' <>, "'Zhuangyan (Yan)'" <>,
References: <> <> <00a501d1e1d7$8bfdcf60$a3f96e20$> <>
In-Reply-To: <>
Date: Fri, 22 Jul 2016 10:42:29 +0100
Message-ID: <09d101d1e3fd$5d6d72e0$184858a0$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_09D2_01D1E405.BF3620A0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGVZEd6TwZTYTYlD7c4/u6zvL+3ggEjBUmmAvTAHFUB4VQ/eaBtW1GA
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-
X-TM-AS-Result: No--12.633-10.0-31-10
X-imss-scan-details: No--12.633-10.0-31-10
X-TMASE-MatchedRID: JorHcieTUslbJCKOm3VRCTvLQX9D9MvHRLaMSRAheO7ZbKeIhXhJa4hQ XRYSwXGZl4ekJe9pqCGQTsyupo9izZjkpj391btm2qqh/6B8PpEUwQ+zl/NLC1gOJfW3AR4Y5Wh uBamJStQ9sRkzc+jk5Zmug812qIbzvNY4Opm8STm638ZUY6gSdzypgVxZjh6lO3n9SKxiPk5HRI pOdliZ+64jY8PS6Fo7F0vYDRID+cpIIISh6IRMoOOxOq7LQlGLkhD59e4L9ID+SkxPwt4b9PaaE ZAHJRdejwxQRBgUpva3UCG/IQp2PjoSfZud5+Ggh8BhJvgqWBl/XJt1+nNNwKjYi/1hSfmCLgju eTnHOLoR8hZMqdJm+cFWmsryu9ZffkuZtv/FS5p03GAz54To+/RPdGKxu2/jogXTByfViOiYisc WDCQrIl9l0JBWZBoPvwylzmXaJXKYf3r4ZCpo6iJ8zskw0dbrjPNt0qgZHhIundZDZWRtwehuvm KfXuukmo2ZG/E7i3M3YXMbdTc5rqX1XMd/SqvuC4miDHQ45vnx+7bi9dWMXUKCKVdcr03jSR1Mt KFnpBNeUK17YvKvWZLZ8vkjKkOxG7myQIxu4L9XPwnnY5XL5OyLQG9V/UV4BJcdzAaRpXEY1KH0 sBt2MR2P280ZiGmRZ/lgUjcssyHz+FNqSFH80P0TP/kikeqnxX/m3s/yzsEOakZ3BhIK39GJ8Ch bkA+ff/9oLiCflNj9KXlxhBAZb4N12XKYbuJLVxt8iPZNr2yALjqnIlNKdNXjKfop/WvT3wqC9Q su3hf9+rKlRf1WaEtzk37SzX4NpVPQMeOFNBSbKItl61J/yZUdXE/WGn0F+qVD1+oFOAmHHQtvy gWztA4g/DDnhFJDw3LlWp/m/8VhoRuYMO4bwI7ujjERYA9n2Jn1S+CDtZJK13rq54uRKkeIDqzn tk8+P1aq+/c50Tj7F1bXydRIxx/BXqwE9HSW
Archived-At: <>
Cc: 'TEAS WG' <>
Subject: Re: [Teas] draft-zhuang-teas-scheduled-resources
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 22 Jul 2016 09:43:11 -0000

Good to know you're happy for us to move ahead with adoption and handle this
issue as part of the WG discussion.
However, no reason to wait for that before we start the discussion.
I just spent some time looking at draft-zhuang-pce-stateful-pce-lsp-scheduling
(which is what I assume you mean by "the solution doc" as mentioned in the
minutes).  Of course, the chronology of architecture and solution is a little
broken, and we need to converge the two things: architecture must meet the needs
that the solution demonstrates; solution needs to conform to the architecture.
I'd like to try to pin down exactly what synchronization you are looking for (so
we can add the right text). I presume you are not looking for the network/PCE
synchronization that is just business as usual for a stateful PCE. Your focus
is, I suspect, Appendix A of the solution document, and the challenge is that
when one PCE "commits" to supply a scheduled LSP, it needs to install something
in its peer PCEs so that there is no conflict for future resources. The choice
is whether to synch the scheduled-LSP-DB or the scheduled TED (or both).
This issue is certainly discussed in draft-zhuang-teas-scheduled-resources-02,
but possibly not sufficiently for your pleasure. I see:
- Section 3.1 bottom bullet of page 6
- Section 4.2
Bottom line, we agree that DB synch is important, we believe it builds on synch
for pre-scheduling PCE work, we are happy to add text.
Would you or Dhruv like to suggest text, or at least pin down a little more
clearly what you'd like to see?
From: Daniele Ceccarelli [] 
Sent: 21 July 2016 11:27
To:; 'Zhuangyan (Yan)';
Subject: RE: [Teas] draft-zhuang-teas-scheduled-resources
Hi Adrian, Yan,
Congratulations for the wide support! :D 
I concur with Dhruv’s comment on synchronization, that needs to be addressed IMO
and I agree to have it done after WG adoption.
Please see inline.
From: Adrian Farrel [] 
Sent: martedì 19 luglio 2016 18:07
To: 'Zhuangyan (Yan)' <>; Daniele Ceccarelli
Cc: 'TEAS WG' <>
Subject: RE: [Teas] draft-zhuang-teas-scheduled-resources
See [AF].
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 [ <> 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?
[DC] the text as is seems to say that SDN == direct control of network elements.
Just removing “such as in the SDN paradigm” should be fine.
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.
[DC] ok and agree with that. My point (maybe misinterpreted) is that you needed
that info for path computation. I’d say you might need it for path computation
is you plan for a future LSP and later on you decide to build a totally disjoint
LSP…but I’m not sure it is a case worth being covered.
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.
[DC] I see the continuum easy to manage as you store the info that you need to
store is that the LSP will be in place from T1 to T2 and not at T1, T1+1slot,
T1+2slots, T1+3slots…maybe I’m missing something.
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.
[DC] like for example?
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
   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
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.