Re: [Pce] stateful-HPCE

"weiw" <weiw@bupt.edu.cn> Fri, 19 August 2016 14:12 UTC

Date: Fri, 19 Aug 2016 22:12:53 +0800
From: weiw <weiw@bupt.edu.cn>
To: Leeyoung <leeyoung@huawei.com>, "pce@ietf.org" <pce@ietf.org>
In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E172A8AC8E3@dfweml501-mbx>
References: <7AEB3D6833318045B4AE71C2C87E8E172A8AC8E3@dfweml501-mbx>
MIME-Version: 1.0
Message-ID: <57B713E3.4090607@bupt.edu.cn>
Content-Type: multipart/alternative; boundary="====003__MESSAGE__ID__54yg6f6h6y456345===="
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/62fJqyupu3-nzHImo1y2LJRzMcM>
Subject: Re: [Pce] stateful-HPCE
Precedence: list

Hi Young and PCE GW,

I am now implementing a ACTN control framework for transport networks, which is a usecase for stateful HPCE. In the coding process, I find some problems about this draft, as follows.

In the beginning of section 3, it states that "In the hierarchical PCE architecture, a P-PCE maintains a domain topology map that contains the child domains (seen as vertices in the topology) and their interconnections (links
in the topology. The P-PCE has no information about the content of the child domains.)". I think it means that P-PCE only has some abstracted information about physical network elements.

According to the considerations above, I think the stateful related messages (PCUpd, PCRpt, PCInitiate) and PCRep should be used in a different way between P-PCE and C-PCE, because we need to do some abstraction processing on these message to report the abstracted information so that P-PCE can match them to the abstracted topology and TE information it has. For example, in the condition where C-PCE only report the border nodes to its P-PCE, it also need to report a abstracted path (whose RRO feild is composed of border nodes) to its P-PCE. Also, in the perspective of security, it not reasonable for C-PCE to forward the physical network specific information carried in PCRep and PCRpt message to P-PCE without any abstraction processing. It is a kind of information leaking in the condition where C-PCEs do not want to provide detailed information about their physical networks to P-PCE.

Consequently, I suggest to add one section to clarify the abstraction processing requirment for the stateful related messages (PCUpd, PCRpt, PCInitiate) and PCRep.

If the abstraction processing is mandatory, there would be another problem, as follows.

This draft provide two usecases for LSP initiation in stateful HPCE context, as section 3.3. One can be concludes as "initiated by P-PCE", and the other "Per Domain Stitched LSP".
For the first case, the P-PCE can choose an optimal abstracted E2E path according to the Hierarchical End-to-End Path Computation Procedure in section 4.6.2 of [RFC6805]. While, the P-PCE cannot initiate a LSP by sending this abstrated path info to the Ingress PCC via ingress C-PCE, becuse the ingress PCC would be confused by the abstracted hop information. How to deal with this case?
The draft is OK for the second usecase, where each C-PCE is responsible for initiating its own intra-domain LSP.

Thanks,
Wei Wang

发件人：Leeyoung <leeyoung@huawei.com>
发送时间：2016-07-21 23:58
主题：[Pce] stateful-HPCE
收件人："pce@ietf.org"<pce@ietf.org>
抄送：

Hi PCE WG,

https://datatracker.ietf.org/doc/draft-dhodylee-pce-stateful-hpce/

We’d like to solicit WG’s comment on this draft. As Dhruv presented today in the PCE WG meeting, this draft does not add any new protocol work. It is informational only and the co-authors believe this draft can move to the next step.

Thanks in advance for your comments, suggestions, etc for this draft.

Young (on behalf of co-authors and contributors).