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

"Zhuangyan (Yan)" <> Tue, 19 July 2016 09:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3379212DFDC for <>; Tue, 19 Jul 2016 02:32:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.507
X-Spam-Status: No, score=-5.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id v36bO97iICVP for <>; Tue, 19 Jul 2016 02:32:14 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2419312DF41 for <>; Tue, 19 Jul 2016 02:22:33 -0700 (PDT)
Received: from (EHLO ([]) by (MOS 4.3.7-GA FastPath queued) with ESMTP id CSV28376; Tue, 19 Jul 2016 09:22:30 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Tue, 19 Jul 2016 10:22:29 +0100
Received: from ([]) by ([]) with mapi id 14.03.0235.001; Tue, 19 Jul 2016 17:22:25 +0800
From: "Zhuangyan (Yan)" <>
To: Daniele Ceccarelli <>, "" <>
Thread-Topic: draft-zhuang-teas-scheduled-resources
Thread-Index: AdHg3v55LWSTWffRT2aakfMvNZaWJgAsfwZQ
Date: Tue, 19 Jul 2016 09:22:24 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_9B4BC45FDEDDD84F813E9E4A5BAF87859422AA6Enkgeml513mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.578DF157.0016, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 71cc49e789bd02b0bb85feec2f72d1ff
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: Tue, 19 Jul 2016 09:32:20 -0000

Hi Daniele,

Thank you very much for the review and comments.
Please see some responses inline.

Best Regards,


·¢¼þÈË: Teas [] ´ú±í Daniele Ceccarelli
·¢ËÍʱ¼ä: 2016Äê7ÔÂ19ÈÕ 7:10
Ö÷Ìâ: [Teas] draft-zhuang-teas-scheduled-resources

Hi Yan, authors,

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.

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.

2.       Section 3.2 ¨C 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.

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. ¨C 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.

Thank you again and please feel free to share more thoughts.