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

Dhruv Dhody <> Tue, 09 August 2016 13:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6721812D86C for <>; Tue, 9 Aug 2016 06:36:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.468
X-Spam-Status: No, score=-5.468 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id t0MqdnMIPjCv for <>; Tue, 9 Aug 2016 06:36:24 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CE33A12D843 for <>; Tue, 9 Aug 2016 06:36:22 -0700 (PDT)
Received: from (EHLO ([]) by (MOS 4.3.7-GA FastPath queued) with ESMTP id CPD41029; Tue, 09 Aug 2016 13:36:20 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Tue, 9 Aug 2016 14:36:12 +0100
Received: from ([]) by ([]) with mapi id 14.03.0235.001; Tue, 9 Aug 2016 19:06:00 +0530
From: Dhruv Dhody <>
To: "" <>, 'Dhruv Dhody' <>
Thread-Topic: [Teas] draft-zhuang-teas-scheduled-resources
Date: Tue, 09 Aug 2016 13:36:00 +0000
Message-ID: <23CE718903A838468A8B325B80962F9B8C91CC61@blreml501-mbx>
References: <> <> <00a501d1e1d7$8bfdcf60$a3f96e20$> <> <09d101d1e3fd$5d6d72e0$184858a0$> <> <23CE718903A838468A8B325B80962F9B8C91B856@blreml501-mbx> <0ac001d1f164$d9b0a0b0$8d11e210$>
In-Reply-To: <0ac001d1f164$d9b0a0b0$8d11e210$>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090205.57A9DC54.010A, 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: e5cf2b495a5dd44041e8a23a943ab5e7
Archived-At: <>
Cc: "Zhuangyan (Yan)" <>, "" <>, 'Daniele Ceccarelli' <>, '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, 09 Aug 2016 13:36:26 -0000

Hi Adrian, 

Please see inline...

> -----Original Message-----
> From: Adrian Farrel []
> Ciao Dhruv,
> > Here is the text for the section on synchronization between PCEs
> Thanks!
> > as well as a few more comments
> Welcomed.
> > (1) Why is the intended status of the document "Standards Track"?
> Why, indeed?!
> I don't plan to have that conversation :-) IMHO, an architecture is normative
> for solutions work.
> But opinions vary and we will be guided by our chairs and the AD.
[Dhruv] I am happy with chairs/AD taking the call :)

> > (2) In section 2.4, perhaps we should limit to simple example of
> > resources, do  you see value in including CPU utilization and buffers?
> Well, the example is in the text:
>    The resource that is scheduled can be link capacity, physical
>    resources on a link, CPU utilization, memory, buffers on an
>    interfaces, etc.  The resource might also be the maximal unreserved
>    bandwidth of the link over a time intervals.  For any one resource
>    there could be multiple pieces of scheduling state, and for any one
>    link, the timing windows might overlap.
> The intention is to illustrate that a wide range of things could be considered
> as "resources".
> Is there any harm in the text?
[Dhruv] The only harm (well not really harm, but...) would be that so far none of the RSVP or RSVP-TE documents, as far as I am aware of, explicitly included "CPU utilization, memory, buffers..." as resources that could be reserved; which made me wonder if a document about scheduling should? 

> > (4) In section 4.1, would it be better to differentiate between the
> > case when service requester is App/NMS v/s when it is an LSR.
> > Basically to show, when the arrow (a) in the figure is via a
> > management interface.
> Hmm. I thought that one of the things that 4655 made clear was that there
> was no difference between a request from an NMS or from an LSR.
> Indeed, the "service requester" in the figure could be the "LSR" shown in
> the same figure.  I will make that point clearer, although the paragraph
> starts with an observation about the requester.
[Dhruv] I agree with you. The only issue I had was in the text - 

   When it is time such as at a start time for the LSP to be set up, the
   PCE sends a PCEP Initiate request to the head end LSR (d) providing
   the path to be signaled as well as other parameters such as the
   bandwidth of the LSP.

When a LSR/PCC is configured with a tunnel with scheduling information, it can send a "service request" to PCE via a PCEP message  (PCRpt) and in this case, I am not sure if the use of a PCEP Initiate message from PCE to setup the LSP is right choice. I guess we can debate that in the solution document, a simple resolution would be either to say PCInitiate/PCUpd message or not to mention a message by name.   


> > Thanks and apologies for taking a bit more time!
> No problem. Thank you for the input. You are now a contributor :-)

[Dhruv] Thanks! :)


> Adrian