Re: [Pce] PCE WG LC for draft-ietf-pce-pcep-extension-for-pce-controller

[Dhruv Dhody <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of [e-mail]
> Sent: Thursday, August 6, 2020 12:19 AM
> To: [e-mail]
> 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
>
> [e-mail]
>
> https://www.ietf.org/mailman/listinfo/pce
>
> _______________________________________________
> Pce mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pce