Hi Aijun,
Thank you for your comments! Please find the responses in line below. From: Pce [mailto:[email protected]] On Behalf Of Aijun Wang Sent: Friday, August 14, 2020 5:42 PM To: [email protected]; [email protected] Subject: Re: [Pce] PCE WG LC for draft-ietf-pce-pcep-extension-for-pce-controller Hi，Dhruv, Julien and authors of this draft: I reviewed this draft and had the following comments for its WG LC: 1. Generally speaking, I support the direction that stated also in the draft as "A PCE-based central controller (PCECC) can simplify the processing of a distributed control plane by blending it with elements of SDN and without necessarily completely replacing it." [Shuping] Thank you for your support. 2. This draft states it focuses on LSP Path central control, but I think the procedures described in this draft is common to other CCI object(which may be defined in other documents). So would it be better to generalize the procedures? The specific part for other path type may be only the CCI objects. This can facilitate the extension of PCECC procedure in other scenario. [Shuping] Yes, you are right. We can add some text in the introduction to make it clear that though this document focuses on the basic PCECC LSP mode for the static LSPs, the procedures defined are generic enough to be used by other PCECC extensions. 3. Section-5.5.1of this draft<https://tools.ietf.org/html/draft-ietf-pce-pcep-extension-for-pce-controller-06#section-5.5.1> describes the “Basic PCECC LSP Setup”, which is based on the LSP delegation mode. But for LSP delegate mode, the LSP must exist beforehand, which is constructed via the distributed protocol(RSVP etc.). In such scenario, is it necessary to allocate the Label via the PCE? [Shuping] This is similar to the case for RFC 8664 where a PCC-initiated SR path is delegated to the PCE. It is not mandatory for the path (label-stack) to be "constructed" beforehand. 4. I think the most useful scenario for PCECC should be based on “PCE Initiate” message, which is used to initiate one new path from the PCE, together with the label allocation. [Shuping] I agree. 5. Similar consideration is for the “PCC allocation label”. What the reason to let the PCC allocate such label? Why can’t PCE allocate such information for each PCC from its appointed label space? [Shuping] It was suggested to be added because in some cases PCC may not be able to allocate a part of its label space for PCE to control and it would want to control the full label-space allocation. 6. For definition of CCI object, will it simplify the overall procedures if the CCI object for MPLS label includes both the IN and OUT label together? [Shuping] At the ingress, we would only have out-label, and at the egress, we would only have an in-label. In case of P2MP branch nodes, we would have one in-label and many out-labels as described in another I-D. For these reasons, we decided to have them as separate CCI instances. Best Regards, Shuping Best Regards Aijun Wang China Telecom -----Original Message----- From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of [email protected]<mailto:[email protected]> Sent: Thursday, August 6, 2020 12:19 AM To: [email protected]<mailto:[email protected]> Subject: [Pce] PCE WG LC for draft-ietf-pce-pcep-extension-for-pce-controller Hi all, This message initiates a 3-week WG Last Call on draft-ietf-pce-pcep-extension-for-pce-controller-06. Please review and share your feedback, whatever it is, using the PCE mailing list. This LC will end on Wednesday August 26, 11:59pm (any timezone). Please note that this I-D is related to draft-zhao-pce-pcep-extension-pce-controller-sr which is already in our WG adoption queue. Thanks, Dhruv & Julien _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ Pce mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/pce
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
