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

"Adrian Farrel" <> Mon, 08 August 2016 11:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D29D612D8A0 for <>; Mon, 8 Aug 2016 04:07:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 hJhXE-wTnxDC for <>; Mon, 8 Aug 2016 04:07:41 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DE01A12D825 for <>; Mon, 8 Aug 2016 04:06:13 -0700 (PDT)
Received: from (localhost.localdomain []) by (8.13.8/8.13.8) with ESMTP id u78B62x0025244; Mon, 8 Aug 2016 12:06:02 +0100
Received: from 950129200 ([]) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id u78B61rp025224 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 8 Aug 2016 12:06:01 +0100
From: Adrian Farrel <>
To: 'Dhruv Dhody' <>, 'Dhruv Dhody' <>
References: <> <> <00a501d1e1d7$8bfdcf60$a3f96e20$> <> <09d101d1e3fd$5d6d72e0$184858a0$> <> <23CE718903A838468A8B325B80962F9B8C91B856@blreml501-mbx>
In-Reply-To: <23CE718903A838468A8B325B80962F9B8C91B856@blreml501-mbx>
Date: Mon, 08 Aug 2016 12:06:01 +0100
Message-ID: <0ac001d1f164$d9b0a0b0$8d11e210$>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGVZEd6TwZTYTYlD7c4/u6zvL+3ggEjBUmmAvTAHFUB4VQ/eQJDdEhjAlLuHWQC+17FuKBLlz9Q
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-
X-TM-AS-Result: No--21.324-10.0-31-10
X-imss-scan-details: No--21.324-10.0-31-10
X-TMASE-MatchedRID: C/snMIRQLS0WUCLmtsxQXfHkpkyUphL9yeUl7aCTy8io+b+yOP0oGNUK tDQSklYjyQSBbnGGc+m5P4MH3MxcT7G8dzu2wTUiW7gz/Gbgpl7Sde/CNbaZJcgYL9oUjHj+0o4 KCDYaoqUmWIh6T/rLQIm1qicqBcAnxMH2MOMU8Vv0gcKB5NC/U23eqxoVjgME/RM/+SKR6qdmnm 4Fwm3ttsSGf3BWU6o0p6nLBJscCjsUlFtHtcPLMaPzv5LU1D23NACnndLvXwfIvQIyugvKddNyA nzaxVyXTupBKcY88KLTAUboZ3mtse+c5IL6OTgOFyqkfsPWu1CP/EshoNKyEcgJv3mVhDpKlHXp pcpLXlDGs3ZJhotca2AdixTw/Gi0LSTGw1g/Kd5PuMJi/ZAk8UyQ5fRSh265TgrQgyTabcb6xkj LRFWGPWRGZ3UhNJo55KS/HhpDvmNJ+HTEll5bHRMMmcrjEONdtuzctX6vZw+bKItl61J/ybLn+0 Vm71Lcq7rFUcuGp/G8QIu4z6HhEH7cGd19dSFd
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: Mon, 08 Aug 2016 11:07:43 -0000

Ciao Dhruv,

> Here is the text for the section on synchronization between PCEs


> as well as a few more comments 


> (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.

> (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?

> (3) In Section 3.1
>   *  If the scheduling state is held centrally at a PCE, the state
>      must be held and restored after a system restart.  This is
>      relatively easy to achieve on a central server that can have
>      access to non-volatile storage.
>   *  If the scheduling state is held centrally at a PCE, the state
>      must be held and restored after a system restart.  This is
>      relatively easy to achieve on a central server that can have
>      access to non-volatile storage. The PCE could also synchronize 
>       the scheduling state with other PCEs after restart. See section 
>       4.2 for details.            

Yes. Thanks.

> (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.

> In case of LSR, do we allow configuration of future LSP at the LSR? If yes when does PCE
> learns about it?

Yes, it's allowed. I guess the PCE learns about it at the time the LSR chooses to tell it. If it leaves it late, however, it runs the risk of resources having been booked for something else.  In this respect there is no difference between this LSP and any other scheduled LSP.

> It would be helpful for PCE to know in advance and thus in this case (a) and (d) are
> sort of merged and we use PCEP for service request too, (perhaps via delegation
> of a future LSP, which will impact the choice of PCEP message in (d))...  

Don't mix up the actors with the actions. (a) is the request for an LSP to be scheduled, and (d) is the "command" to set up the LSP.

> (5)A new section on State synchronization 
> 4.3  Synchronization between the PCEs


Thanks for this text.

> (6) Some idnits exist

Yup. Tidiness is next to godliness.

> Thanks and apologies for taking a bit more time! 

No problem. Thank you for the input. You are now a contributor :-)