Hi Avantika, I am forwarding the mail with your review comments to the PCE List as well
Hi WG, We have update the document. Name: draft-dhody-pce-applicability-actn Revision: 01 Title: Applicability of Path Computation Element (PCE) for Abstraction and Control of TE Networks (ACTN) Document date: 2016-10-19 Group: Individual Submission Pages: 15 URL: https://www.ietf.org/internet-drafts/draft-dhody-pce-applicability-actn-01.txt Status: https://datatracker.ietf.org/doc/draft-dhody-pce-applicability-actn/ Htmlized: https://tools.ietf.org/html/draft-dhody-pce-applicability-actn-01 Diff: https://www.ietf.org/rfcdiff?url2=draft-dhody-pce-applicability-actn-01 The main changes are - Resolution of comments from Avantika - Comments received at mic, notably from Jon n Added text to highlight that not all functions need to be implemented in PCEP It should be noted that, in this document we list all possible ways in which PCEP could be used for each of the above functions, but all functions are not required to be implemented via PCEP. Operator may choose to use the PCEP for multi domain coordination via stateful H-PCE but use RestConf or BGP-LS to get the topology and support virtualization/abstraction function. n Added section on Relationship to PCE based central control Thanks! Comments are welcome! Regards, Dhruv (Young & Daniele) From: Dhruv Dhody Sent: 18 October 2016 11:46 To: Avantika <[email protected]>; Satish Karunanithi <[email protected]> Cc: Leeyoung <[email protected]>; Dhruv Dhody <[email protected]> Subject: RE: PCE Applicability to ACTN Thanks for your comments, updated in document. See inline... From: Avantika Sent: 19 July 2016 10:12 To: Dhruv Dhody <[email protected]<mailto:[email protected]>>; Satish Karunanithi <[email protected]<mailto:[email protected]>> Subject: RE: PCE Applicability to ACTN Hi Dhruv, I have few suggestions: 1. <t><xref target="I-D.ietf-pce-stateful-pce"/> also describes the active stateful PCE. The active PCE functionality allows a PCE to reroute an existing LSP or make changes to the attributes of an existing LSP, or delegate control of specific LSPs to a new PCE.</t> <t><xref target="I-D.ietf-pce-stateful-pce"/> also describes the active stateful PCE. The active PCE functionality allows a PCE to reroute an existing LSP or make changes to the attributes of an existing LSP, or PCC to delegate control of specific LSPs to a new PCE.</t> 2. <t>This document examines the PCE and ACTN architecture and describes how the PCE architecture is applicable to ACTN. It also list the PCEP extensions that are needed to use PCEP as an ACTN interface. This documents also identify any gaps in PCEP, that exist at the time of publication of this document.</t> </section> <t>This document examines the PCE and ACTN architecture and describes how the PCE architecture is applicable to ACTN. It also lists the PCEP extensions that are needed to use PCEP as an ACTN interface. This documents also identifies any gaps in PCEP, that exist at the time of publication of this document.</t> </section> 3. <xref target="I-D.dhodylee-pce-stateful-hpce"/>, for inter-domain LSP in Hierarchical PCE architecture, the initiation operations can be carried out at the parent PCE. In which case after parent PCE finishes the E2E path computation, it can send the PCInitiate message to the child PCE, the PCE further propagates the initiate request to the PCC.</t> <t></t> <xref target="I-D.dhodylee-pce-stateful-hpce"/>, for inter-domain LSP in Hierarchical PCE architecture, the initiation operations can be carried out at the parent PCE. In which case after parent PCE finishes the E2E path computation, it can send the PCInitiate message to the child PCEs, the child PCEs further propagate the initiate requests to the PCCs.</t> <t></t> 4. The PNC (or child PCE) uses PCEP to communicate to the network device already. Do you mean: "The PNC (or child PCE) already uses PCEP to communicate to the network device." 5. This could as simple as a domain topology map as described in <xref target="RFC6805"/> or it can have full topology information of all domains. This could be as simple as a domain topology map as described in <xref target="RFC6805"/> or it can have full topology information of all domains. 6. The latter is not scalable and thus an abstracted topology of each domain interconnected by inter-domain links is the most common case. Is there also a problem of confidentiality in the latter? [Dhruv] Yes but I wanted to avoid confidentiality from the text here and highlight scalability only as in ACTN we assume trusted domain. 7. <list style="symbols"> <t>Topology Change: When the PNC learns of any topology change, the PNC needs to decide if the change needs to be notified to the MDSC. This is dependent on the level abstraction between the MDSC and the PNC.</t> </list> </t> <list style="symbols"> <t>Topology Change: When the PNC learns of any topology change, the PNC needs to decide if the change needs to be notified to the MDSC. This is dependent on the level of abstraction between the MDSC and the PNC.</t> </list> </t> 8. <t>VN Instantiate: MDSC is requested to instantiate a VN, the minimal information that is required would be a VN identifier, a set of end points. Various path computation and setup constraints and objective functions may also be provided. In PCE terms, a VN Instantiate can be considered as a set of Path belonging to the same VN. <t>VN Instantiate: MDSC is requested to instantiate a VN, the minimal information that is required would be a VN identifier and a set of end points. Various path computation and, setup constraints and objective functions may also be provided. In PCE terms, a VN Instantiate can be considered as a set of Path paths belonging to the same VN. 9. <t>Per Domain Path Instantiation: Based on the above path computation, MDSC can issue the path instantiation request to each PNC via PCInitiate message (see <xref target="I-D.dhodylee-pce-stateful-hpce"/> and <xref target="I-D.leedhody-pce-vn-association"/>). The message from MDSC to PNC can contain a partial path, in which case the PNC computes the full path in the domain. Do we need to handle in text the cases in which MDSC given path is different from the path computed by PNC? (may be based on timing issue or maybe because abstraction makes two paths same to MDSC but PNC can make finer distinction (I am very confident if second case is permitted in abstraction principles..)) [Dhruv]: I added this text instead - In case PNC generates an abstract topology to the MDSC, the PCInitiate/PCUpd messages from the MDSC to a PNC will contain a path with abstract nodes and links. PNC would need to take that as an input for path computation to get a path with physical nodes and links. Similarly PNC would convert the path received from the device (with physical nodes and links) into abstract path (based on the abstract topology generated before with abstract nodes and links) and reported to the MDSC. 10. Is there a need to add text for E2E (parent LSP) MBB handling? [Dhruv]: I have added - This should be done in make-before-break fashion. I am shying away from putting more details right now. Regards, Avantika From: Dhruv Dhody Sent: 04 July 2016 11:07 To: Satish Karunanithi; Udayasree palle; Avantika Subject: FW: PCE Applicability to ACTN Please provide comments.... From: Dhruv Dhody Sent: 04 July 2016 11:05 To: Leeyoung <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Cc: Dhruv Dhody ([email protected]<mailto:[email protected]>) ([email protected]<mailto:[email protected]>) <[email protected]<mailto:[email protected]>> Subject: PCE Applicability to ACTN Hi, I have written the draft version for this document. Please provide comments or directly make changes in the xml/txt. Please forward to anyone else who you think can help... Thanks! Regards, Dhruv
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
