Hi Aijun, As a contributor to this I-D and a WG participant, let me jump in and snip to ...
<snip> > 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. > > [WAJ] Not only the introduction part, but also the following procedures. It > is better to generalize the (section 5), not strictly limit within the LSP > path. > > [DD] I see that this has been updated based on Adrian's comment, this now reads - While this document is focused on the procedures for the static LSPs (referred to as basic PCECC mode in Section 3), the mechanism and protocol encoding are specified in such a way that, extensions for other use cases is easy to achieve. For example, the extensions for PCECC for Segment Routing (SR) are specified in [I-D.zhao-pce-pcep-extension-pce-controller-sr] and [I-D.dhody-pce-pcep-extension-pce-controller-srv6]. I disagree regarding the need to change section 5. In this I-D, we don't generalize but allow for an easy extension for new use cases. This document defines what needs to be done for CCI Object-Type=1, and allows other CCI Object-Types to be defined in other I-Ds later. There are cases where we can generalize when the extension can stand on its own, for example, a generic ASSOCIATION object, and have different association types. But we do not have a generic CCI object, we have CCI Object-Type=1 that needs to be specified in this context. This is similar to how PCEP for SR-MPLS exists on its own in RFC 8664 and later extended for SRv6 without a generic SR text. > > > > 3. Section-5.5.1of this draft 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. > > [WAJ] For the PCC-initiated SR path, only the headend need to be touched. It > is different from the scenario described in Figure 2. > > > [DD] It is different, but Shuping's response was based on your comment "But for LSP delegate mode, the LSP must exist beforehand..." and to highlight that the requirement for the LSP to exist beforehand is incorrect! One can send a PCReq message first to get the path and then delegate it. It is also allowed to delegate an LSP that has an empty ERO (down LSP). But in either case, there is no requirement for the LSP to be established in the data plane before the delegation. <snip> > 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. > > [WAJ] In such situation, we think the distributed only label allocation is > fine. The PCE should not intervene this process. Adding PCE in the network > should simplify the procedures, not make it complex. > > [DD] The capability of the PCC to allocate labels is something that already exists and by adding one flag in the protocol exchange one is able to allow both modes. This is not particularly complex IMHO :) Also, you should note that this is quite common in SR use cases such as binding and path segments where PCC allocated binding segment and path segment is supported. > > > > 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. > > [WAJ] Separate CCI instances requires the binding function on the devices. > How to avoid the problem when the CCI instances can’t be bound together? For > example, the PCE download two out label, no in label, or vice versa? > > [DD] I discussed this with Shuping and she has added explicit text to handle this now via error messages. The "binding" is in the PCInitiate message itself which includes the LSP object and then multiple CCI objects are included. Thanks! Dhruv > > > > Best Regards, > > Shuping > > > > Best Regards > > > > Aijun Wang > > China Telecom > > > > > > > > > > -----Original Message----- > From: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] On Behalf Of > julien.meu...@orange.com > Sent: Thursday, August 6, 2020 12:19 AM > To: pce@ietf.org > 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 > > Pce@ietf.org > > https://www.ietf.org/mailman/listinfo/pce > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
