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

From: <[email-masked]>
Date: Wed, 5 Aug 2020 18:18:33 +0200

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.

---

From: Huaimo Chen <[email-masked]>
Date: Thu, 13 Aug 2020 15:15:36 +0000

Support.

Best Regards,
Huaimo
________________________________
From: Pce <[email-masked]> on behalf of [email-masked] <[email-masked]>
Sent: Wednesday, August 5, 2020 12:18 PM
To: [email-masked] <[email-masked]>
Subject: [Pce] PCE WG LC for draft-ietf-pce-pcep-extension-for-pce-controller

Hi all,

Thanks,

Dhruv & Julien

_______________________________________________
Pce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pce

---

From: Zhuangshunwan <[email-masked]>
Date: Fri, 14 Aug 2020 01:46:37 +0000

Support.

Best Regards,
Shunwan

-----Original Message-----
From: Pce [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, August 6, 2020 12:19 AM
To: [email-masked]
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.

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 14 Aug 2020 13:51:39 +0800

Support.

Best Regards,
Cong Li

From: [email-masked]
Date: 2020-08-06 00:18
To: [email-masked]
Subject: [Pce] PCE WG LC for draft-ietf-pce-pcep-extension-for-pce-controller
Hi all,

 
Thanks,
 
Dhruv & Julien

---

From: "Aijun Wang" <[email-masked]>
Date: Fri, 14 Aug 2020 17:41:52 +0800

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

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: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Thursday, August 6, 2020 12:19 AM
To: [email-masked]
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.

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

 <mailto:[email-masked]> [email-masked]

 <https://www.ietf.org/mailman/listinfo/pce>
https://www.ietf.org/mailman/listinfo/pce

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 14 Aug 2020 18:37:40 +0800

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

[email-masked] & [email-masked]

 
 
Thanks,
 
Dhruv & Julien

---

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Fri, 14 Aug 2020 11:46:11 +0000

Hi Aijun,

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

From: Pce [mailto:[email-masked]] On Behalf Of Aijun Wang
Sent: Friday, August 14, 2020 5:42 PM
To: [email-masked]; [email-masked]
Subject: Re: [Pce] PCE WG LC for draft-ietf-pce-pcep-extension-for-pce-controller

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

[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-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Thursday, August 6, 2020 12:19 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Pce] PCE WG LC for draft-ietf-pce-pcep-extension-for-pce-controller

Hi all,

Thanks,

Dhruv & Julien

Thank you.

Pce mailing list

[email-masked]<mailto:[email-masked]>

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 16 Aug 2020 17:14:40 +0100

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 object/   (twice)
s/New PCEP object/A new PCEP object/

---

5.5.2.2

   If the PCC receives a PCInitiate message but does not recognize the
   label in the CCI, the PCC MUST generate a PCErr message with Error-
   Type 19(Invalid operation) and Error-Value=TBD8, "Unknown Label" and
   MUST include the SRP object to specify the error is for the
   corresponding label cleanup (via PCInitiate message).

This is OK as a choice, but I wonder why you need to report this as an
error. The intention of the request is to make sure that the label in 
the CCI is removed from the PCC. If the label is not recognised, isn't
this the right result meaning that the answer should be a positive
response?

I'm not saying you must change this, but please consider it.

---

5.5.3

s/In order to setup/In order to set up/

OLD
   The
   PCC responds with first PCRpt message with the status as "GOING-UP"
   and assigned PLSP-ID.
NEW
   The
   PCC responds with a PCRpt message with the status set to "GOING-UP"
   and carrying the assigned PLSP-ID.
END

s/from PCECC are send/from PCECC are sent/
s/setup operations are/setup operations are the/
s/LSP is same as/LSP is the same as/
s/the PCE SHOULD send the/the PCE SHOULD send a/
s/In case where/In the case where/
s/label allocation are made/label allocations are made/

---

5.5.3

   In case where the label allocation are made by the PCC itself (see
   Section 5.5.8), the procedure remains similar.

Do you mean "remains similar" or "is the same"?
If it is only similar then you need to describe how it is different.

---

5.5.4                                                  `
s/modification of PCECC/modification of a PCECC/
s/In case where/In the case where/
s/label allocation are made/label allocations are made/

---

5.5.4

   In case where the label allocation are made by the PCC itself (see
   Section 5.5.8), the procedure remains similar.

Same question as 5.5.3

---

5.5.5

s/control over the/control over an/
s/In case of/In the case of a/

---

5.5.9

s/the PCE via PCRpt message as per/the PCE via a PCRpt message as per/

---

5.5.9

   The PCECC capability MUST be exchanged on the PCEP session, before
   PCE could allocate binding label.

Maybe turn this around to read...

   Before a PCE can allocate a binding label the PCECC capability MUST
   be exchanged on the PCEP session.

---

6.1

OLD
   the message has been extended as shown below
NEW
   this document extends the message as shown below
END

---

Either in 6.1 or in section 2, you should include something like

   The message formats in this document are specified using Routing
   Backus-Naur Form (RBNF) encoding as specified in [RFC5511].

And obviously add a reference to 5511.

---

6.1

c/At max two instances/At most two instances/

---

7.1

s/defines a new optional TLVs/defines new optional TLVs/

---

7.1.1

OLD
   No flags are assigned right now.
NEW
   No flags are defined in this document.
END

---

7.3

OLD
   Currently, the following flag bit is defined:
NEW
   Currently, the following flag bits are defined:
END

s/A PCE set this bit/A PCE sets this bit/

---

11.3

Can you add to the definition of this registry what the size is? I 
think there are 32 bits available.

---

11.4

I think the name of this section is wrong. you are not creating a new
registry in this section.

---

11.6

You should say how many bits this registry can track. I think it is 16.

---

11.7

It's not too important, but it might be nice to order this list by
increasing error type.

-----Original Message-----
From: Pce <[email-masked]> On Behalf Of [email-masked]
Sent: 05 August 2020 17:19
To: [email-masked]
Subject: [Pce] PCE WG LC for

Hi all,

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.

information that may be protected by law;

---

From: Lizhenbin <[email-masked]>
Date: Sun, 16 Aug 2020 23:27:29 +0000

Hi All,
I support the WG LC of the draft as the co-author. After years of work, the solution is mature and the draft is well written.

Best Regards,
Zhenbin (Robin)

From: [email-masked]<mailto:[email-masked]>
Date: 2020-08-06 00:18
To: [email-masked]<mailto:[email-masked]>
Subject: [Pce] PCE WG LC for draft-ietf-pce-pcep-extension-for-pce-controller
Hi all,

Thanks,

Dhruv & Julien

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.

---

From: Khasanov Boris <[email-masked]>
Date: Mon, 17 Aug 2020 06:50:50 +0000

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:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, August 5, 2020 7:19 PM
To: [email-masked]
Subject: [Pce] PCE WG LC for draft-ietf-pce-pcep-extension-for-pce-controller

Hi all,

Thanks,

Dhruv & Julien

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 18 Aug 2020 08:51:09 +0800

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:[email-masked]] 
Sent: Friday, August 14, 2020 7:46 PM
To: Aijun Wang <[email-masked]>; [email-masked];
[email-masked]
Subject: RE: [Pce] PCE WG LC for
draft-ietf-pce-pcep-extension-for-pce-controller

Hi Aijun, 

From: Pce [mailto:[email-masked]] On Behalf Of Aijun Wang
Sent: Friday, August 14, 2020 5:42 PM
To: [email-masked] <mailto:[email-masked]> ;
[email-masked] <mailto:[email-masked]> 
Subject: Re: [Pce] PCE WG LC for
draft-ietf-pce-pcep-extension-for-pce-controller

 

 

 

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

 

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

 

[Shuping] I agree.

 

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

 

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

[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: [email-masked] <mailto:[email-masked]>
[mailto:[email-masked]] On Behalf Of [email-masked]
<mailto:[email-masked]> 
Sent: Thursday, August 6, 2020 12:19 AM
To: [email-masked] <mailto:[email-masked]> 
Subject: [Pce] PCE WG LC for
draft-ietf-pce-pcep-extension-for-pce-controller

Hi all,

Thanks,

Dhruv & Julien

Thank you.

Pce mailing list

---

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Tue, 18 Aug 2020 11:07:54 +0000

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&url2=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

> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Monday, August 17, 2020 12:15 AM
> Cc: [email-masked]
> 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.
> If you make the table in Section 5.2 into "Figure 1" then you will not need to
> renumber 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:
> 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
>    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
> s/This document specify/This document specifies/ s//new CCI
> object-type/new CCI object-types/
> 
> ---
> 
> 5.4
> 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
> 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/label allocation are/label allocations are/ s/Similarly C bit/Similarly the C
> bit/
> 
> ---
> 
> 5.5.1
> 
> You have:
> I think that you are not defining anything new here. You are just describing
> what 8231 already says. So how about...
> 
> This is fine, but you should probably add some explanation of why an Ingress
> might choose to do this.
> 
> ---
> 
> 5.5.1
> 
> This is OK as a choice, but I wonder why you need to report this as an error.
> The intention of the request is to make sure that the label in the CCI is
> removed from the PCC. If the label is not recognised, isn't this the right result
> meaning that the answer should be a positive response?
> 
> s/from PCECC are send/from PCECC are sent/ s/setup operations are/setup
> operations are the/ s/LSP is same as/LSP is the same as/ s/the PCE SHOULD
> send the/the PCE SHOULD send a/ s/In case where/In the case where/
> s/modification of PCECC/modification of a PCECC/ s/In case where/In the
> case where/ s/label allocation are made/label allocations are made/
> 
> ---
> 
> 5.5.4
> 
>    the message has been extended as shown below NEW
>    this document extends the message as shown below END
> 
> ---
> 
> Can you add to the definition of this registry what the size is? I think there
> are 32 bits available.
> 
> ---
> 
> 11.4
> 
> I think the name of this section is wrong. you are not creating a new registry
> in this section.
> 
> ---
> 
> 11.6
> 
> It's not too important, but it might be nice to order this list by increasing
> error type.
> 
> 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.
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 18 Aug 2020 12:25:04 +0100

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) <[email-masked]> 
Sent: 18 August 2020 12:08
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Pce] PCE WG LC for

Dear Adrian, 

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&url2=https://raw.githubusercontent.com/dhruvd
hody/ietf/master/draft-ietf-pce-pcep-extension-for-pce-controller-07.txt

Thank you!

Best regards, 
Shuping

> If you make the table in Section 5.2 into "Figure 1" then you will not
need to
> All figures should be mentioned explicitly in the text. Thus, instead of
saying
> This paragraph is, of course, completely true. But it is absolutely
unclear
> I think that you are not defining anything new here. You are just
describing
> This is fine, but you should probably add some explanation of why an
Ingress
> This is OK as a choice, but I wonder why you need to report this as an
error.
> I think the name of this section is wrong. you are not creating a new
registry
> It's not too important, but it might be nice to order this list by
increasing
> draft-zhao-pce-pcep-extension-pce-controller-sr which is already in our WG
exploites
> If you have received this email in error, please notify the sender and
delete
> this message and its attachments.

---

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Tue, 18 Aug 2020 11:37:05 +0000

Bravo! :)

Thank you, Adrian!

Best regards,

Shuping

发件人：Adrian Farrel <[email-masked]>
收件人：Pengshuping (Peng Shuping) <[email-masked]>;julien.meuric <[email-masked]>;pce <[email-masked]>
抄 送：draft-ietf-pce-pcep-extension-for-pce-controller <[email-masked]>
时 间：2020-08-18 19:25:23
主 题：RE: [Pce] PCE WG LC for draft-ietf-pce-pcep-extension-for-pce-controller

Everything looks good.

Best,
Adrian

-----Original Message-----
From: Pengshuping (Peng Shuping) <[email-masked]>
Sent: 18 August 2020 12:08
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Pce] PCE WG LC for

Dear Adrian,

Thank you!

Best regards,
Shuping

need to
saying
unclear
describing
Ingress
error.
registry
increasing
exploites
delete

---

From: Dhruv Dhody <[email-masked]>
Date: Tue, 18 Aug 2020 17:10:59 +0530

Hi Aijun,

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

<snip>

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

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

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

> From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]

---

From: "Luc-Fabrice Ndifor Ngwa [ MTN Cameroon ]" <[email-masked]>
Date: Mon, 24 Aug 2020 05:07:38 +0000

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
[email-masked]
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 <[email-masked]> On Behalf Of [email-masked]
Sent: Wednesday, August 5, 2020 5:19 PM
To: [email-masked]
Subject: [Pce] PCE WG LC for draft-ietf-pce-pcep-extension-for-pce-controller

Hi all,

Thanks,

Dhruv & Julien

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Wed, 26 Aug 2020 12:38:59 +0000

Hi PCE,

This is a useful draft that defines the extensions of PCEP for PCECC. Hope this document can be published as an RFC in the future to guide implementation and deployment of PCECC. Therefore I support the WGLC of this document.

Thanks,
Cheng

-----邮件原件-----
发件人: Pce [mailto:[email-masked]] 代表 [email-masked]
发送时间: 2020年8月6日 0:19
收件人: [email-masked]
主题: [Pce] PCE WG LC for draft-ietf-pce-pcep-extension-for-pce-controller

Hi all,

Thanks,

Dhruv & Julien