Re: [Pce] stateful-HPCE

[Leeyoung <[e-mail]>]

Hi Dhruv,

Thanks for this illustration and action to further clarify in the text of the mentioned drafts. 

Hi Wei, 

I have one more comment back to Wei's question. Please see my comment inline. 

Thanks.
Young


-----Original Message-----
From: Dhruv Dhody 
Sent: Monday, August 22, 2016 7:14 AM
To: 'weiw'; Leeyoung; [e-mail]
Cc: Dhruv Dhody
Subject: RE: [Pce] stateful-HPCE

Hi Wei, 

Thanks for your comments. 

In the Stateful H-PCE [https://tools.ietf.org/html/draft-dhodylee-pce-stateful-hpce-00] -  we describe the architectural considerations when Hierarchy of stateful PCEs are deployed. It combines two existing idea - H-PCE [RFC6805] and Stateful PCE. It mentions ACTN only in passing.
 
And thus in this draft, the abstract topology is per RFC6805 (domain topology map) and the P-PCE uses the technique of RFC6805 to compute full E2E path using PCReq/PCRep. Because in the context of this document, the full E2E path is known at P-PCE, and we do not need to abstract information received from PCC at C-PCE, before sending it to P-PCE and vice-versa (though an implementation may choose to do it anyways, in the way Young mentioned). 

In the context of ACTN, your comment is valid, and I will add text in this document as well as PCE-ACTN [https://tools.ietf.org/html/draft-dhody-pce-applicability-actn-00], which describes how to use PCE (and PCEP) in ACTN framework. 

To clarify, let us take a case when P-PCE has abstract topology and it computes path directly on this topology (and not use the RFC6805 procedures) and thus there is a need for translation. 

               P-PCE
              /     \
             /       \
            /         \ Abstracted Path
           /           \
          /             \
         /               \
      C-PCE1              C-PCE2
       /                    |
      /                     | Full Path
     /                      |
    /                       |
   A1--A2--A3--BN-AB------BN-BA---B2---B1

     Domain A                 Domain B

In the above simple example 

C-PCE1 provides an abstract topology (A1---A---BN-AB), hiding A1 and A2 and instead creating an abstract node A
C-PCE2 provides an abstract topology (BN-BA---B1), hiding node B2

When P-PCE works on the abstracted topology and provide paths in terms of abstraction as (A1->A->BN-AB) and (BN-BA->B1); the C-PCE needs to translate these into the full paths as (A->A2->A3->BN-AB) and (BN-BA->B2->B3) respectively. 
And when C-PCE receive report from the PCC it needs to convert that back into the terms of abstract topology.

I will add text in both documents. 

Regards,
Dhruv



From: Pce [mailto:[e-mail]] On Behalf Of weiw
Sent: 22 August 2016 13:10
To: Leeyoung <[e-mail]>; [e-mail]
Subject: Re: [Pce] stateful-HPCE

Hi Young,
 
Happy to see that we have the same point on my first question. 
 
Regarding to the second question , I think I need to express it more clearly.
 
In the beginning of section 3.3, the draft provides the initiation operations for the case of inter-domain LSP in HPCE architecture. The main idea of E2E path computation is as per Steps 4 to 10 of section 4.6.2 of [RFC6805], where C-PCEs are responsible for intra-domain path computation, and P-PCE is correlating all the responses from C-PCEs and stitching them with the inter-domain links together as one inter-domain path. After getting the required inter-domain path, the P-PCE starts the inter-domain LSP initiation operations, and the detailed procedures are as per step 2 to 7 of section 3.3 of this draft. The main idea is P-PCE send the PCInitiate message to the Ingress C-PCE, and then the C-PCE propergates it to the Ingress LSP(PCC).
After receiving the PCInitiate message, the Ingress LSR needs to set up the LSP hop by hop in dataplane via LDP (RSVP or someone else). To do such operations, I guess the Ingress PCC MUST know the detailed Hop information of the whole inter-domain path.
 
In the HPCE architecture without any abstraction, these procedures make sense because the P-PCE can get the detailed hop informaition from each C-PCE, and send it via PCInitiate message to the Ingress LSP.
While, if there exists abstraction (like the border nodes level abstraction) between P-PCE and C-PCE, the P-PCE may get only abstracted path information from each C-PCE. Following the procedures mentioned above, the P-PCE will send the abstracted path information to the Ingress C-PCE, and then to the Ingress LSR. Even though C-PCE has the ability to translate the abstracted path information to C-PCE(PNC) level, the Ingress LSR still cannot get the overall Hop information, because it receives the PCInitiate message via ONLY Ingress C-PCE(without help of any other C-PCEs). 

YOUNG>> with the diagram Dhruv drew above, you are talking about C-PCE to PCC (LSR) as to how PCC (LSR) would know the overall Hop information (I think you meant every hop of the end-to-end LSP). The head-end LSR of the first domain does not have to know the end-to-end hop information. The C-PCE of that domain would tell the headend LSR its detailed LSP hop info up to the border node of that domain. Likewise, other domains would create their domain LSP. Then we need some stitching mechanism (which is not the scope of this draft) to stitch the endto-end LSP. The P-PCE would coordinate the domain sequence and interact with each C-PCE on the determined domain sequence.   
 
So I think the proceduress described in the beginning of section 3.3 are not applicable for the HPCE architecture where abstraction exists.
 
Section 3.1.1 describes a different mode named "Per Domain Stitched LSP", and I think this mode is better for HPCE architecture.
 
Thanks,
 
Best Regards,
Wei Wang
________________________________________
发件人：Leeyoung <[e-mail]>
发送时间：2016-08-20 03:22
主题：RE: [Pce] stateful-HPCE
收件人："weiw"<[e-mail]>,"[e-mail]"<[e-mail]>
抄送："Jonathan.Hardwick"<[e-mail]>
 
Hi Wei,

Thanks for your comment on Stateful H-PCE draft. Please see my comment on some of your questions. Dhruv might also have his comments. 

Best regards,
Young

From: weiw [mailto:[e-mail]]
Sent: Friday, August 19, 2016 9:13 AM
To: Leeyoung; [e-mail]
Cc: Jonathan.Hardwick
Subject: Re: [Pce] stateful-HPCE

Hi Young and PCE WG,
 
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. 

YOUNG>> Yes, when it says vertices in the topology, it implies that it is an abstraction. We can make it more clear on this in the next revision.

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.
 
YOUNG>> It is correct that the there is a level of difference between 
YOUNG>> MPI and SBI (in ACTN terms) as to how much details should be disclosed. But the basic stateful (and stateless) PCEP messages will be applicable as is across PCE-PCC (SBI) and P-PCE-C-PCE (MPI). The current PCEP messages/Objects/TLVs allow expressing TE information (which is basically, nodes, links, b/w, etc.) in an abstracted way. I think you are talking about how to abstract RRO of an LSP for instance. You can use “loose hop” notion to hide internal details, simply giving the source border node and the destination border node.

Consequently, I suggest to add one section to clarify the abstraction processing requirment for the stateful related messages (PCUpd, PCRpt, PCInitiate) and PCRep.
 
YOUNG>> This can be done. 
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?

YOUNG>> P-PCE should know the border nodes domain networks when it computes an E2E path across multiple domains. P-PCE would express the C-PCEs to create LSP between a pair of border nodes (source and destination) for each domain. Do you see any issue with this? Then each C-PCE will setup an LSP that connects the border nodes. I don’t think C-PCE would be confused with this method. 

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 <[e-mail]>
发送时间：2016-07-21 23:58
主题：[Pce] stateful-HPCE
收件人："[e-mail]"<[e-mail]>
抄送：
 
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).