Re: [Pce] Alvaro Retana's No Objection on draft-ietf-pce-stateful-pce-app-07: (with COMMENT)

"Zhangxian (Xian)" <zhang.xian@huawei.com> Mon, 31 October 2016 08:15 UTC

Return-Path: <zhang.xian@huawei.com>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF411293E4; Mon, 31 Oct 2016 01:15:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.718
X-Spam-Level:
X-Spam-Status: No, score=-5.718 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.497, SPF_PASS=-0.001] 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 kIoxylveobTW; Mon, 31 Oct 2016 01:15:51 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF6D7127A90; Mon, 31 Oct 2016 01:15:50 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CUF26802; Mon, 31 Oct 2016 08:15:47 +0000 (GMT)
Received: from SZXEMA413-HUB.china.huawei.com (10.82.72.72) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 31 Oct 2016 08:14:56 +0000
Received: from SZXEMA512-MBS.china.huawei.com ([169.254.8.52]) by SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id 14.03.0235.001; Mon, 31 Oct 2016 16:14:46 +0800
From: "Zhangxian (Xian)" <zhang.xian@huawei.com>
To: Alvaro Retana <aretana@cisco.com>, The IESG <iesg@ietf.org>
Thread-Topic: Alvaro Retana's No Objection on draft-ietf-pce-stateful-pce-app-07: (with COMMENT)
Thread-Index: AQHSLsAAQjk6jxMCu0WL4cZEt0Vd1aDCPd5g
Date: Mon, 31 Oct 2016 08:14:45 +0000
Message-ID: <C636AF2FA540124E9B9ACB5A6BECCE6B7DF4D22B@SZXEMA512-MBS.china.huawei.com>
References: <147740052242.15199.4026997320564075389.idtracker@ietfa.amsl.com>
In-Reply-To: <147740052242.15199.4026997320564075389.idtracker@ietfa.amsl.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.63.139.68]
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.0A020202.5816FDB3.00FA, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.8.52, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 33b3da5710508ce801f20fe9fe2c9cc0
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/8Msw8kNj8OH9mwGz5X2xiB2R7pI>
Cc: "draft-ietf-pce-stateful-pce-app@ietf.org" <draft-ietf-pce-stateful-pce-app@ietf.org>, "pce@ietf.org" <pce@ietf.org>, "pce-chairs@ietf.org" <pce-chairs@ietf.org>
Subject: Re: [Pce] Alvaro Retana's No Objection on draft-ietf-pce-stateful-pce-app-07: (with COMMENT)
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Oct 2016 08:15:54 -0000

Dear Alvaro, 

   First of all, we would like to thank you for identifying the circular dependencies. After discussions among AD/chair/authors, we all agree with what you said below, i.e., " I think that the application scenarios and motivation for future extensions should be able to be described without referring to the extensions themselves". 

   So, we have worked out and uploaded a new version to remove all the dependencies that you have raised plus those we think should be cleared to make it generic/not depending on protocol extension drafts.  Could you please check the diff to see if you are happy with the latest version to proceed? (URL: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-stateful-pce-app-08). 

Regards,
Xian 

-----邮件原件-----
发件人: Alvaro Retana [mailto:aretana@cisco.com] 
发送时间: 2016年10月25日 21:02
收件人: The IESG
抄送: draft-ietf-pce-stateful-pce-app@ietf.org; Jonathan Hardwick; pce-chairs@ietf.org; jonathan.hardwick@metaswitch.com; pce@ietf.org
主题: Alvaro Retana's No Objection on draft-ietf-pce-stateful-pce-app-07: (with COMMENT)

Alvaro Retana has entered the following ballot position for
draft-ietf-pce-stateful-pce-app-07: No Objection

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-app/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

This document mostly presents application scenarios, which (by reference) serve as motivation for draft-ietf-pce-stateful-pce.  However, there are a couple of places (in Section 4) where the operation defined in draft-ietf-pce-stateful-pce is used as part of the considerations.  For example (from 4.1):

   Stateless and stateful PCEs can co-exist in the same network and be
   in charge of path computation of different types.  To solve the
   problem of distinguishing between the two types of PCEs, either
   discovery or configuration may be used.  The capability negotiation
   in [I-D.ietf-pce-stateful-pce] ensures correct operation when the PCE
   address is configured on the PCC.

I see a circular dependency between this document and draft-ietf-pce-stateful-pce, where the considerations here are expected to motivate the extensions, but the specific extensions are used to discuss “generic issues with stateful PCE deployments”.

Given that draft-ietf-pce-stateful-pce is a Normative Reference, I would rather see this document come back for IESG Evaluation with/after draft-ietf-pce-stateful-pce.  Note that draft-ietf-pce-stateful-pce is still (AFAICT) under consideration in the WG.


I am not making this comment a DISCUSS because I don’t think that it raises to the appropriate level (as only some parts of the document seem to have the dependency), and we’ll have to wait for draft-ietf-pce-stateful-pce to be processed before publication anyway. 
However, I think that the application scenarios and motivation for future extensions should be able to be described without referring to the extensions themselves — I would then like the authors, Shepherd and the responsible AD to consider whether it is possible for this document to stand on its own, or whether we need to process it with the extensions draft.  Given that draft-ietf-pce-stateful-pce is still in the WG, I think it is important for us to talk about it as this point.  I noted in the Shepherd’s writeup that this document used to be “originally included in the base stateful PCE protocol specification” (which I assume is draft-ietf-pce-stateful-pce).

To be clear: I am not opposing the publication of this document (even though the content could have been part of draft-ietf-pce-stateful-pce), I just think that in the current form it should be processed/published
*with* draft-ietf-pce-stateful-pce.


[Mechanisms from I-D.ietf-pce-stateful-sync-optimizations and I-D.ietf-pce-pce-initiated-lsp are also mentioned in similar ways, and those drafts are also in process in the WG.  I’m focusing on draft-ietf-pce-stateful-pce above just to make the point.]