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

[julien.meuric]

Dear WG,

This LC has ended. Some comments have been discussed on the list:
authors, please resolve them and publish a revised document accordingly.

Thanks,

Dhruv & Julien


On 05/08/2020 18:18, julien.meu...@orange.com wrote:
> 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
>




smime.p7s
Description: S/MIME Cryptographic Signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

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

[Siva Sivabalan]

Support this useful draft.

Thanks,
Siva

-Original Message-
From: Pce  On Behalf Of julien.meu...@orange.com
Sent: Wednesday, August 5, 2020 12:19 PM
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
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

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

[Luc-Fabrice Ndifor Ngwa [ MTN Cameroon ]]

Hi Julien,
I support the WG LC of the draft. Have no objection with the current status of 
the draft.


​Warm regards,
Luc-Fabrice

Ndifor
Specialist - IP Access and Data center
luc-fabrice.ndi...@mtn.com
T +237 677 55 02 13
Head Office: 360, Rue Drouot
​P.O. Box 15 574 Douala, Cameroon
T +237 679 00 90 90
 | mtn.cm
This email is confidential. If you have received it in error, you are on notice 
of its status. Please notify ​the ​​sender immediately by
​reply email and then delete this message from your system. Please do not copy 
it ​or use it for any purpose or disclose its content
​to any other person as to do so could be a breach of ​confidentiality.
​
 Please be informed that no employee or agent is authorized to conclude any 
legally binding agreement ​on behalf of MTN Cameroon
​via email. This can be only done if the email is confirmed explicitly in 
writing ​by an MTN Cameroon authorized officer. In no event
​will this email or its content be construed as a written ​approval.
-Original Message-
From: Pce  On Behalf Of julien.meu...@orange.com
Sent: Wednesday, August 5, 2020 5:19 PM
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

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

[Dhruv Dhody]

Hi Aijun,

As a contributor to this I-D and a WG participant, let me jump in and
snip to ...



> 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.



> 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?
>
>

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

[Pengshuping (Peng Shuping)]

Bravo! :)


Thank you, Adrian!


Best regards,

Shuping

发件人：Adrian Farrel 
收件人：Pengshuping (Peng Shuping) ;julien.meuric 
;pce 
抄 送：draft-ietf-pce-pcep-extension-for-pce-controller 

时 间：2020-08-18 19:25:23
主 题：RE: [Pce] PCE WG LC for draft-ietf-pce-pcep-extension-for-pce-controller

That's super-fast work, Shuping. Thanks.

I skimmed through the changes and checked the ones where I had asked
questions.

Everything looks good.

I can now fully support the last call.

Best,
Adrian

-Original Message-
From: Pengshuping (Peng Shuping) 
Sent: 18 August 2020 12:08
To: adr...@olddog.co.uk; julien.meu...@orange.com; pce@ietf.org
Cc: draft-ietf-pce-pcep-extension-for-pce-control...@ietf.org
Subject: RE: [Pce] PCE WG LC for
draft-ietf-pce-pcep-extension-for-pce-controller

Dear Adrian,

Many thanks for your detailed review and comments.

Please find the diff with our updates to the draft according to your
comments. Hope we have addressed them properly.

https://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=draft-ietf-pce-pcep-e
xtension-for-pce-controller-06=https://raw.githubusercontent.com/dhruvd
hody/ietf/master/draft-ietf-pce-pcep-extension-for-pce-controller-07.txt

We have also updated Chao Zhou's email address in the draft.

Thank you!

Best regards,
Shuping


> -Original Message-
> From: Adrian Farrel [mailto:adr...@olddog.co.uk]
> Sent: Monday, August 17, 2020 12:15 AM
> To: julien.meu...@orange.com; pce@ietf.org
> Cc: draft-ietf-pce-pcep-extension-for-pce-control...@ietf.org
> Subject: RE: [Pce] PCE WG LC for
> draft-ietf-pce-pcep-extension-for-pce-controller
>
> Hi Julien, WG, authors,
>
> I'm listed as one of the eight Contributors to this document, although my
> affiliation should read "Old Dog Consulting".
>
> I was a co-author of RFC 8283, so I am generally glad to see protocol work
> addressing this space.
>
> This document is almost ready to progress, but there are quite a few nits
> that we should take care of before asking to advance the document.
> After that's done, I support this document being published as an RFC.
>
> Thanks,
> Adrian
>
> ===
>
> Figures
>
> If you make the table in Section 5.2 into "Figure 1" then you will not
need to
> renumber Figure 2.
>
> All figures should have a caption such as you have for Figure 2.
>
> All figures should be mentioned explicitly in the text. Thus, instead of
saying
> "as shown below" you should say "as shown in Figure 2".  This is important
> because:
> - it helps the RFC Editor check that you are using all of the figures
> - it protects the text from edits that might move it around in relation
>   to the figure.
>
> ---
>
> Abstract
>
> s/(G)MPLS/MPLS and GMPLS/
> s/PCEP protocol extensions/PCEP extensions/
>
> ---
>
> Introduction
>
> s/draft specify/document specifies/
>
> ---
>
> Introduction
>
>The extension for PCECC in Segment Routing (SR) is specified in a
>separate draft [I-D.zhao-pce-pcep-extension-pce-controller-sr].
>
> This paragraph is, of course, completely true. But it is absolutely
unclear
> what it is doing here. There has been no previous discussion of SR in the
> document, and the only other mention of SR is in 5.5.9. I think we can
> probably do without this paragraph.
>
> ---
>
> 2.
>
> OLD
>Terminologies used in this document is same as described in the draft
>[RFC8283].
> NEW
>Terminology used in this document is that same as that described in
>[RFC8283].
> END
>
> ---
>
> 3.
>
> OLD
>it is assumed that label range to be used NEW
>it is assumed that the label range to be used END
>
> OLD
>A future extension could add this capability NEW
>A future extension could add the capability END
>
> OLD
>This document also allow a case where the label space is maintained
>by PCC itself
> NEW
>This document also allows a case where the label space is maintained
>by the PCC itself
> END
>
> ---
>
> 4.
>
> OLD
>Following key requirements associated PCECC should be considered
> when
>designing the PCECC based solution:
> NEW
>The following key requirements should be considered when
>designing the PCECC based solution:
> END
>
> ---
>
> 5.3
> s/This document specify/This document specifies/ s//new CCI
> object-type/new CCI object-types/
>
> ---
>
> 5.4
> s/During PCEP Initialization Phase/During the PCEP Initialization Phase/
> s/Path is setup/Path is set up/ s/sub-TLV in PCC's/sub-TLV in a PCC's/
s/PCE's
> OPEN message/a PCE's OPEN message/
>
> ---
>
> 5.4
>
>If the PCEP
>Speakers support the extensions of this draft but did not 

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

[Pengshuping (Peng Shuping)]

Dear Adrian, 

Many thanks for your detailed review and comments. 

Please find the diff with our updates to the draft according to your comments. 
Hope we have addressed them properly. 

https://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=draft-ietf-pce-pcep-extension-for-pce-controller-06=https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-pce-pcep-extension-for-pce-controller-07.txt

We have also updated Chao Zhou's email address in the draft. 

Thank you!

Best regards, 
Shuping


> -Original Message-
> From: Adrian Farrel [mailto:adr...@olddog.co.uk]
> Sent: Monday, August 17, 2020 12:15 AM
> To: julien.meu...@orange.com; pce@ietf.org
> Cc: draft-ietf-pce-pcep-extension-for-pce-control...@ietf.org
> Subject: RE: [Pce] PCE WG LC for
> draft-ietf-pce-pcep-extension-for-pce-controller
> 
> Hi Julien, WG, authors,
> 
> I'm listed as one of the eight Contributors to this document, although my
> affiliation should read "Old Dog Consulting".
> 
> I was a co-author of RFC 8283, so I am generally glad to see protocol work
> addressing this space.
> 
> This document is almost ready to progress, but there are quite a few nits
> that we should take care of before asking to advance the document.
> After that's done, I support this document being published as an RFC.
> 
> Thanks,
> Adrian
> 
> ===
> 
> Figures
> 
> If you make the table in Section 5.2 into "Figure 1" then you will not need to
> renumber Figure 2.
> 
> All figures should have a caption such as you have for Figure 2.
> 
> All figures should be mentioned explicitly in the text. Thus, instead of 
> saying
> "as shown below" you should say "as shown in Figure 2".  This is important
> because:
> - it helps the RFC Editor check that you are using all of the figures
> - it protects the text from edits that might move it around in relation
>   to the figure.
> 
> ---
> 
> Abstract
> 
> s/(G)MPLS/MPLS and GMPLS/
> s/PCEP protocol extensions/PCEP extensions/
> 
> ---
> 
> Introduction
> 
> s/draft specify/document specifies/
> 
> ---
> 
> Introduction
> 
>The extension for PCECC in Segment Routing (SR) is specified in a
>separate draft [I-D.zhao-pce-pcep-extension-pce-controller-sr].
> 
> This paragraph is, of course, completely true. But it is absolutely unclear
> what it is doing here. There has been no previous discussion of SR in the
> document, and the only other mention of SR is in 5.5.9. I think we can
> probably do without this paragraph.
> 
> ---
> 
> 2.
> 
> OLD
>Terminologies used in this document is same as described in the draft
>[RFC8283].
> NEW
>Terminology used in this document is that same as that described in
>[RFC8283].
> END
> 
> ---
> 
> 3.
> 
> OLD
>it is assumed that label range to be used NEW
>it is assumed that the label range to be used END
> 
> OLD
>A future extension could add this capability NEW
>A future extension could add the capability END
> 
> OLD
>This document also allow a case where the label space is maintained
>by PCC itself
> NEW
>This document also allows a case where the label space is maintained
>by the PCC itself
> END
> 
> ---
> 
> 4.
> 
> OLD
>Following key requirements associated PCECC should be considered
> when
>designing the PCECC based solution:
> NEW
>The following key requirements should be considered when
>designing the PCECC based solution:
> END
> 
> ---
> 
> 5.3
> s/This document specify/This document specifies/ s//new CCI
> object-type/new CCI object-types/
> 
> ---
> 
> 5.4
> s/During PCEP Initialization Phase/During the PCEP Initialization Phase/
> s/Path is setup/Path is set up/ s/sub-TLV in PCC's/sub-TLV in a PCC's/ s/PCE's
> OPEN message/a PCE's OPEN message/
> 
> ---
> 
> 5.4
> 
>If the PCEP
>Speakers support the extensions of this draft but did not advertise
>this capability attempts a PCECC operation then a PCErr message with
>Error-Type=19(Invalid Operation) and Error-Value=TBD3 (Attempted
>PCECC operations when PCECC capability was not advertised) will be
>generated and the PCEP session will be terminated.
> 
> This is good. But you also need to include what happens if an
> implementation that does not understand these extensions receives one.
> I suspect you can do this with a reference to another document.
> 
> ---
> 
> There are a couple of cases of s/a LSP/an LSP/
> 
> ---
> 
> 5.5.1
> 
> s/based on PCECC mechanism/based on the PCECC mechanism/
> s/LSP-IDENTIFIER TLV MUST/An LSP-IDENT

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

[Aijun Wang]

Hi, Shuping:

 

Please see the responses inline, wish to see the update of the draft soon.

 

 

Best Regards

 

Aijun Wang

China Telecom

 

From: Pengshuping (Peng Shuping) [mailto:pengshup...@huawei.com] 
Sent: Friday, August 14, 2020 7:46 PM
To: Aijun Wang ; julien.meu...@orange.com;
pce@ietf.org
Subject: RE: [Pce] PCE WG LC for
draft-ietf-pce-pcep-extension-for-pce-controller

 

Hi Aijun, 

 

Thank you for your comments! Please find the responses in line below. 

 

From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Aijun Wang
Sent: Friday, August 14, 2020 5:42 PM
To: julien.meu...@orange.com <mailto:julien.meu...@orange.com> ;
pce@ietf.org <mailto:pce@ietf.org> 
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.

[WAJ] Not only the introduction part, but also the following procedures.  It
is better to generalize the (section 5
<https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-for-pce
-controller-06#section-5> ), not strictly limit within the LSP path. 

 

 

3. Section-5.5.1of this draft
<https://tools.ietf.org/html/draft-ietf-pce-pcep-extension-for-pce-controlle
r-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.

[WAJ] For the PCC-initiated SR path, only the headend need to be touched. It
is different from the scenario described in Figure 2.

 

 

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.

[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.

 

 

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?

 

 

Best Regards, 

Shuping

 

Best Regards

 

Aijun Wang

China Telecom

 

 

 

 

-Original Message-
From: pce-boun...@ietf.org <mailto:pce-boun...@ietf.org>
[mailto:pce-boun...@ietf.org] On Behalf Of julien.meu...@orange.com
<mailto:julien.meu...@orange.com> 
Sent: Thursday, August 6, 2020 12:19 AM
To: pce@ietf.org <mailto: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,

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

[Khasanov Boris]

Hi Dhruv and Julien,

I read the draft and support it along with PCECC work. It is important to 
define those extensions, the degree of details is good.  

SY,
Boris

-Original Message-
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of julien.meu...@orange.com
Sent: Wednesday, August 5, 2020 7:19 PM
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

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

[Adrian Farrel]

Hi Julien, WG, authors,

I'm listed as one of the eight Contributors to this document, although
my affiliation should read "Old Dog Consulting".

I was a co-author of RFC 8283, so I am generally glad to see protocol
work addressing this space.

This document is almost ready to progress, but there are quite a few
nits that we should take care of before asking to advance the document.
After that's done, I support this document being published as an RFC.

Thanks,
Adrian

===

Figures

If you make the table in Section 5.2 into "Figure 1" then you will not 
need to renumber Figure 2.

All figures should have a caption such as you have for Figure 2.

All figures should be mentioned explicitly in the text. Thus, instead of
saying "as shown below" you should say "as shown in Figure 2".  This is
important because:
- it helps the RFC Editor check that you are using all of the figures
- it protects the text from edits that might move it around in relation
  to the figure.

---

Abstract

s/(G)MPLS/MPLS and GMPLS/
s/PCEP protocol extensions/PCEP extensions/

---

Introduction

s/draft specify/document specifies/

---

Introduction

   The extension for PCECC in Segment Routing (SR) is specified in a
   separate draft [I-D.zhao-pce-pcep-extension-pce-controller-sr].

This paragraph is, of course, completely true. But it is absolutely
unclear what it is doing here. There has been no previous discussion of
SR in the document, and the only other mention of SR is in 5.5.9. I
think we can probably do without this paragraph.

---

2.

OLD
   Terminologies used in this document is same as described in the draft
   [RFC8283].
NEW
   Terminology used in this document is that same as that described in 
   [RFC8283].
END

---

3.

OLD
   it is assumed that label range to be used
NEW
   it is assumed that the label range to be used
END

OLD
   A future extension could add this capability
NEW
   A future extension could add the capability
END

OLD
   This document also allow a case where the label space is maintained
   by PCC itself
NEW
   This document also allows a case where the label space is maintained
   by the PCC itself
END

---

4.

OLD
   Following key requirements associated PCECC should be considered when
   designing the PCECC based solution:
NEW
   The following key requirements should be considered when
   designing the PCECC based solution:
END

---

5.3
s/This document specify/This document specifies/
s//new CCI object-type/new CCI object-types/

---

5.4
s/During PCEP Initialization Phase/During the PCEP Initialization Phase/
s/Path is setup/Path is set up/
s/sub-TLV in PCC's/sub-TLV in a PCC's/
s/PCE's OPEN message/a PCE's OPEN message/

---

5.4

   If the PCEP
   Speakers support the extensions of this draft but did not advertise
   this capability attempts a PCECC operation then a PCErr message with
   Error-Type=19(Invalid Operation) and Error-Value=TBD3 (Attempted
   PCECC operations when PCECC capability was not advertised) will be
   generated and the PCEP session will be terminated.

This is good. But you also need to include what happens if an
implementation that does not understand these extensions receives one.
I suspect you can do this with a reference to another document.

---

There are a couple of cases of s/a LSP/an LSP/

---

5.5.1

s/based on PCECC mechanism/based on the PCECC mechanism/
s/LSP-IDENTIFIER TLV MUST/An LSP-IDENTIFIER TLV MUST/
s/with D flags/with D flag/
s/and set up the/and sets up the/
s/include the central/includes the central/
s/The CC-ID is uniquely identify/The CC-ID uniquely identifies/
s/two CCI object/two CCI objects/
s/PCECC LSP is same as/PCECC LSP is the same as/
s/receives PCRpt message/receives a PCRpt message/   (twice)
s/The PCECC LSP are/The PCECC LSPs are/
s/In case where/In the case where/
s/label allocation are/label allocations are/
s/Similarly C bit/Similarly the C bit/

---

5.5.1

You have:
   This PCUpd message is as per [RFC8231] SHOULD include the path
   information as calculated by the PCE.

I think that you are not defining anything new here. You are just
describing what 8231 already says. So how about...

   Per [RFC8231], this PCUpd message should include the path
   information calculated by the PCE.

---

5.5.1

   The Ingress MAY further choose to deploy a
   data plane check mechanism and report the status back to the PCE via
   PCRpt message.

This is fine, but you should probably add some explanation of why an
Ingress might choose to do this.

---

5.5.1

   It should be noted that in this example, the request is made to the
   egress node with C bit set in the CCI object to indicate that the
   label allocation needs to be done by the egress and it responds with
   the allocated label to the PCE.

This is a little ambiguous. "...it responds" - what is it?
Perhaps you should have:
"...done by the egress, and the egress responds..."

---

5.5.2.1

s/to setup an LSP based/to set up an LSP based/
s/included in LSP object/included in the LSP 

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

[Pengshuping (Peng Shuping)]

Hi Aijun,



Thank you for your comments! Please find the responses in line below.

From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Aijun Wang
Sent: Friday, August 14, 2020 5:42 PM
To: julien.meu...@orange.com; pce@ietf.org
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: pce-boun...@ietf.org<mailto:pce-boun...@ietf.org> 
[mailto:pce-boun...@ietf.org] On Behalf Of 
julien.meu...@orange.com<mailto:julien.meu...@orange.com>
Sent: Thursday, August 6, 2020 12:19 AM
To: pce@ietf.org<mailto: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.



___

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

[duzongp...@foxmail.com]

Hi all,
 
I support the adoption.  The mechanism supports a convenient communication 
between the PCE and PCCs. 
 
Best Regards
Zongpeng Du



duzongp...@foxmail.com & duzongp...@chinamobile.com
 
From: julien.meu...@orange.com
Date: 2020-08-06 00:18
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

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

[Aijun Wang]

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."

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.

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?

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.

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?

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?

 

 

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

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

[Peng Liu]

Support.




Regards,

Peng Liu








Peng Liu | 刘鹏

China Mobile | 移动研究院

mobile phone：13810146105

email:  liupeng...@chinamobile.com

 



发件人: julien.meuric

时间: 2020/08/06(星期四)00:18

收件人: pce;

主题: [Pce] PCE WG LC for draft-ietf-pce-pcep-extension-for-pce-controllerHi 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

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

[lic...@chinatelecom.cn]

Support.

Best Regards,
Cong Li

From: julien.meu...@orange.com
Date: 2020-08-06 00:18
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

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

[Zhuangshunwan]

Support.

Best Regards,
Shunwan

-Original Message-
From: Pce [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

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

[Huaimo Chen]

Support.

Best Regards,
Huaimo

From: Pce  on behalf of julien.meu...@orange.com 

Sent: Wednesday, August 5, 2020 12:18 PM
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