Re: [Pce] Adoption Poll for draft-dhodylee-pce-pcep-ls

[Pengshuping (Peng Shuping)]

Hi Julien, 

I support the WG adoption of this work. It has been a long time since this work 
was started. It is an useful experiment. It would be good if the WG adopts it 
and progresses it further, especially helps with the IANA issues as Adrian 
pointed out. 

Thank you! 

Best Regards,
Shuping 


-Original Message-
From: Pce  On Behalf Of julien.meu...@orange.com
Sent: Friday, April 5, 2024 12:19 AM
To: pce@ietf.org
Subject: [Pce] Adoption Poll for draft-dhodylee-pce-pcep-ls

Hi all,

We have a long history around PCEP-LS. The rough consensus has been to progress 
it as experimental within the PCE WG, which makes more sense than an 
independent submission.
As a result, do you support draft-dhodylee-pce-pcep-ls-27 [1] to become a PCE 
WG document? Please share your feedback using the PCE mailing list, including 
your comments and especially your rationales in case you're opposed.

Thank you,

Julien

---
[1] https://datatracker.ietf.org/doc/draft-dhodylee-pce-pcep-ls/

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] IPR poll for draft-dhodylee-pce-pcep-ls

[Pengshuping (Peng Shuping)]

Hi Andrew,

- I am not aware of any IPR applicable to this draft that should be disclosed 
in accordance with IETF IPR rules

BR,
Shuping

From: Daniele Ceccarelli [mailto:daniele.i...@gmail.com]
Sent: Monday, April 8, 2024 3:33 PM
To: Andrew Stone (Nokia) 
Cc: Dhruv Dhody ; Pengshuping (Peng Shuping) 
; younglee...@gmail.com; Aijun Wang 
; gyan.s.mis...@verizon.com; ssiva...@ciena.com; 
udayasreere...@gmail.com; Sergio Belotti (Nokia) ; 
satish karunanithi ; Cheng Li ; 
pce@ietf.org; pce-cha...@ietf.org
Subject: Re: IPR poll for draft-dhodylee-pce-pcep-ls

Hi Andrew,

- I am not aware of any IPR applicable to this draft that should be disclosed 
in accordance with IETF IPR rules

Thanks
Daniele

Il Ven 5 Apr 2024, 17:14 Andrew Stone (Nokia) 
mailto:andrew.st...@nokia.com>> ha scritto:
Hi Authors,
In preparation for WG adoption on this draft, we'd like all authors and 
contributors to confirm on the list that they are in compliance with IETF IPR 
rules.
Please respond (copying the mailing list) to say one of:
- I am not aware of any IPR applicable to this draft that should be disclosed 
in accordance with IETF IPR rules.

- I am aware of the IPR applicable to this draft, and it has already been 
disclosed to the IETF.

- I am aware of IPR applicable to this draft, but that has not yet been 
disclosed to the IETF. I will work to ensure that it will be disclosed in a 
timely manner.

Thanks,
Andrew
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] IPR poll for draft-ietf-pce-segment-routing-policy-cp

[Pengshuping (Peng Shuping)]

Hi,

I am not aware of any IPR applicable to this draft that should be disclosed in 
accordance with IETF IPR rules.

Best Regards,
Shuping

From: Mike Koldychev (mkoldych) 
Sent: Tuesday, January 9, 2024 3:17 AM
To: Andrew Stone (Nokia) ; pce@ietf.org; 
draft-ietf-pce-segment-routing-policy...@ietf.org; Sivabalan, Siva 
; cba...@juniper.net; Pengshuping (Peng Shuping) 
; Hooman Bidgoli (Nokia) ; 
Dhruv Dhody ; Cheng Li ; Samuel Sidor 
(ssidor) 
Cc: pce-cha...@ietf.org
Subject: RE: IPR poll for draft-ietf-pce-segment-routing-policy-cp

I am not aware of any IPR applicable to this draft that should be disclosed in 
accordance with IETF IPR rules.

Thanks,
Mike.

From: Andrew Stone (Nokia) 
mailto:andrew.st...@nokia.com>>
Sent: Monday, January 8, 2024 1:28 PM
To: pce@ietf.org<mailto:pce@ietf.org>; 
draft-ietf-pce-segment-routing-policy...@ietf.org<mailto:draft-ietf-pce-segment-routing-policy...@ietf.org>;
 Mike Koldychev (mkoldych) mailto:mkold...@cisco.com>>; 
Sivabalan, Siva mailto:ssiva...@ciena.com>>; 
cba...@juniper.net<mailto:cba...@juniper.net>; 
pengshup...@huawei.com<mailto:pengshup...@huawei.com>; Hooman Bidgoli (Nokia) 
mailto:hooman.bidg...@nokia.com>>; Dhruv Dhody 
mailto:d...@dhruvdhody.com>>; 
chengl...@huawei.com<mailto:chengl...@huawei.com>; Samuel Sidor (ssidor) 
mailto:ssi...@cisco.com>>
Cc: pce-cha...@ietf.org<mailto:pce-cha...@ietf.org>
Subject: IPR poll for draft-ietf-pce-segment-routing-policy-cp

Hi Authors,

In preparation for WGLC on this draft, we'd like all authors and contributors 
to confirm on the list that they are in compliance with IETF IPR rules.

Please respond (copying the mailing list) to say one of:

- I am not aware of any IPR applicable to this draft that should be disclosed 
in accordance with IETF IPR rules.
- I am aware of the IPR applicable to this draft, and it has already been 
disclosed to the IETF.
- I am aware of IPR applicable to this draft, but that has not yet been 
disclosed to the IETF. I will work to ensure that it will be disclosed in a 
timely manner.

Thanks,
Andrew
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] FW: New Version Notification for draft-ietf-pce-pcep-extension-pce-controller-sr-08.txt

[Pengshuping (Peng Shuping)]

Hi all, 

We have updated this draft and believe that it is ready for the WGLC. 
Your further review are appreciated. Thank you! 

HTMLized: 
https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-pce-controller-sr
Diff: 
https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-pcep-extension-pce-controller-sr-08

Best Regards, 
Shuping 


-Original Message-
From: internet-dra...@ietf.org  
Sent: Tuesday, January 2, 2024 9:48 AM
To: Chao Zhou ; Mahendra Negi ; 
Mahendra Singh Negi ; Quintin Zhao 
; Pengshuping (Peng Shuping) 
; Lizhenbin 
Subject: New Version Notification for 
draft-ietf-pce-pcep-extension-pce-controller-sr-08.txt

A new version of Internet-Draft
draft-ietf-pce-pcep-extension-pce-controller-sr-08.txt has been successfully 
submitted by Shuping Peng and posted to the IETF repository.

Name: draft-ietf-pce-pcep-extension-pce-controller-sr
Revision: 08
Title:PCE Communication Protocol (PCEP) Extensions for Using PCE as a 
Central Controller (PCECC) for Segment Routing (SR) MPLS Segment Identifier 
(SID) Allocation and Distribution.
Date: 2024-01-01
Group:pce
Pages:34
URL:  
https://www.ietf.org/archive/id/draft-ietf-pce-pcep-extension-pce-controller-sr-08.txt
Status:   
https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-pce-controller-sr/
HTML: 
https://www.ietf.org/archive/id/draft-ietf-pce-pcep-extension-pce-controller-sr-08.html
HTMLized: 
https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-pce-controller-sr
Diff: 
https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-pcep-extension-pce-controller-sr-08

Abstract:

   The PCE is a core component of Software-Defined Networking (SDN)
   systems.

   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.  Thus, the Label
   Switched Path (LSP) can be calculated/set up/initiated and the label
   forwarding entries can also be downloaded through a centralized PCE
   server to each network device along the path while leveraging the
   existing PCE technologies as much as possible.

   This document specifies the procedures and PCE Communication Protocol
   (PCEP) extensions when a PCE-based controller is also responsible for
   configuring the forwarding actions on the routers, in addition to
   computing the paths for packet flows in a segment routing (SR)
   network and telling the edge routers what instructions to attach to
   packets as they enter the network.  PCECC as defined in RFC 9050 is
   further enhanced for SR-MPLS SID (Segment Identifier) allocation and
   distribution.



The IETF Secretariat


___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] IPR poll for draft-sidor-pce-circuit-style-pcep-extensions-05

[Pengshuping (Peng Shuping)]

Hi all，
- I am not aware of any IPR applicable to this draft that should be disclosed 
in accordance with IETF IPR rules.
Best Regards,
Shuping


From: Dhruv Dhody [mailto:d...@dhruvdhody.com]
Sent: Friday, December 1, 2023 6:40 PM
To: Samuel Sidor (ssidor) ; praveen.maheshw...@airtel.com; 
Stone, Andrew (Nokia - CA/Ottawa) ; 
luay.ja...@verizon.com; Pengshuping (Peng Shuping) 
Cc: pce@ietf.org
Subject: IPR poll for draft-sidor-pce-circuit-style-pcep-extensions-05

Hi Authors,

In preparation for WG adoption on this draft, we'd like all authors to confirm 
on the list that they are in compliance with IETF IPR rules.

Please respond (copying the mailing list) to say one of:

- I am not aware of any IPR applicable to this draft that should be disclosed 
in accordance with IETF IPR rules.
- I am aware of the IPR applicable to this draft, and it has already been 
disclosed to the IETF.
- I am aware of IPR applicable to this draft, but that has not yet been 
disclosed to the IETF. I will work to ensure that it will be disclosed in a 
timely manner.

Thanks,
Dhruv
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05

[Pengshuping (Peng Shuping)]

Hi,

I support the adoption of this work as a coauthor.

It provides the PCEP extensions for enabling the CS SR Policy currently being 
specified in SPRING.

Thank you!

Best Regards,
Shuping


From: Christian Schmutzer (cschmutz) [mailto:cschm...@cisco.com]
Sent: Thursday, December 14, 2023 5:58 AM
To: Dhruv Dhody 
Cc: Christian Schmutzer (cschmutz) ; pce@ietf.org; 
draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org
Subject: Re: [Pce] WG Adoption of 
draft-sidor-pce-circuit-style-pcep-extensions-05

I support the adoption of this draft as it defines the essential PCEP 
extensions need for the concepts described in draft-ietf-spring-cs-sr-policy.

regards
Christian


On 01.12.2023, at 05:32, Dhruv Dhody 
mailto:d...@dhruvdhody.com>> wrote:

Hi WG,

This email begins the WG adoption poll for 
draft-sidor-pce-circuit-style-pcep-extensions-05.

https://datatracker.ietf.org/doc/draft-sidor-pce-circuit-style-pcep-extensions/

Should this draft be adopted by the PCE WG? Please state your reasons - Why / 
Why not? What needs to be fixed before or after adoption? Are you willing to 
work on this draft? Review comments should be posted to the list.

Please respond by Friday 15th Dec 2023.

Please be more vocal during WG polls!

Thanks!
Dhruv & Julien
___
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] WG Adoption of draft-dhody-pce-pcep-extension-pce-controller-srv6

[Pengshuping (Peng Shuping)]

Hi Adrian, all, 

We have updated this draft and hoped that we have resolved your comments. Thank 
you! 
https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-pce-controller-srv6-01
 

Here is the diff for your convenience. 
https://author-tools.ietf.org/iddiff?url1=draft-ietf-pce-pcep-extension-pce-controller-srv6-00=draft-ietf-pce-pcep-extension-pce-controller-srv6-01=--html
 

Best Regards,
Shuping 


> -Original Message-
> From: Adrian Farrel [mailto:adr...@olddog.co.uk]
> Sent: Wednesday, January 18, 2023 4:20 AM
> To: pce@ietf.org
> Cc: julien.meu...@orange.com;
> draft-dhody-pce-pcep-extension-pce-controller-s...@ietf.org
> Subject: Re: [Pce] WG Adoption of
> draft-dhody-pce-pcep-extension-pce-controller-srv6
> 
> Hi,
> 
> Tl;dr  I support the adoption of this draft.
> 
> As a co-author of RFC 8283, I take an interest in this work and the wider
> applicability of PCECC. I've also been interested in how SID allocation is
> coordinated, and this seems like a reasonable solution.
> 
> Given that we have procedures and protocol extensions for PCECC with
> SR-MPLS, it seems pragmatic to also have them for SRv6.
> 
> Some comments and nits below, none of which needs to be actioned before
> adoption.
> 
> Best,
> Adrian
> 
> ===
> 
> Abstract
> 
> Suggest a paragraph break before "This document"
> 
> ---
> 
> Abstract
> 
> You nicely introduce PCE and PCECC, but don't introduce SR. There is,
> perhaps, a sentence or two in the Introduction you could borrow...
> 
> 
>Segment Routing (SR) technology leverages the source routing and
>tunneling paradigms.  Each path is specified as a set of "segments"
>encoded in the header of each packet as a list of Segment Identifiers
>(SIDs).
> 
> You'd then tidy up the subsequent text since there is no need to expand the
> abbreviations twice.
> 
> ---
> 
> Abstract
> 
> s/SDN and/SDN/
> s/in the for /in the/
> 
> ---
> 
> 1.
> 
> Although PCEP is expanded in the Abstract, you need to expand it on first use
> in the main body of text.
> 
> ---
> 
> 1.
> 
> s/introduction to SR/introduction to the SR/ a/[RFC8665] ,/[RFC8665],/
> 
> ---
> 
> 1.
> OLD
>[RFC8283] introduces the architecture for PCE as a central controller
> NEW
>[RFC8283] introduces the architecture for PCE as a central controller
>(PCECC)
> END
> 
> ---
> 
> 1.
> 
>It relies on a
>series of forwarding instructions being placed in the header of a
>packet.  The list of segments forming the path is called the Segment
>List and is encoded in the packet header.
> 
> You say "in the packet header" twice.
> 
> ---
> 
> 1.
> 
>PCECC may further use PCEP for SR SID (Segment Identifier) allocation
>and distribution to all the SR nodes with some benefits.
> 
> Hmmm. Not sure PCEP is use for allocation. Maybe it is open for
> interpretation, but possibly...
> 
>The PCECC may perform centralized allocation of SR Segment
>Identifiers (SIDs) and use PCEP to distribute them to the SR nodes.
> 
> ---
> 
> 1.
> 
>[I-D.ietf-pce-pcep-extension-pce-controller-sr] specifies the
>procedures and PCEP extensions when a PCE-based controller is also
>responsible for configuring the forwarding actions on the routers
>(SR-MPLS SID distribution), in addition to computing the paths for
>packet flows in a segment routing network and telling the edge
>routers what instructions to attach to packets as they enter the
>network.  This document extends this to include SRv6 SID distribution
>as well.
> 
> Big question first. I know the history that led us to have one I-D for SR-MPLS
> and one for SRv6. The question is whether we still need to have that, or we
> should adopt this document and them move for a merger so that the is just
> one draft for PCECC-SR. I assume that the philosophy of the PCEP extensions
> are the same, and that it is just the encoding of SIDs that differs. (See also
> the end of Section 3.)
> 
> And then, a rewrite for clarity...
> 
>A PCE-based central controller may be responsible for computing the
>paths for packet flows in an MPLS Segment Routing (SR-MPLS) network
>and for telling the edge routers what instructions to attach to
>packets as they enter the network.  [I-D.ietf-pce-pcep-extension-pce-
>controller-sr] specifies the procedures and PCEP extensions when a
>PCE-based controller is additionally responsible for configuring the
>forwarding actions on routers in an SR-MPLS network (i.e., for SR-
>MPLS SID distribution).  This document extends those procedures to
>include SRv6 SID distribution as well.
> 
> ---
> 
> 2.
> 
> s/in the document/in/
> 
> ---
> 
> 3.
> 
>An
>ingress node of an SR-TE path appends all outgoing packets with a
>list of MPLS labels (SIDs).
> 
> I don't think "append" is quite the right word. It has implications of "attach
> to the end of". Perhaps...
> 
>An
>ingress node of an SR-TE path includes a list of MPLS labels (SIDs)

[Pce] FW: New Version Notification for draft-peng-pce-stateful-pce-autobw-update-00.txt

[Pengshuping (Peng Shuping)]

Hi folks, 

We have submitted this new draft, which introduces the capability to explicitly 
remove an attribute identified by an sub-TLV of the AUTO-BANDWIDTH-ATTRIBUTES 
TLV. Your review and comments are very welcomed. Thank you! 

Best Regards, 
Shuping 


> -Original Message-
> From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
> Sent: Monday, July 3, 2023 6:57 PM
> To: Dhruv Dhody ; Rakesh Gandhi
> ; Pengshuping (Peng Shuping)
> 
> Subject: New Version Notification for
> draft-peng-pce-stateful-pce-autobw-update-00.txt
> 
> 
> A new version of I-D, draft-peng-pce-stateful-pce-autobw-update-00.txt
> has been successfully submitted by Dhruv Dhody and posted to the IETF
> repository.
> 
> Name: draft-peng-pce-stateful-pce-autobw-update
> Revision: 00
> Title:Update to Automatic Bandwidth Adjustment procedure of
> Stateful PCE
> Document date:2023-07-03
> Group:Individual Submission
> Pages:8
> URL:
> https://www.ietf.org/archive/id/draft-peng-pce-stateful-pce-autobw-updat
> e-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-peng-pce-stateful-pce-autobw-updat
> e/
> Html:
> https://www.ietf.org/archive/id/draft-peng-pce-stateful-pce-autobw-updat
> e-00.html
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-peng-pce-stateful-pce-autobw-u
> pdate
> 
> 
> Abstract:
>Extensions to the Path Computation Element Communication Protocol
>(PCEP) for MPLS-TE Label Switched Path (LSP) Automatic Bandwidth
>Adjustments with Stateful PCE are defined in RFC 8733.  It defines
>the AUTO-BANDWIDTH-ATTRIBUTES TLV and a set of sub-TLVs for each
> of
>the attributes.  The sub-TLVs are included if there is a change since
>the last information sent in the PCEP message.  But it lacks a
>mechanism to explicitly remove an attribute identified by the sub-
>TLV.
> 
>This document updates RFC 8733 by defining the behaviour.
> 
> 
> 
> 
> The IETF Secretariat
> 
> 

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WGLC for draft-ietf-pce-pcep-extension-native-ip-20

[Pengshuping (Peng Shuping)]

Hi,

I read through the document and I think that it is ready for WGLC.
I support the WGLC.

Best Regards,
Shuping

From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Dhruv Dhody
Sent: Tuesday, May 16, 2023 11:16 PM
To: pce@ietf.org
Cc: pce-chairs ; 
draft-ietf-pce-pcep-extension-native...@ietf.org
Subject: [Pce] WGLC for draft-ietf-pce-pcep-extension-native-ip-20

Hi WG,

This email starts a 2-weeks working group last call for 
draft-ietf-pce-pcep-extension-native-ip-20 [1].

Please indicate your support or concern for this draft. If you are opposed to 
the progression of the draft to RFC, please articulate your concern. If you 
support it, please indicate that you have read the latest version and it is 
ready for publication in your opinion. As always, review comments and nits are 
most welcome.

The WG LC will end on Wednesday 31st May 2023. We will also notify the IDR WG 
about this WGLC.

A general reminder to the WG to be more vocal during the last-call/adoption and 
help us unclog our queues :)

Thanks,
Dhruv & Julien

[1] https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WG Last Call for draft-ietf-pce-segment-routing-ipv6-15

[Pengshuping (Peng Shuping)]

Hi all, 

The work is mature enough to move forward. Therefore, I support the WG LC of 
this work. 

Best Regards, 
Shuping 

> -Original Message-
> From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of
> julien.meu...@orange.com
> Sent: Tuesday, February 14, 2023 1:39 AM
> To: pce@ietf.org
> Subject: [Pce] WG Last Call for draft-ietf-pce-segment-routing-ipv6-15
> 
> Dear PCE WG,
> 
> This message starts a 2-week WG last call on
> draft-ietf-pce-segment-routing-ipv6-15 [1]. Please, be express any
> comments you have about this document using the PCE mailing list.
> 
> This WGLC will end on Tuesday 28th February 2023.
> 
> Thanks,
> 
> Julien
> 
> --
> [1] https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-ipv6/

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] IETF WG state changed for draft-dhody-pce-pcep-extension-pce-controller-srv6

[Pengshuping (Peng Shuping)]

Dear Julien,

Many thanks for all the work! We will submit this draft shortly. 

Thank you!

Best Regards, 
Shuping

> -Original Message-
> From: julien.meu...@orange.com [mailto:julien.meu...@orange.com]
> Sent: Wednesday, February 8, 2023 9:09 PM
> To: draft-dhody-pce-pcep-extension-pce-controller-s...@ietf.org
> Cc: pce@ietf.org
> Subject: Re: IETF WG state changed for
> draft-dhody-pce-pcep-extension-pce-controller-srv6
> 
> Dear authors of draft-dhody-pce-pcep-extension-pce-controller-srv6,
> 
> You may now submit the same I-D under the name
> draft-ietf-pce-pcep-extension-pce-controller-srv6-00.
> 
> Thanks,
> 
> Julien
> 
> 
> On 08/02/2023 14:05, IETF Secretariat wrote:
> > The IETF WG state of
> > draft-dhody-pce-pcep-extension-pce-controller-srv6 has been changed to
> > "Adopted by a WG" from "Call For Adoption By WG Issued" by Julien
> Meuric:
> >
> > https://datatracker.ietf.org/doc/draft-dhody-pce-pcep-extension-pce-co
> > ntroller-srv6/
> >
> >
> 
> 
> __
> ___
> 
> 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

Re: [Pce] IPR Poll on draft-dhody-pce-pcep-extension-pce-controller-srv6

[Pengshuping (Peng Shuping)]

Hi Hari,


I am not aware of any IPR applicable to this draft that should be disclosed
in accordance with IETF IPR rules.

Thank you!

Best Regards,
Shuping

From: Hariharan Ananthakrishnan [mailto:h...@netflix.com]
Sent: Tuesday, January 17, 2023 12:23 PM
To: Pengshuping (Peng Shuping) ; Gengxuesong (Geng 
Xuesong) ; Mahend Negi ; 
Lizhenbin 
Cc: pce@ietf.org
Subject: IPR Poll on draft-dhody-pce-pcep-extension-pce-controller-srv6


Hi Authors,

In preparation for WG adoption on this draft, I'd like all

authors and contributors to confirm on the list that they are in compliance

with IETF IPR rules.

Please respond (copying the mailing list) to say one of:

I am not aware of any IPR applicable to this draft that should be disclosed

in accordance with IETF IPR rules.



I am aware of the IPR applicable to this draft, and it has already been

disclosed to the IETF.



I am aware of IPR applicable to this draft, but that has not yet been

disclosed to the IETF. I will work to ensure that it will be disclosed in a

timely manner.



Thanks,

- Hari
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WG Adoption of draft-dhody-pce-pcep-extension-pce-controller-srv6

[Pengshuping (Peng Shuping)]

Hi, 

Thanks to the Chairs for starting this call. 

This draft has been updated according to the feedback collected through email 
exchanges and presentations. 

As a co-author of this work, I support the WG adoption of it. 

Thank you! 

Best Regards, 
Shuping 


-Original Message-
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of julien.meu...@orange.com
Sent: Tuesday, January 17, 2023 2:00 AM
To: pce@ietf.org
Subject: [Pce] WG Adoption of draft-dhody-pce-pcep-extension-pce-controller-srv6

Hi all,

This e-mail starts an adoption poll for
draft-dhody-pce-pcep-extension-pce-controller-srv6-10 [1]. Do you consider this 
I-D is ready to become a PCE WG item?

Please respond to the PCE list, including rationale if you believe the WG 
should not adopt it.

Thanks,

Julien


[1]
https://datatracker.ietf.org/doc/draft-dhody-pce-pcep-extension-pce-controller-srv6/


___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] IPR Poll on draft-li-pce-pcep-srv6-yang-07

[Pengshuping (Peng Shuping)]

Hi,

I am not aware of any IPR applicable to this draft that should be disclosed
in accordance with IETF IPR rules.

Thank  you!

Best Regards,
Shuping


From: Hariharan Ananthakrishnan [mailto:h...@netflix.com]
Sent: Saturday, September 3, 2022 12:04 PM
To: luc-fabrice.ndi...@mtn.com; ssiva...@ciena.com; Chengli ; 
Mike Koldychev (mkoldych) ; Pengshuping (Peng Shuping) 

Cc: pce@ietf.org
Subject: IPR Poll on draft-li-pce-pcep-srv6-yang-07


Hi Authors,

In preparation for WG adoption on this draft, I'd like all

authors and contributors to confirm on the list that they are in compliance

with IETF IPR rules.

Please respond (copying the mailing list) to say one of:

I am not aware of any IPR applicable to this draft that should be disclosed

in accordance with IETF IPR rules.



I am aware of the IPR applicable to this draft, and it has already been

disclosed to the IETF.



I am aware of IPR applicable to this draft, but that has not yet been

disclosed to the IETF. I will work to ensure that it will be disclosed in a

timely manner.



Thanks,

- Hari
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WG Adoption of draft-li-pce-pcep-pmtu-05

[Pengshuping (Peng Shuping)]

Hi Gyan,

Thank you for your support and suggestions.

Since this draft is going to be refined considering the new draft being built 
in SPRING, the current uploaded draft is not changed accordingly.

Please find more responses in line below.

From: Gyan Mishra [mailto:hayabusa...@gmail.com]
Sent: Tuesday, March 29, 2022 12:24 PM
To: Dhruv Dhody 
Cc: draft-li-pce-pcep-p...@ietf.org; pce@ietf.org
Subject: Re: [Pce] WG Adoption of draft-li-pce-pcep-pmtu-05


Hi Dhruv

I reviewed the draft and support WG adoption.

Should this draft be adopted by the PCE WG?

Yes

Please state your reasons - Why / Why not?

This documents PCEP PMTU extension is valuable for any operator deployments of 
SR-MPLS or SRv6 and/or uses SR-TE and want to ensure that fragmentation does 
not occur along the stateful path instantiated.

What needs to be fixed before or after adoption?

The document well written and to the point and is ready for adoption

Are you willing to work on this draft?

Yes I would be happy to collaborate on the draft

Review comments should be posted to the list.

Few comments for the authors below:

It maybe worthwhile to mention PMTUD path MTU discovery which allows a TCP 
session to dynamically adjust the MSS for incoming and outgoing MSS.  As this 
document utilizes PMTU which is based on the PMTUD concept which is being 
carried in a new metric field in the PCEP report message I think for clarity it 
would.

BGP uses TCP and by default most all vendor implementations have PMTUD enabled 
by default on all BGP sessions.  Maybe worthwhile mentioning.

Shuping> This document just defines a new metric type for PCEP, I am not sure 
if we need to repeat the benefit of why MTU discovery is useful. And if 
something must be said than just a reference to existing RFC should suffice.


In the abstract I don’t understand this sentence.


Since the SR does not require signaling, the path maximum

transmission unit (MTU) information for SR path is not available.


Shuping> For RSVP-TE signaled paths we have mechanism in RSVP-TE signaling to 
get path-MTU. In SR we do not have this mechanism. The above text is 
highlighting this point.


I understand SR eliminates the control plane signaling for label distribution 
LDP which is now via IGP extension, but how does that make it so the SR MTU 
information is not available.  Directed LDP is for adjacency nodes or targeted 
LDP for session protection for non directly connected nodes.

RFC 5036 LDP does not support signaling for MTU.

RFC 7552 LDP updates for IPv6 also does not support signaling for MTU.

RFC 3988 is an experimental extension to support signaling for MTU.

I see RFC 3988 as a informational reference.

I think it would be good to mention what I stated above related to LDP not 
providing any signaling for MTU and RFC 3988 as its experimental and not 
standard track also not implemented by all vendors.

Shuping> PCE plays no role in LDP, you will not find any such information in 
any PCE document.


Section 3.5 mentions that path MTU adjustment can be made for primary or TI-LFA 
local protection path.

I would think this can be used for SR-TE protected path instantiated by 
stateful PCE but not for local protection.

Shuping> The text says that the overhead because of TI-LFA can still be 
calculated and adjusted.


Also would this draft be applicable to Non SR MPLS and GMPLS LDP signaling RFC 
3988 is experimental only so MPLS and GMPLS as well have a gap for MTU 
signaling.  I do see you stated in the introduction.  You may want to state the 
gap that exists as RFC 3988 is experimental and now this solution fills that 
gap as well.

Shuping> This can be used for other path setup types. But PCE plays no role in 
LDP and thus your comment does not apply.


Thank you!

Best Regards,
Shuping



Thanks

Gyan

On Mon, Mar 28, 2022 at 12:10 PM Dhruv Dhody 
mailto:d...@dhruvdhody.com>> wrote:
Hi WG,

This email begins the WG adoption poll for draft-li-pce-pcep-pmtu-05.

https://datatracker.ietf.org/doc/draft-li-pce-pcep-pmtu/

Should this draft be adopted by the PCE WG? Please state your reasons - Why / 
Why not? What needs to be fixed before or after adoption? Are you willing to 
work on this draft? Review comments should be posted to the list.

Please respond by Monday 11th April 2022.

Thanks!
Dhruv & Julien
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
--

[图像已被发件人删除。]

Gyan Mishra

Network Solutions Architect

Email gyan.s.mis...@verizon.com

M 301 502-1347

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WG Adoption of draft-li-pce-pcep-pmtu-05

[Pengshuping (Peng Shuping)]

Hi Andrew,

Thank you for your support and suggestions.

Since this draft is going to be refined considering the new draft being built 
in SPRING, the current uploaded draft is not changed accordingly.

Please find more responses in line below.

From: Stone, Andrew (Nokia - CA/Ottawa) [mailto:andrew.st...@nokia.com]
Sent: Friday, April 1, 2022 10:31 PM
To: Dhruv Dhody ; pce@ietf.org
Cc: draft-li-pce-pcep-p...@ietf.org
Subject: Re: [Pce] WG Adoption of draft-li-pce-pcep-pmtu-05

Hi PCE WG

Support adoption, seems reasonable to relay path MTU as status information and 
criteria/constraint in PCEP. A few comments/questions (these are non-blocking 
to adoption):


  1.  Shouldn’t the MTU bound use case be an inversion of the current 
description? Rather than specify a max mtu, wouldn't an operator prefer to find 
a path that satisfies a minimum MTU to avoid fragmentation? For example, if I 
have a requirement for X byte MTU along my path, then my bounds should indicate 
"please find a path that supports at minimum MTU value of X" ?   Similar to a 
bandwidth constraint?  This is the paragraph reference:

   Further, a PCC MAY use the Path MTU metric in a Path Computation
   Request (PCReq) message to request a path meeting the MTU requirement
   of the path.  In this case, the B bit MUST be set to suggest a bound
   (a maximum) for the Path MTU metric that must not be exceeded for the
   PCC to consider the computed path as acceptable.  The Path MTU metric
   must be less than or equal to the value specified in the metric-value
   field.

Shuping> You are correct that the PMTU metric is different from other metric 
types and thus we need to explain that in the document more clearly. We will 
work on an update for this.


  1.  Should the term optimize be defined in the below snippet? I assume the 
goal to find a path providing the largest MTU possible, so recommend some text 
describing what is the optimization goal when the goal is metric type MTU.

   A PCC can also use this metric to ask PCE to optimize the path MTU
   during path computation.  In this case, the B bit MUST be cleared.

Shuping> The objective of the optimization is to find the path with the largest 
PMTU. We will further work on the text to be updated in the draft.


  1.  Glad to see considerations for ietf-pce-multipath in the document. Since 
multipath document generically handles embedding other objects including METRIC 
(section 7.1 in draft-ietf-multipath), I would assume this metric would follow 
suit similar to existing metrics (ex TE-metric). Do the authors have potential 
other special use cases/needs involving the PMTU metric object per ERO?

Shuping> The multipath case will be further developed.


  1.  In section 3.3 it specifies " A PCC MAY include the path MTU metric as a 
bound constraint or to indicate optimization criteria (similar to PCReq)." I 
assume the intention here was to indicate that a PcRpt may carry the MTU metric 
as a constraint, so probably worth explicitly stating PcRpt may carry it rather 
than comparing to PcReq.



Shuping> In section 3.3 it can be changed to " A PCC MAY include the path MTU 
metric as a bound constraint or to indicate optimization criteria in PcRpt 
(similar to PCReq)."



  1.  The document makes a brief remark on the differentiation for MSD compared 
to PMTU. While correct, it’s likely worth remarking that for SR-MPLS the type 
of SIDs pushed onto the path would also have an impact to MTU in the path 
selection. For example, AdjSIDs being popped as the packet is in transit vs 
node SIDs remaining constant vs more complexity with BSIDs being used in the 
transit path could actually cause the packet size to grow while in mid-flight. 
Was there any consideration into the impact of this for PCE and or guidance for 
how PCE should be able to handle this ? I don’t have content to suggest but 
since there’s no discussion SR-MPLS segment type behavior makes me wonder if 
there might be a scenario or situation gap.



Shuping> Thank you for your suggestions. We will work on them and consider 
where to add the text.



Best Regards,

Shuping


Thanks
Andrew


From: Pce mailto:pce-boun...@ietf.org>> on behalf of 
Dhruv Dhody mailto:d...@dhruvdhody.com>>
Date: Monday, March 28, 2022 at 12:10 PM
To: "pce@ietf.org" mailto:pce@ietf.org>>
Cc: "draft-li-pce-pcep-p...@ietf.org" 
mailto:draft-li-pce-pcep-p...@ietf.org>>
Subject: [Pce] WG Adoption of draft-li-pce-pcep-pmtu-05

Hi WG,

This email begins the WG adoption poll for draft-li-pce-pcep-pmtu-05.

https://datatracker.ietf.org/doc/draft-li-pce-pcep-pmtu/

Should this draft be adopted by the PCE WG? Please state your reasons - Why / 
Why not? What needs to be fixed before or after adoption? Are you willing to 
work on this draft? Review comments should be posted to the list.

Please respond by Monday 11th April 2022.

Thanks!
Dhruv & Julien
___
Pce 

Re: [Pce] WG Adoption of draft-li-pce-pcep-pmtu-05

[Pengshuping (Peng Shuping)]

Hi Aijun,

Thank you for your suggestions.

Since this draft is going to be refined considering the new draft being built 
in SPRING, the current uploaded draft is not changed accordingly. Please find 
more responses in line below.

Best Regards,
Shuping

From: Aijun Wang [mailto:wangai...@tsinghua.org.cn]
Sent: Tuesday, March 29, 2022 10:37 AM
To: 'Dhruv Dhody' ; pce@ietf.org
Cc: draft-li-pce-pcep-p...@ietf.org
Subject: RE: [Pce] WG Adoption of draft-li-pce-pcep-pmtu-05

Hi, Dhruv:
I have read this document and support it adoption.
Some suggestions for the current contents are the followings:

1. The proposal in this draft is easy to understand, It is better to 
simplify the “Introduction” part.

Shuping> Yes, this part will be simplified.


2. There should be one section about “Procedures for the Path MTU 
calculation”, which can include the some contents in section 3.1, section 3.2, 
section 3.5

Shuping > Yes, this section is needed. We will consider where to put it.


3. Section 3.3 and 3.4 should be put in one independent section, such as 
“Application of the Path MTU Metric”?

Shuping >  We will consider this suggestion. Thank you!

Best Regards

Aijun Wang
China Telecom

From: pce-boun...@ietf.org 
mailto:pce-boun...@ietf.org>> On Behalf Of Dhruv Dhody
Sent: Tuesday, March 29, 2022 12:09 AM
To: pce@ietf.org
Cc: draft-li-pce-pcep-p...@ietf.org
Subject: [Pce] WG Adoption of draft-li-pce-pcep-pmtu-05

Hi WG,

This email begins the WG adoption poll for draft-li-pce-pcep-pmtu-05.

https://datatracker.ietf.org/doc/draft-li-pce-pcep-pmtu/

Should this draft be adopted by the PCE WG? Please state your reasons - Why / 
Why not? What needs to be fixed before or after adoption? Are you willing to 
work on this draft? Review comments should be posted to the list.

Please respond by Monday 11th April 2022.

Thanks!
Dhruv & Julien
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WG Adoption of draft-li-pce-pcep-pmtu-05

[Pengshuping (Peng Shuping)]

Hi Dhruv,

As an author of this draft, I would like to thank the Chairs of both WGs for 
the guidance. We will post the PCE document and start drafting the SPRING one.

Thank you!

Best Regards,
Shuping

From: Dhruv Dhody [mailto:d...@dhruvdhody.com]
Sent: Tuesday, May 3, 2022 11:17 AM
To: pce@ietf.org
Cc: draft-li-pce-pcep-p...@ietf.org; spring-cha...@ietf.org
Subject: Re: WG Adoption of draft-li-pce-pcep-pmtu-05

Hi WG,

Thanks for providing your feedback and discussion on the adoption of this draft.

The discussion on this thread as well as a chat with the SPRING chairs confirms 
the need for a document in the SPRING WG that can be referred to by the 
protocol extensions in PCE (and IDR). There is also no opposition to the actual 
protocol work in PCE.

Thus, the chairs conclude the adoption poll and adopt this I-D in the PCE WG. 
The chairs also ask the authors (and whoever is willing to contribute) to 
produce a document in the SPRING WG in parallel and continue the discussion on 
the SPRING mailing list. Post-adoption, the PCE document would need to remove 
any duplicate content and refer to the spring document instead.

Thanks!
Dhruv & Julien

On Mon, Mar 28, 2022 at 9:39 PM Dhruv Dhody 
mailto:d...@dhruvdhody.com>> wrote:
Hi WG,

This email begins the WG adoption poll for draft-li-pce-pcep-pmtu-05.

https://datatracker.ietf.org/doc/draft-li-pce-pcep-pmtu/

Should this draft be adopted by the PCE WG? Please state your reasons - Why / 
Why not? What needs to be fixed before or after adoption? Are you willing to 
work on this draft? Review comments should be posted to the list.

Please respond by Monday 11th April 2022.

Thanks!
Dhruv & Julien
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WG Adoption of draft-li-pce-pcep-pmtu-05

[Pengshuping (Peng Shuping)]

Hi Ketan,

Thank you for your comments. Regarding to your three points, please find our 
responses below.


1)  Are you referring to an architecture kind of draft on Path MTU? 
Including collection, calculation/comparison, selection, enforcement to the 
headend? We are open to have such draft but would like to get the guidance from 
the Chairs of these working groups whether it is needed since there have been 
several PMTU drafts adopted already in each WG. But we don’t think this should 
be taken as a reason to stop the adoption of this draft because it has all the 
information that needs to be adopted in the PCE WG.



2)  In PCEP, the METRIC object as per RFC5440 is used for both a) and b). 
In this draft, we defined a new type of METRIC object.


3)  Yes, this is applicable for both RSVP-TE and SR Policy.


Thank you!

Best Regards,
Shuping



From: Ketan Talaulikar [mailto:ketant.i...@gmail.com]
Sent: Monday, April 4, 2022 10:05 PM
To: Dhruv Dhody 
Cc: pce@ietf.org; draft-li-pce-pcep-p...@ietf.org
Subject: Re: [Pce] WG Adoption of draft-li-pce-pcep-pmtu-05

Hello,

I do not believe this document is ready for adoption. I believe the WG perhaps 
needs to discuss some basic concepts before taking up this work.

Please note that I do not object to (what I infer is) the motivation for this 
work. This document is not (yet) a good starting point for this work.

1) We need a SPRING WG document that covers the considerations related to Path 
MTU for SR Policies. We do not have such a document today. While this document 
does touch upon certain aspects, it is inadequate. This document should focus 
more on the PCEP protocol aspects and rely on the existing RSVP-TE spec RFC3209 
and TBD for SR Policy for the application to the respective constructs. Note 
that draft-ietf-idr-sr-policy-path-mtu introduces this PMTU for BGP SRTE [*]

2) There seems to be some degree of mixup between the concept of (a) constraint 
for the path and (b) the reporting of the calculated path MTU of the path. Both 
are perhaps needed, but we need them to be unambiguous and differentiated. I 
would think that (a) is also very useful. And I am not sure if it is 
appropriate to refer to (b) as a "metric" - isn't it a property?

3) This is applicable for both RSVP-TE and SR Policy.

[*] What I see is that some amount of uncoordinated protocol spec development 
related to SPRING constructs is happening in the protocol-specific WGs (PCE & 
IDR) without the base work being done in the SPRING WG. I had raised this point 
during the IDR document adoption as well: 
https://mailarchive.ietf.org/arch/msg/idr/ZrN1-Uw1ggyxKeltBICmcthjymM/

Thanks,
Ketan



On Mon, Mar 28, 2022 at 9:40 PM Dhruv Dhody 
mailto:d...@dhruvdhody.com>> wrote:
Hi WG,

This email begins the WG adoption poll for draft-li-pce-pcep-pmtu-05.

https://datatracker.ietf.org/doc/draft-li-pce-pcep-pmtu/

Should this draft be adopted by the PCE WG? Please state your reasons - Why / 
Why not? What needs to be fixed before or after adoption? Are you willing to 
work on this draft? Review comments should be posted to the list.

Please respond by Monday 11th April 2022.

Thanks!
Dhruv & Julien
___
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] IPR Poll for draft-li-pce-pcep-pmtu-05

[Pengshuping (Peng Shuping)]

Hi Hari,

I am not aware of any IPR applicable to this draft that should be disclosed
in accordance with IETF IPR rules.

Best Regards,
Shuping



From: Hariharan Ananthakrishnan [mailto:h...@netflix.com]
Sent: Tuesday, March 29, 2022 5:32 AM
To: Pengshuping (Peng Shuping) ; 
luc-fabrice.ndi...@mtn.com; Chengli (Cheng Li) ; 
hanliu...@chinamobile.com
Cc: pce@ietf.org
Subject: IPR Poll for draft-li-pce-pcep-pmtu-05


Hi Authors,

In preparation for WG adoption on this draft, I'd like all

authors and contributors to confirm on the list that they are in compliance

with IETF IPR rules.

Please respond (copying the mailing list) to say one of:

I am not aware of any IPR applicable to this draft that should be disclosed

in accordance with IETF IPR rules.



I am aware of the IPR applicable to this draft, and it has already been

disclosed to the IETF.



I am aware of IPR applicable to this draft, but that has not yet been

disclosed to the IETF. I will work to ensure that it will be disclosed in a

timely manner.



Thanks,

- Hari
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] IPR Poll for draft-tokar-pce-sid-algo

[Pengshuping (Peng Shuping)]

Hi,

I am not aware of any IPR applicable to this draft that should be disclosed in 
accordance with IETF rules.

Best Regards,
Shuping

From: Hariharan Ananthakrishnan [mailto:h...@netflix.com]
Sent: Saturday, February 5, 2022 1:58 AM
To: ssi...@cisco.com; peng.sha...@zte.com.cn; ato...@cisco.com; 
msiva...@gmail.com; Pengshuping (Peng Shuping) ; 
ts...@juniper.net; Mahend Negi 
Cc: pce@ietf.org
Subject: IPR Poll for draft-tokar-pce-sid-algo


Hi Authors,

In preparation for WG adoption on this draft, I'd like all

authors and contributors to confirm on the list that they are in compliance

with IETF IPR rules.

Please respond (copying the mailing list) to say one of:

I am not aware of any IPR applicable to this draft that should be disclosed

in accordance with IETF IPR rules.



I am aware of the IPR applicable to this draft, and it has already been

disclosed to the IETF.



I am aware of IPR applicable to this draft, but that has not yet been

disclosed to the IETF. I will work to ensure that it will be disclosed in a

timely manner.



Thanks,

- Hari
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Adoption of draft-litkowski-pce-state-sync

[Pengshuping (Peng Shuping)]

Hi WG,

I support the adoption of this work.

Best regards,
Shuping


> -Original Message-
> From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of
> julien.meu...@orange.com
> Sent: Monday, May 17, 2021 9:41 PM
> To: pce@ietf.org
> Subject: [Pce] Adoption of draft-litkowski-pce-state-sync
> 
> Dear all,
> 
> The document draft-litkowski-pce-state-sync has reached the head of our
> adoption queue
> (https://datatracker.ietf.org/doc/draft-litkowski-pce-state-sync/).
> 
> Do you consider this I-D is a good foundation for a WG item? Please share
> your feedback using the PCE mailing list by May 31.
> 
> Regards,
> 
> Dhruv & Julien
> 

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] IPR Poll on draft-koldychev-pce-multipath-05

[Pengshuping (Peng Shuping)]

I am not aware of any IPR applicable to this draft that should be disclosed
in accordance with IETF IPR rules.

Best regards,
Shuping




--
彭书萍 Peng Shuping
Mobile: +86-18210364128(优先)
Email: pengshup...@huawei.com<mailto:pengshup...@huawei.com>
发件人：Hariharan Ananthakrishnan 
收件人：Mike Koldychev (mkoldych) ;ssivabal 
;tsaad ;vbeeram 
;Bidgoli, Hooman (Nokia - CA/Ottawa) 
;byadav ;Pengshuping (Peng Shuping) 

抄 送：pce 
时 间：2021-04-19 21:35:03
主 题：IPR Poll on draft-koldychev-pce-multipath-05


Hi Authors,

In preparation for WG adoption on this draft, I'd like all
authors and contributors to confirm on the list that they are in compliance
with IETF IPR rules.

Please respond (copying the mailing list) to say one of:

I am not aware of any IPR applicable to this draft that should be disclosed
in accordance with IETF IPR rules.

I am aware of the IPR applicable to this draft, and it has already been
disclosed to the IETF.

I am aware of IPR applicable to this draft, but that has not yet been
disclosed to the IETF. I will work to ensure that it will be disclosed in a
timely manner.

Thanks,
- Hari
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WG Adoption of draft-koldychev-pce-multipath-05

[Pengshuping (Peng Shuping)]

Hi WG,

I support WG adoption of this draft since it is an important work that fills in 
the gap of multipath support in PCEP.

Thank you for your help on progressing this work!

Best regards,
Shuping

From: Dhruv Dhody [mailto:d...@dhruvdhody.com]
Sent: Wednesday, April 14, 2021 10:52 PM
To: pce@ietf.org
Cc: draft-koldychev-pce-multip...@ietf.org
Subject: WG Adoption of draft-koldychev-pce-multipath-05

Hi WG,

This email begins the WG adoption poll for draft-koldychev-pce-multipath-05.

https://datatracker.ietf.org/doc/html/draft-koldychev-pce-multipath-05

Should this draft be adopted by the PCE WG? Please state your reasons - Why / 
Why not? What needs to be fixed before or after adoption? Are you willing to 
work on this draft? Review comments should be posted to the list.

Please respond by Wednesday 28th April.

Thanks!
Dhruv & Julien
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Alvaro Retana's No Objection on draft-ietf-pce-pcep-extension-for-pce-controller-12: (with COMMENT)

[Pengshuping (Peng Shuping)]

Hi Alvaro,

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

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


> -Original Message-
> From: Alvaro Retana via Datatracker [mailto:nore...@ietf.org]
> Sent: Tuesday, February 23, 2021 2:28 AM
> To: The IESG 
> Cc: draft-ietf-pce-pcep-extension-for-pce-control...@ietf.org;
> pce-cha...@ietf.org; pce@ietf.org; Julien Meuric
> 
> Subject: Alvaro Retana's No Objection on
> draft-ietf-pce-pcep-extension-for-pce-controller-12: (with COMMENT)
> 
> Alvaro Retana has entered the following ballot position for
> draft-ietf-pce-pcep-extension-for-pce-controller-12: No Objection
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-for-pce-contr
> oller/
> 
> 
> 
> --
> COMMENT:
> --
> 
> (0) The fact that the procedures (§5) are presented before introducing the
> messages/objects (§6-7) makes reading this document harder and more
> complex than it has to be.  Consider changing the order or at least adding
> forward references in §5.

Forward references are added.

> 
> (1) §5.2:  Is there a reason for the messages from rfc8231 to be in
> parenthesis?

No, removed parenthesis!

> 
> (2) §5.4:
> 
>The PCECC-CAPABILITY sub-TLV SHOULD NOT be used without the
>corresponding Path Setup Type being listed in the PATH-SETUP-TYPE-
>CAPABILITY TLV.  If it is present without the corresponding Path
>Setup Type listed in the PATH-SETUP-TYPE-CAPABILITY TLV, it MUST be
>ignored.
> 
> When is it ok to use the PCECC-CAPABILITY sub-TLV without the
> corresponding PST?  If the result is that it will be ignored, then I don't
> understand why the use of both is not required.

Changed to MUST NOT

> 
> (3) §5.5.1/§5.5.4: "ingress MAY further choose to deploy a data plane check
> mechanism and report the status back to the PCE"  Is this (checking and
> reporting) specified somewhere?  Because you're using normative language,
> please add a reference.
> 
> A similar statement is made in §5.5.7: "ingress PCC MAY choose to apply any
> OAM mechanism to check the status of LSP in the Data plane and MAY
> further send its status in a PCRpt message to the PCE".

Removed the normative language and added "The exact mechanism is out of scope 
of this document."!

> 
> (4) §5.5.3: s/central controller instructions...is done/central controller
> instructions...are done

Updated

> 
> (5) §5.5.8: "The PCC SHOULD allocate the Label and SHOULD report to the
> PCE
> using the PCRpt message."   When is it ok for the PCC to not allocate
> and/or
> report?  IOW, why are these actions only recommended and not required?
> Note that the very next paragraph requires the behavior.

Updated to "The PCC MUST try to allocate the Label and MUST report to the PCE 
via PCRpt or PCErr message."

> 
> (6) §7.3/§7.3.1:  In the out-label case, "it is mandatory to encode the
> next-hop information".  Should this information point at a directly
> connected IP address/interface, or can it point at a remote next-hop (which
> may be resolved through a routing protocol)?  What if the expected
> conditions are not met?


I propose to add this text - 

"The next-hop information encoded in the Address TLVs needs to be a directly 
connected IP address/interface information. If the PCC is not able to resolve 
the next-hop information, it MUST reject the CCI and respond with a PCErr 
message with Error-Type = TBD5 ("PCECC failure") and Error
Value = TBD18 ("Invalid next-hop information")."

> 
> 
Best regards, 
Shuping 
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Éric Vyncke's Discuss on draft-ietf-pce-pcep-extension-for-pce-controller-12: (with DISCUSS and COMMENT)

[Pengshuping (Peng Shuping)]

Hi Erik, 

Thank you for your comments! Please find the diff including the updates based 
on your comments. Thank you!

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

Best regards, 
Shuping 



-Original Message-
From: Erik Kline [mailto:ek.i...@gmail.com] 
Sent: Thursday, February 25, 2021 11:57 PM
To: Dhruv Dhody 
Cc: Éric Vyncke ; Julien Meuric ; 
pce@ietf.org; The IESG ; pce-chairs ; 
draft-ietf-pce-pcep-extension-for-pce-control...@ietf.org
Subject: Re: Éric Vyncke's Discuss on 
draft-ietf-pce-pcep-extension-for-pce-controller-12: (with DISCUSS and COMMENT)

Dhruv,

Thanks for this.

>From my previous review, for reference only:

"""
* Saying that the LINKLOCAL-IPV6-ID-ADDRESS TLV holds a pair of global IPv6
  addresses seems confusing to me.

  If the pair of global IPv6 addresses is to be considered "on link" in the
  sense that IPv6 ND can be successfully be performed on the link for both
  of these addresses, then "ONLINK" might be better than LINKLOCAL.

* Also, why are two interface IDs required?  I would have expected that only
  the outgoing interface name/ID would be of relevance to the recipient of
  a message with TLV in it?
"""

Just for your consideration, in case "ONLINK" seems like it might be useful 
naming.

One more thing of note: I am terrible at naming!

On Thu, Feb 25, 2021 at 7:46 AM Dhruv Dhody  wrote:
>
> Hi Eric,
>
> I discussed this offline with one of the authors, who confirmed that 
> while NAI in RFC 8664 uses a pair, in this case, the pair is not 
> needed for the next-hop information and it can be updated as suggested 
> by you.
>
> Thanks!
> Dhruv
>
> On Thu, Feb 25, 2021 at 8:50 PM Dhruv Dhody  wrote:
> >
> > Hi Eric,
> >
> > On Thu, Feb 25, 2021 at 8:35 PM Éric Vyncke via Datatracker 
> >  wrote:
> > >
> > > Éric Vyncke has entered the following ballot position for
> > > draft-ietf-pce-pcep-extension-for-pce-controller-12: Discuss
> > >
> > > When responding, please keep the subject line intact and reply to 
> > > all email addresses included in the To and CC lines. (Feel free to 
> > > cut this introductory paragraph, however.)
> > >
> > >
> > > Please refer to 
> > > https://www.ietf.org/iesg/statement/discuss-criteria.html
> > > for more information about IESG DISCUSS and COMMENT positions.
> > >
> > >
> > > The document, along with other ballot positions, can be found here:
> > > https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-for
> > > -pce-controller/
> > >
> > >
> > >
> > > --
> > > 
> > > DISCUSS:
> > > --
> > > 
> > >
> > > Thank you for the work put into this document. I have not had time 
> > > to review in details though :( but I appreciated the detailed 
> > > description as well as the useful time diagrams.
> > >
> > > Please find below one blocking DISCUSS point (which may be my bad 
> > > understanding), some non-blocking COMMENT points (but replies 
> > > would be appreciated).
> > >
> > > I hope that this helps to improve the document,
> > >
> > > Regards,
> > >
> > > -éric
> > >
> > > == DISCUSS ==
> > >
> > > -- Section 7.3.1 --
> > > LINKLOCAL-IPV6-ID-ADDRESS TLV: I fail to understand why there are 
> > > two addresses in this TLV while others have one one ? Also is 
> > > 'local' and 'remote' really global addresses ?
> > >
> > >
> >
> > Erik Kline had the same comment.
> >
> > The text and encoding is inspired by RFC 8664
> > https://www.rfc-editor.org/rfc/rfc8664.html#section-4.3.2
> >
> > which says -
> >
> > IPv6 Link-Local Adjacency:
> > Specified as a pair of (global IPv6 address, interface ID) tuples. 
> > It is used to describe an IPv6 adjacency for a link that uses only 
> > link-local IPv6 addresses. Each global IPv6 address is configured on 
> > a specific router, so together they identify a pair of adjacent routers.
> > The interface IDs identify the link that the adjacency is formed over.
> >
> > A reference to RFC8664 and more description can be added.
> >
> > Thanks!
> > Dhruv
> >
> > > --
> > > 
> > > COMMENT:
> > > --
> > > 
> > >
> > > == COMMENTS ==
> > >
> > > A minor comment: the abstract is clear but probably a little too 
> > > long for an abstract.
> > >
> > > -- Section 7.3 --
> > > Just wonder why  LINKLOCAL-IPV6-ID-ADDRES is not mentioned in this 
> > > section but well in the next one ?
> > >
> > >
> > >
>
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Roman Danyliw's No Objection on draft-ietf-pce-pcep-extension-for-pce-controller-12: (with COMMENT)

[Pengshuping (Peng Shuping)]

Hi Roman, 

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

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


-Original Message-
From: Roman Danyliw via Datatracker [mailto:nore...@ietf.org] 
Sent: Thursday, February 25, 2021 2:58 AM
To: The IESG 
Cc: draft-ietf-pce-pcep-extension-for-pce-control...@ietf.org; 
pce-cha...@ietf.org; pce@ietf.org; Julien Meuric ; 
julien.meu...@orange.com
Subject: Roman Danyliw's No Objection on 
draft-ietf-pce-pcep-extension-for-pce-controller-12: (with COMMENT)

Roman Danyliw has entered the following ballot position for
draft-ietf-pce-pcep-extension-for-pce-controller-12: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-for-pce-controller/



--
COMMENT:
--

Thank you to Yaron Sheffer for the SECDIR review and the updates made as a 
result to improve the Security Considerations.  I endorse the revised text that 
minimally RECOMMENDs the use of “mutually-authenticated and encrypted 
sessions.”  My question is why can’t we go even further and require (use MUST) 
this crucial provisioning channel always be protected.  When would we NOT want 
to use TLS?  I appreciate that mandating the use of security primitives in 
routing is challenging due to a long tail of legacy investment.  However, this 
extension seems like a near "green field" focused on a modern, SDN architecture 
which seems unlikely to have less capable legacy elements.


Shuping> This is a case of blending elements of SDN into the existing 
distributed control plane and devices without necessarily completely replacing 
it and enhancing PCEP as an SBI. It is true that the central control 
instructions allows greater control to label allocation but it is not far from 
what is already done for segment routing label stack (which uses 'RECOMMEND').

Best Regards, 
Shuping 
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Robert Wilton's No Objection on draft-ietf-pce-pcep-extension-for-pce-controller-12: (with COMMENT)

[Pengshuping (Peng Shuping)]

Hi Robert, 

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

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


-Original Message-
From: Robert Wilton via Datatracker [mailto:nore...@ietf.org] 
Sent: Thursday, February 25, 2021 8:26 PM
To: The IESG 
Cc: draft-ietf-pce-pcep-extension-for-pce-control...@ietf.org; 
pce-cha...@ietf.org; pce@ietf.org; Julien Meuric ; 
julien.meu...@orange.com
Subject: Robert Wilton's No Objection on 
draft-ietf-pce-pcep-extension-for-pce-controller-12: (with COMMENT)

Robert Wilton has entered the following ballot position for
draft-ietf-pce-pcep-extension-for-pce-controller-12: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-for-pce-controller/



--
COMMENT:
--

Hi,

Thanks for the document, I have not had time to review in detail.

The length of the abstract does stand out to me, and it might be helpful if it 
could be shortened.  E.g. I suspect that the first two paragraphs are probably 
not required in the abstract and are best covered in the introduction.

Shuping> Updated.

On section 10:

   A PCE or PCC implementation SHOULD allow to configure to enable/
   disable PCECC capability as a global configuration.   =>
   A PCE or PCC implementation SHOULD allow the PCECC capability
   to be enabled/disabled as part of the global configuration.

Also probably change "is enabled on the PCEP session" to "is enabled on a PCEP 
session"?

Shuping> Ack

Best Regards, 
Shuping 


Regards,
Rob



___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Benjamin Kaduk's No Objection on draft-ietf-pce-pcep-extension-for-pce-controller-12: (with COMMENT)

[Pengshuping (Peng Shuping)]

Hi Benjamin, 

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

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


-Original Message-
From: Benjamin Kaduk via Datatracker [mailto:nore...@ietf.org] 
Sent: Thursday, February 25, 2021 2:59 PM
To: The IESG 
Cc: draft-ietf-pce-pcep-extension-for-pce-control...@ietf.org; 
pce-cha...@ietf.org; pce@ietf.org; Julien Meuric ; 
julien.meu...@orange.com
Subject: Benjamin Kaduk's No Objection on 
draft-ietf-pce-pcep-extension-for-pce-controller-12: (with COMMENT)

Benjamin Kaduk has entered the following ballot position for
draft-ietf-pce-pcep-extension-for-pce-controller-12: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-for-pce-controller/



--
COMMENT:
--

I agree with Roman about the prospects for ensuring a solid security baseline 
with what is essentially greenfield deployment.

Shuping> As mentioned to Roman, this is a case of blending elements of SDN into 
the existing distributed control plane and devices without necessarily 
completely replacing it. 

(throughout) Is the TLV LSP-IDENTIFIER or LSP-IDENTIFIERS (with final 'S')?

Shuping> Updated to LSP-IDENTIFIERS (as per RFC 8231)

Thanks to Yaron Sheffer for the secdir reviews, and to the authors for updating 
in light of that review.

I note in a few places in the section-by-section comments that the figures seem 
to indicate a 'D' flag in PCInitiate and PCUpd messages, and the only D flag I 
see mentioned in the prose is the Delegate flag in a PCRpt.  This seems 
particularly important to check and get right (though I admit that I could just 
be missing something).

Shuping> Yes, D flag is the Delegate flag. Changed the text so that it is 
applicable for other PCEP messages as well - "The ingress PCC and PCE MUST also 
set D (Delegate) flag (see [RFC8231]) and C (Create) flag (see [RFC8281]) in 
the LSP object in the initial exchange."

Section 1

   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.  Thus, the LSP can be
   calculated/setup/initiated and the label forwarding entries can also
   be downloaded through a centralized PCE server to each network
   devices along the path while leveraging the existing PCE technologies
   as much as possible.

nit: "each network device" singular.

Shuping> Ack

Section 2

   The terminology used in this document is the same as that described
   in the draft [RFC8283].

"That RFC doesn't look like a draft to me"

Shuping> removed


Section 3

   This document also allows a case where the label space is maintained
   by the PCC itself, and the labels are allocated by the PCC, in this
   case, the PCE should request the allocation from PCC as described in
   Section 5.5.8.

nit: comma splice.

Shuping> Ack

Section 4

   4.  PCEP procedures need to provide a mean to update (or clean up)
   the label-download entry to the PCC.

   5.  PCEP procedures need to provide a mean to synchronize the labels
   between the PCE and the PCC via PCEP messages.

nits: "provide a means" plural (twice); s/the label-download entry/label 
entries downloaded/ (I think)

Shuping> Ack

Section 5.4

   A legacy PCEP speaker (that does not recognize the PCECC Capability
   sub-TLV) will ignore the sub-TLV in accordance with [RFC8408] and
   [RFC5440].  As per [RFC8408], the legacy PCEP speaker (that does not
   support PST), it will:

Sending a PCErr for an unrecognized PST in the PATH-SETUP-TYPE-CAPABILITY would 
break extensibility; the 21/1 error type/value pair is only used in RFC 8408 
when a PST is attempted to be used in a PCRpt, PCInitiate, or PCUpd.  I think 
we should just say that it ignores the PST in the PATH-SETUP-TYPE-CAPABILITY 
TLV.

Shuping> Changed to "As per [RFC8408], the legacy PCEP speaker on receipt of an 
unsupported PST in RP/SRP Object will:" to make it clear.


Section 5.5.1

   An LSP-IDENTIFIER TLV MUST be included for PCECC LSPs, the tuple
   uniquely identifies the LSP in the network.  [...]

Which tuple?

Shuping> Removed.

Also, RFC 8231 says that the LSP-IDENTIFIERS TLV (note final 'S') must be used 
for RSVP-signaled LSPs, but PCECC is not 

Re: [Pce] Murray Kucherawy's No Objection on draft-ietf-pce-pcep-extension-for-pce-controller-12: (with COMMENT)

[Pengshuping (Peng Shuping)]

Hi Murray,

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

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


-Original Message-
From: Murray Kucherawy via Datatracker [mailto:nore...@ietf.org] 
Sent: Thursday, February 25, 2021 3:42 PM
To: The IESG 
Cc: draft-ietf-pce-pcep-extension-for-pce-control...@ietf.org; 
pce-cha...@ietf.org; pce@ietf.org; Julien Meuric 
Subject: Murray Kucherawy's No Objection on 
draft-ietf-pce-pcep-extension-for-pce-controller-12: (with COMMENT)

Murray Kucherawy has entered the following ballot position for
draft-ietf-pce-pcep-extension-for-pce-controller-12: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-for-pce-controller/



--
COMMENT:
--

In Section 2, RFC 8283 isn't a "draft".

Shuping> Removed!

In Section 5.5.1:

   Once the label operations are completed, the PCE SHOULD send a PCUpd
   message to the ingress PCC.

Why "SHOULD"?  Is there another option?   Why might an implementer do something 
else?

Shuping> Changed to MUST. Thanks for spotting this!

The SHOULDs elsewhere in Section 5 are probably worth a second look too.

Shuping> Ack

Best Regards, 
Shuping 

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Genart last call review of draft-ietf-pce-pcep-extension-for-pce-controller-11

[Pengshuping (Peng Shuping)]

Hi Gyan, 

Many thanks for your review. Please find my responses inline below. 

I have also uploaded the new version of this draft according to your reviews 
and suggestions. . 

https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-for-pce-controller-12
 
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pcep-extension-for-pce-controller-12

Please let us know if there is any further comments. 

Thank you!

> -Original Message-
> From: Gyan Mishra via Datatracker [mailto:nore...@ietf.org]
> Sent: Thursday, February 11, 2021 7:03 AM
> To: gen-...@ietf.org
> Cc: draft-ietf-pce-pcep-extension-for-pce-controller@ietf.org;
> last-c...@ietf.org; pce@ietf.org
> Subject: Genart last call review of
> draft-ietf-pce-pcep-extension-for-pce-controller-11
> 
> Reviewer: Gyan Mishra
> Review result: Almost Ready
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area Review
> Team (Gen-ART) reviews all IETF documents being processed by the IESG for
> the IETF Chair.  Please treat these comments just like any other last call
> comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-pce-pcep-extension-for-pce-controller-??
> Reviewer: Gyan Mishra
> Review Date: 2021-02-10
> IETF LC End Date: 2021-02-08
> IESG Telechat date: 2021-02-25
> 
> Summary:
> This document is very well written and describes a new PCEP protocol
> extension for using PCE as a centralized controller PCECC for provisioning
> using its own discrete label space for all or discrete parts static LSP ERO
> path.
> 
> Major issues:
> None
> 
> Minor issues:
> 
> For stateful PCE how do you prevent label collisions when both the PCE is
> provisioning using its own label space and the routers also are using their
> own label space as well and have a mix of both.  After the label download
> and sync at each router hop PCE PCC session their maybe some nodes that
> use the router label space  and other nodes using PCE label space.
> 

This is covered in Section 3, I have added text to clarify further -

   As per Section 3.1.2. of [RFC8283], the PCE-based controller will
   take responsibility for managing some part of the MPLS label space
   for each of the routers that it controls, and may take wider
   responsibility for partitioning the label space for each router and
   allocating different parts for different uses.  The PCC MUST NOT make
   allocations from the label space set aside for the PCE to avoid
   overlap and collisions of label allocations.


> It would seem more complicated to have a mix of having both PCE managed
> label space and non PCE managed label space and for this draft since it’s
> about provisioning static LSP using PCE discrete label space I think it would
> make more sense to have entire LSP to be provisioned using PCE label space
> to prevent label collisions.  This caveat I think should be added to the
> considerations section as well.   

OK, I have added -

   It is RECOMMENDED that
   PCE makes allocations (from the label space set aside for the PCE)
   for all nodes along the path.


> I did not see it mentioned but I think it’s
> also worthwhile mentioning what is the advantage of using this extension
> where the PCE uses its own label space.  Also list the disadvantages as well
> so the operator had a clear picture of reasons to use this extension and
> maybe reasons to not use.  It maybe also worthwhile to mention use cases
> where it makes sense to use this extension and others where it is not.


I have added the following text, which includes the correct references -

   [RFC8283] examines the motivations and applicability for PCECC and
   use of PCEP as an SBI.  Section 3.1.2. of [RFC8283] highlights the
   use of PCECC for label allocation along the static LSPs and it
   simplifies the processing of a distributed control plane by blending
   it with elements of SDN and without necessarily completely replacing
   it.  This allows the operator to introduce the advantages of SDN
   (such as programmability) into the network.  Further Section 3.3. of
   [I-D.ietf-teas-pcecc-use-cases] describes some of the scenarios where
   the PCECC technique could be useful.  Section 4 of [RFC8283] also
   describe the implications on the protocol when used as an SDN SBI.
   The operator needs to evaluate the advantages offered by PCECC
   against the operational and scalability needs of the PCECC.


> 
> In section 9 I agree it’s a good idea to have mutually authentication and
> encrypted sessions for all PCE PCC sessions to prevent malicious PCE using
> this extension.
> 
> Nits/editorial comments:
> The abstract states the following in the last sentence which I think should
> better describe the goal and purpose of the draft.
> 
> “ This document specifies the procedures and PCEP extensions for using
> the PCE as the central controller.”
> 
> I would say use of PCE as a centralized controller for provisioning 

Re: [Pce] Secdir last call review of draft-ietf-pce-pcep-extension-for-pce-controller-10

[Pengshuping (Peng Shuping)]

Dear Yaron, 

Thank you for your comments! We have made an update based on your comments. 
Please suggest further text if required. The Security section is further 
expended and more details are provided, especially the new section on the 
Malicious PCC is added as below. 

9.2.  Malicious PCC 

   The PCECC mechanism described in this document requires the PCE to   
   keep labels (CCI) that it downloads and relies on the PCC responding 
   (with either an acknowledgment or an error message) to requests for  
   LSP instantiation.  This is an additional attack surface by placing 
a
   requirement for the PCE to keep a CCI/label replica for each PCC.  
It
   is RECOMMENDED that PCE implementations provide a limit on resources 
   (in this case the CCI) a single PCC can occupy.  [RFC8231] provides 
a
   notification mechanism when such threshold is reached.   

Please also find the working copy and the diff. 

Working copy: 
https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-pce-pcep-extension-for-pce-controller-11.txt
 
Diff: 
https://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=draft-ietf-pce-pcep-extension-for-pce-controller-10=https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-pce-pcep-extension-for-pce-controller-11.txt
 

Best Regards, 
Shuping 


> -Original Message-
> From: Yaron Sheffer via Datatracker [mailto:nore...@ietf.org]
> Sent: Sunday, February 7, 2021 3:35 AM
> To: sec...@ietf.org
> Cc: draft-ietf-pce-pcep-extension-for-pce-controller@ietf.org;
> last-c...@ietf.org; pce@ietf.org
> Subject: Secdir last call review of
> draft-ietf-pce-pcep-extension-for-pce-controller-10
> 
> Reviewer: Yaron Sheffer
> Review result: Not Ready
> 
> This document defines PCEP extensions for the RFC 8283 architecture, where
> the PCE acts as a central controller in an SDN. The document is focused on
> specific use cases, referred to as "basic PCECC mode".
> 
> Let me state up front that I am not familiar with the PCE architecture other
> than what I read up in order to review this document. Having said that, I
> suspect that there would be significant value in a security analysis of the
> architecture defined here. Having each connection "authenticated and
> encrypted"
> is table stakes nowadays, but is it really enough for very large SDN
> deployments that require this level of protocol sophistication?
> 
> Details
> 
> 9.1: "authenticated and encrypted" TLS sessions are typically only
> authenticated by the server. Please point out explicitly that mutual
> authentication is required. Also, is there no authorization? I would assume a
> peer PCE Controller is allowed to do different things than a PCC. Are all PCCs
> allowed to issue the same commands/queries, targeted at the same
> resources?
> 
> - RFC 8283 which defines the architecture that is implemented by this draft
> says:
> 
> [The] security implications of SDN have not been fully discussed or
> described.
> Therefore, protocol and applicability work-around solutions for this
> architecture must take proper account of these concerns.
> 
> It is expected that each new document that is produced for a specific use
> case will also include considerations of the security impacts of the use of a
> PCE-based central controller on the network type and services being
> managed.
> 
> I don't think that the current document addresses this challenge.
> 
> In general, this looks like a very monolithic architecture, where everybody
> trusts everybody else once they've been authenticated. Although Sec. 9.1
> discusses the case of a malicious PCE (which would be rather catastrophic), I
> would encourage the authors to consider whether a malicious PCC can also
> disrupt the PCE's operations and cause "major impact to the network".
> 

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] RtgDir review: draft-ietf-pce-pcep-extension-for-pce-controller-09

[Pengshuping (Peng Shuping)]

Hi Victoria, 

Many thanks for your review. Please find the diff which reflects the changes we 
have made following your suggestions. 

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

Please find our responses in line below. 

Best regards, 
Shuping


From: Pritchard, Victoria [mailto:victoria.pritch...@airbus.com] 
Sent: Tuesday, December 22, 2020 9:16 PM
To: rtg-...@ietf.org
Cc: rtg-...@ietf.org; 
draft-ietf-pce-pcep-extension-for-pce-controller@ietf.org; pce@ietf.org
Subject: RtgDir review: draft-ietf-pce-pcep-extension-for-pce-controller-09


Hello,

I have been selected as the Routing Directorate reviewer for this draft: PCEP 
Procedures and Protocol Extensions for Using PCE as a Central Controller 
(PCECC) of LSPs. 

The Routing Directorate seeks to review all routing or routing-related drafts 
as they pass through IETF last call and IESG review, and sometimes on special 
request. The purpose of the review is to provide assistance to the Routing ADs. 
For more information about the Routing Directorate, please see 
http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would 
be helpful if you could consider them along with any other IETF Last Call 
comments that you receive, and strive to resolve them through discussion or by 
updating the draft.



Document: draft-ietf-pce-pcep-extension-for-pce-controller-09
Reviewer: Victoria Pritchard
Review Date: 22/12/2020
IETF LC End Date: 
Intended Status: Standards Track



Summary:

I have some minor concerns about this document that I think should be resolved 
before publication.



Comments:

    The draft is generally very good and the diagrams are also very helpful. 

[Shuping] Thank you! 


A few sections may initially cause a reader to be confused. I have 
suggested some reorganisation of the text in case this is helpful. 

I also found a few things which were unclear, which could be clarified in 
the document, and have included questions in the Minor issues section.

[Shuping] Thanks for providing such detailed comments with suggested text. Much 
appreciated!

Major Issues:

    No major issues found.



Minor Issues:

Section 5.4: I got confused reading this - the first part isn't clear but then 
extra information is given, but it would be better to be clear from the 
start... Here is some suggested text: 
---
During the PCEP Initialization Phase, PCEP Speakers (PCE or PCC) advertise 
their support of and willingness to use PCEP extensions for PCECC using these 
elements in the OPEN message:

   o  A new Path Setup Type (PST) in the PATH-SETUP-TYPE-CAPABILITY TLV to 
indicate support for PCEP extensions for PCECC - TBD1 (Path is set up via PCECC 
mode)
   o  A new PCECC-CAPABILITY sub-TLV inside the PATH-SETUP-TYPE-CAPABILITY TLV 
to indicate willingness to use PCEP extensions for PCECC
   o  The STATEFUL-PCE-CAPABILITY TLV ([RFC8231]) (with the I flag set 
[RFC8281])

The new Path Setup Type is to be listed in the PATH-SETUP-TYPE-CAPABILITY TLV 
by all PCEP speakers which support the PCEP extensions for PCECC in this 
document.

The new PCECC-CAPABILITY sub-TLV is included in PATH-SETUP-TYPE-CAPABILITY TLV 
in the OPEN object to indicate willingness to use the PCEP extensions for PCECC 
during the established PCEP session. Using flags in this TLV, the PCE shows the 
intention to function as a PCECC server, and the PCC shows willingness to act 
as a PCECC client (see Section 7.1.1).

If the PCECC-CAPABILITY sub-TLV is advertised and the STATEFUL-PCE-CAPABILITY 
TLV is not advertised, or is advertised without the I flag set, in the OPEN 
Object, the receiver MUST:
   o  Send a PCErr message with Error-Type=19 (Invalid Operation) and 
Error-value=TBD4 (stateful PCE capability was not advertised) 
   o  Terminate the session

The PCECC-CAPABILITY sub-TLV SHOULD NOT be used without the corresponding Path 
Setup Type being listed in the PATH-SETUP-TYPE-CAPABILITY TLV. If it is present 
without the corresponding Path Setup Type listed in the 
PATH-SETUP-TYPE-CAPABILITY TLV, it MUST be ignored.

If support and willingness are indicated by the PCE, but not by the PCC, the 
PCE MUST:
   o  Send a PCErr message with Error-Type 10 (Reception of an invalid object) 
and Error-Value TBD2 (Missing PCECC-CAPABILITY sub-TLV)
   o  Terminate the PCEP session

If support and willingness is indicated by the PCC but not the PCE, the PCE 
will ignore the capability. Unknown sub-TLVs are ignored in accordance with 
[RFC8408] and [RFC5440].

If one or both speakers (PCE and PCC) have not indicated support and 
willingness to use the PCEP extensions for PCECC, the PCEP extensions for PCECC 
MUST NOT be used. If a PCECC operation is attempted when both speakers have not 
agreed in the OPEN messages, the receiver of the message MUST:
   o  

Re: [Pce] Adoption of draft-zhao-pce-pcep-extension-pce-controller-sr-09?

[Pengshuping (Peng Shuping)]

Hi WG, 

This draft has been updated and aligned with other relevant drafts, and an 
editorial cleanup was made. I support the WG adoption as a coauthor. 

Thank you! 

Best regards, 
Shuping 



> -Original Message-
> From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of
> julien.meu...@orange.com
> Sent: Thursday, November 26, 2020 11:35 PM
> To: pce@ietf.org
> Subject: [Pce] Adoption of
> draft-zhao-pce-pcep-extension-pce-controller-sr-09?
> 
> Hi all,
> 
> PCECC extensions are progressing towards the IESG. It is time to share your
> thoughts about draft-zhao-pce-pcep-extension-pce-controller-sr-09.
> Do you believe the I-D is a right foundation for a PCE WG item? Please use
> the PCE mailing list to express your comments, support or disagreement,
> including applicable rationale, especially for the latter.
> 
> Thanks,
> 
> Dhruv & Julien
> 

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Adoption of draft-zhao-pce-pcep-extension-pce-controller-sr-09?

[Pengshuping (Peng Shuping)]

Hi Adrian,

Thank you for your comments.

We plan to discuss the PCEP-LS in the next meeting in a hope to make some 
progress on it. We can always move the TLV in question to this I-D from PCEP-LS 
if need be.

RFC5511 will be added.

Thank you!

Best regards,
Shuping


--
彭书萍 Peng Shuping
Mobile: +86-18210364128(优先)
Email: pengshup...@huawei.com
发件人：Adrian Farrel 
收件人：julien.meuric ;pce 
时 间：2020-12-03 21:05:30
主 题：Re: [Pce] Adoption of draft-zhao-pce-pcep-extension-pce-controller-sr-09?

Hello all,

I was a contributor to some of the earlier versions of this document and am 
listed as such (although I don't think I work for Juniper any more).

I think the document is in a good enough state for adoption.

Post-adoption there are some things that could benefit from work...

- I worry about having draft-dhodylee-pce-pcep-ls referenced by section 5.4
  This use is normative, but draft-dhodylee-pce-pcep-ls is only included as an
  informative reference. It is worrying because it is unclear at this stage 
whether
  the WG will choose to adopt that work.
- The document feels too long for a relatively small extension. However, a
  quick scan doesn't immediately identify sections to prune.
- A reference to RFC 5511 is needed to explain section 6.1

Best,
Adrian

-Original Message-
From: Pce < pce-boun...@ietf.org> On Behalf Of 
julien.meu...@orange.com
Sent: 26 November 2020 15:35
To: pce@ietf.org
Subject: [Pce] Adoption of draft-zhao-pce-pcep-extension-pce-controller-sr-09?

Hi all,

PCECC extensions are progressing towards the IESG. It is time to share
your thoughts about draft-zhao-pce-pcep-extension-pce-controller-sr-09.
Do you believe the I-D is a right foundation for a PCE WG item? Please
use the PCE mailing list to express your comments, support or
disagreement, including applicable rationale, especially for the latter.

Thanks,

Dhruv & Julien



___
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] IPR Poll on draft-zhao-pce-pcep-extension-pce-controller-sr-09

[Pengshuping (Peng Shuping)]

Hi Hari,

I am not aware of any IPR applicable to this draft that should be disclosed in 
accordance with IETF IPR rules.

Thank you!

Best regards,
Shuping


From: Hariharan Ananthakrishnan [mailto:h...@netflix.com]
Sent: Friday, November 27, 2020 6:58 AM
To: Lizhenbin ; Pengshuping (Peng Shuping) 
; Mahend Negi ; 
qz...@ethericnetworks.com; chaozhou...@yahoo.com
Cc: pce@ietf.org
Subject: IPR Poll on draft-zhao-pce-pcep-extension-pce-controller-sr-09


Hi Authors,



In preparation for WG adoption on this draft, I'd like all

authors and contributors to confirm on the list that they are in compliance

with IETF IPR rules.

Please respond (copying the mailing list) to say one of:

I am not aware of any IPR applicable to this draft that should be disclosed

in accordance with IETF IPR rules.



I am aware of the IPR applicable to this draft, and it has already been

disclosed to the IETF.



I am aware of IPR applicable to this draft, but that has not yet been

disclosed to the IETF. I will work to ensure that it will be disclosed in a

timely manner.



Thanks,

- Hari
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Shepherd's Review of draft-ietf-pce-pcep-extension-for-pce-controller-07

[Pengshuping (Peng Shuping)]

Hi Julien, 

Many thanks for your review and comments!

We will update the draft as per your comments, especially with an editorial 
cleanup of figures and the reference.

Best regards, 
Shuping 


> -Original Message-
> From: julien.meu...@orange.com [mailto:julien.meu...@orange.com]
> Sent: Wednesday, November 18, 2020 11:13 PM
> To: Pengshuping (Peng Shuping) ;
> draft-ietf-pce-pcep-extension-for-pce-control...@ietf.org
> Cc: pce@ietf.org
> Subject: Re: Shepherd's Review of
> draft-ietf-pce-pcep-extension-for-pce-controller-07
> 
> Hi Shuping,
> 
> Thanks for the update. Please see [JM] below.
> 
> Cheers,
> 
> Julien
> 
> 
> On 14/11/2020 07:17, Pengshuping (Peng Shuping) wrote:
> > Hi Julien,
> >
> > Thank you for your comments. We have handled the shepherd review and
> an update is posted. Please find the diff and responses inline. Thank you!
> >
> >
> https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-for-pce-contr
> oller/
> > and
> https://www.ietf.org/rfcdiff?url1=draft-ietf-pce-pcep-extension-for-pce-con
> troller-07=draft-ietf-pce-pcep-extension-for-pce-controller-08
> >
> > Best regards,
> > Shuping
> >
> >> -Original Message-
> >> From: julien.meu...@orange.com [mailto:julien.meu...@orange.com]
> >> Sent: Wednesday, October 21, 2020 10:51 PM
> >>
> >> Hi authors of draft-ietf-pce-pcep-extension-for-pce-controller,
> >>
> >> Please find below my review of the aforementioned I-D.
> >>
> >> Regards,
> >>
> >> Julien
> >>
> >> ---
> >>
> >> *Main Concerns*
> >>
> >> - From a PCECC operation stand point, it feels odd that what is referred to
> as
> >> "basic PCECC LSP setup" is actually PCC triggered, whereas the
> PCE-initiatied
> >> option does exist as well. Even though it adds an additional PCInitiate
> >> message, I would suggest to define the latter as the "basic setup", which
> >> would not only address that comment, but would also mitigate the
> following
> >> concerns on PCC-triggered setup.
> >> - I have 2 issues with PCC-triggered setup:
> >>   * it adds LSP characteristics and egress-related information in the
> ingress
> >> PCC, which is not straightforward in a PCECC context (certainly not for a
> >> "base setup");
> >>   * the behavior triggered by the initial PCRpt is implementation-specific
> in
> >> the PCE: as per section 5.8.3 of RFC 8231, I could configure my PCE to just
> >> store the reported info, or make it wait for whatever event before
> actually
> >> starting something ("PCE *decides* to update the LSP", "the PCE *can*
> >> modify LSP parameters of delegated LSPs").
> >>   => Assuming the PCC-triggerred option is really needed, this limitation
> >> should be more explicit.
> > The order has been changed and the text is added to say that in case of
> PST=PCECC it SHOULD calculate and set up the path based on the PCECC
> technique.
> [JM] Thank you for the changes. I believe both of them do improve the I-D.
> 
> >> - At the end of section 6.1, some errors are defined with respect to the
> >> number of CCI objects in a message. If the ingress PCE has a particular
> role
> >> (e.g. PLSP-ID allocation), how do other PCCs know if they are transit or
> >> egress to be able to check the number of CCIs they get?
> >> AFAIU, at 1st setup, only inconsistencies between the O bit and the
> number
> >> of CCIs can trigger an error; on LSP updates the node may add an
> additional
> >> check with respect to its role before the update: those situations need to
> be
> >> clarified.
> > The source and destination are part of the LSP-IDENTIFIERS TLV, that can
> help identify Ingress, egress and Transit. The text has been added for that.
> [JM] Fine, thanks.
> 
> >> - There is no reference to RFC 8741. Is it applicable? If so, then how?
> > Added.
> [JM] OK, fine.
> 
> >> *Nits*
> 
> 
> >> - Figure 1: all figures have the same message ordering, though the order
> only
> >> matters when using PCC-allocated labels (leaving initial and last messages
> >> apart); have you considered shuffling the message order a bit on figures
> for
> >> PCE-allocated cases?
> > It's true from the point of view of the messages on wire and thus we don't
> put this in the specification, but internally the PCE would still allocate 
> label
> from the internal sp

Re: [Pce] Shepherd's Review of draft-ietf-pce-pcep-extension-for-pce-controller-07

[Pengshuping (Peng Shuping)]

Hi Julien,

Thank you for your comments. We have handled the shepherd review and an update 
is posted. Please find the diff and responses inline. Thank you!

https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-for-pce-controller/
and 
https://www.ietf.org/rfcdiff?url1=draft-ietf-pce-pcep-extension-for-pce-controller-07=draft-ietf-pce-pcep-extension-for-pce-controller-08

Best regards, 
Shuping 

> -Original Message-
> From: julien.meu...@orange.com [mailto:julien.meu...@orange.com]
> Sent: Wednesday, October 21, 2020 10:51 PM
> To: draft-ietf-pce-pcep-extension-for-pce-control...@ietf.org
> Cc: pce@ietf.org
> Subject: Shepherd's Review of
> draft-ietf-pce-pcep-extension-for-pce-controller-07
> 
> Hi authors of draft-ietf-pce-pcep-extension-for-pce-controller,
> 
> Please find below my review of the aforementioned I-D.
> 
> Regards,
> 
> Julien
> 
> ---
> 
> *Main Concerns*
> 
> - From a PCECC operation stand point, it feels odd that what is referred to as
> "basic PCECC LSP setup" is actually PCC triggered, whereas the PCE-initiatied
> option does exist as well. Even though it adds an additional PCInitiate
> message, I would suggest to define the latter as the "basic setup", which
> would not only address that comment, but would also mitigate the following
> concerns on PCC-triggered setup.
> - I have 2 issues with PCC-triggered setup:
>   * it adds LSP characteristics and egress-related information in the ingress
> PCC, which is not straightforward in a PCECC context (certainly not for a
> "base setup");
>   * the behavior triggered by the initial PCRpt is implementation-specific in
> the PCE: as per section 5.8.3 of RFC 8231, I could configure my PCE to just
> store the reported info, or make it wait for whatever event before actually
> starting something ("PCE *decides* to update the LSP", "the PCE *can*
> modify LSP parameters of delegated LSPs").
>   => Assuming the PCC-triggerred option is really needed, this limitation
> should be more explicit.

The order has been changed and the text is added to say that in case of 
PST=PCECC it SHOULD calculate and set up the path based on the PCECC technique.

> - At the end of section 6.1, some errors are defined with respect to the
> number of CCI objects in a message. If the ingress PCE has a particular role
> (e.g. PLSP-ID allocation), how do other PCCs know if they are transit or
> egress to be able to check the number of CCIs they get?
> AFAIU, at 1st setup, only inconsistencies between the O bit and the number
> of CCIs can trigger an error; on LSP updates the node may add an additional
> check with respect to its role before the update: those situations need to be
> clarified.

The source and destination are part of the LSP-IDENTIFIERS TLV, that can help 
identify Ingress, egress and Transit. The text has been added for that.

> - There is no reference to RFC 8741. Is it applicable? If so, then how?

Added.

> 
> 
> *Nits*
> --
> Global
> ---
> - Consistency on capitalization of ingress/transit/egress to be corrected.

Done

> --
> Abstract
> ---
> - s/PCE-based central controller (PCECC)/PCE-based Central Controller
> (PCECC)/
> - s/"calculated/setup"/"calculated/set up"/
> - s/each network devices/each network device/

Done

> --
> Section 1.
> ---
> - s/offload path computation function/offload the path computation
> function/
> - s/PCE-based central controller (PCECC)/PCE-based Central Controller
> (PCECC)/
> - s/such a way that, extensions/such a way that extensions/
> - s/extensions for other use cases is/extensions for other use cases are/

Done

> --
> Section 4.
> ---
> - s/PCE speaker supporting/A PCE speaker supporting/
> - s/PCE speaker needs/A PCE speaker needs/
> - s/needs the means/needs means/
> - s/PCECC based LSP/PCECC-based LSPs/
> - s/PCECC based label allocations/PCECC-based label allocations/
> - s/provide a means/provide a mean/  [x2]
> - s/between PCE and PCC/between the PCE and the PCC/

Done

> --
> Sections 5. & 5.1.
> ---
> - s/PCE as the Central Controller/PCE as a Central Controller/
> - s/reuses existing Active stateful PCE mechanism/reuses the existing active
> stateful PCE mechanism/
> - s/control the LSP/control LSPs/

Done

> --
> Section 5.4.
> ---
> - s/the PCEP speaker MUST send a PCErr/the receiving PCEP speaker MUST
> send a PCErr/
> - OLD
>    [...] 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.
>   NEW
>    [...] If a PCEP speaker
>    which supports 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 

Re: [Pce] WGLC for draft-ietf-pce-association-policy

[Pengshuping (Peng Shuping)]

Hi,

I have read this draft, and I support this document being published as an RFC.

Just a few nits are found and listed as below.

1. "may instantiate LSPs and specifies" -> "...specify"
2. "[RFC8697] specify" -> "... specifies"
3. "Error- Value 4" -> "Error-Value 4"
4. " In some cases to apply a PCE policy successfully, it is required to also 
associate some policy parameters that needs to be evaluated, to successfully 
apply the said policy. " 
-> " In some cases to apply a PCE policy successfully, it is required to also 
associate some policy parameters that need to be evaluated. "
5. "The TLV could include one or more policy related parameter" -> "... 
parameters"
6. "a 4-bytes alignment" -> "4-byte"
7. "The PCEP peer implementation need to be aware" 
->" The PCEP peer implementation needs to be aware"
8. "Further, if one or more parameters received in the POLICY-PARAMETERS-TLV 
received by the PCEP speaker "
-> "Further, if one or more parameters in the POLICY-PARAMETERS-TLV received by 
the PCEP speaker "
9. " IANA is requested to confirm the early-allocated codepoints "
-> " IANA is requested to confirm the early-allocated code point" 
10. "in which case the an operator MUST "
-> " in which case the operator MUST "
11. "This module supports associations as defined in [RFC8697] and thus support 
the Policy Association groups "
-> "This module supports associations as defined in [RFC8697] and thus supports 
the Policy Association groups "
12. " this document borrow some of " -> " this document borrowed some of "

Best regards,
Shuping


> -Original Message-
> From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Dhruv Dhody
> Sent: Friday, September 4, 2020 1:13 PM
> To: pce@ietf.org
> Cc: draft-ietf-pce-association-pol...@ietf.org; pce-chairs
> 
> Subject: [Pce] WGLC for draft-ietf-pce-association-policy
> 
> Hi WG,
> 
> This email starts a working group last call for
> draft-ietf-pce-association-policy [1].  Please indicate your support or
> concern for this draft. If you are opposed to the progression of the draft to
> RFC, please articulate your concern. If you support it, please indicate that
> you have read the latest version and it is ready for publication in your
> opinion. As always, review comments and nits are most welcome.
> 
> The WG LC will end on 21st September 2020.
> 
> Thanks,
> Dhruv & Julien
> [1] https://datatracker.ietf.org/doc/draft-ietf-pce-association-policy/
> 
> ___
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] New Version Notification for draft-li-pce-pcep-pmtu-02.txt

[Pengshuping (Peng Shuping)]

Dear PCEers,



Thank all the colleagues who have commented on this draft during my 
presentation in IETF108. We have addressed all the comments in this new 
version. Please review.



Htmlized:   https://datatracker.ietf.org/doc/html/draft-li-pce-pcep-pmtu

Diff:   https://www.ietf.org/rfcdiff?url2=draft-li-pce-pcep-pmtu-02



Since we have agreed that this is a nice feature to have, we would like to ask 
the WG to adopt this draft. Thank you!



Best regards,

Shuping

___
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

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

Re: [Pce] IPR Poll on draft-ietf-pce-pcep-extension-for-pce-controller

[Pengshuping (Peng Shuping)]

I am not aware of any IPR applicable to this draft that should be disclosed
in accordance with IETF IPR rules.

Best regards,
Shuping



From: Hariharan Ananthakrishnan [mailto:h...@netflix.com]
Sent: Friday, August 7, 2020 12:02 PM
To: Lizhenbin ; Pengshuping (Peng Shuping) 
; Mahend Negi ; 
qz...@ethericnetworks.com; chao.z...@cisco.com
Cc: pce@ietf.org
Subject: IPR Poll on draft-ietf-pce-pcep-extension-for-pce-controller


Hi Authors,



In preparation for WG LC on this draft, I'd like all

authors and contributors to confirm on the list that they are in compliance

with IETF IPR rules.



Please respond (copying the mailing list) to say one of:



I am not aware of any IPR applicable to this draft that should be disclosed

in accordance with IETF IPR rules.



I am aware of the IPR applicable to this draft, and it has already been

disclosed to the IETF.



I am aware of IPR applicable to this draft, but that has not yet been

disclosed to the IETF. I will work to ensure that it will be disclosed in a

timely manner.



Thanks,

- Hari
___
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

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

Re: [Pce] WG adoption poll for draft-barth-pce-segment-routing-policy-cp-06

[Pengshuping (Peng Shuping)]

Hi WG, Chairs,

I support WG adoption of this draft.

Thanks! 

Best regards,
Shuping 

-Original Message-
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Dhruv Dhody
Sent: Sunday, June 7, 2020 3:45 PM
To: pce@ietf.org
Subject: [Pce] WG adoption poll for draft-barth-pce-segment-routing-policy-cp-06

Hi WG,

This email begins the WG adoption poll for 
draft-barth-pce-segment-routing-policy-cp-06.

https://datatracker.ietf.org/doc/draft-barth-pce-segment-routing-policy-cp/06/

Should this draft be adopted by the PCE WG? Please state your reasons
- Why / Why not? What needs to be fixed before or after adoption? Are you 
willing to work on this draft? Review comments should be posted to the list.

This adoption poll will end on 22nd June 2020.

Thanks!
Dhruv & Julien

___
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] IPR Poll on draft-barth-pce-segment-routing-policy-cp-06

[Pengshuping (Peng Shuping)]

I am not aware of any IPR applicable to this draft.

Best regards,
Shuping

From: Hariharan Ananthakrishnan [mailto:h...@netflix.com]
Sent: Monday, June 8, 2020 11:49 PM
To: Mike Koldychev (mkoldych) ; msiva...@gmail.com; Colby 
Barth ; Pengshuping (Peng Shuping) 
; hooman.bidg...@nokia.com
Cc: pce@ietf.org
Subject: IPR Poll on draft-barth-pce-segment-routing-policy-cp-06


Hi Authors,



In preparation for WG adoption on this draft, I'd like all

authors and contributors to confirm on the list that they are in compliance

with IETF IPR rules.



Please respond (copying the mailing list) to say one of:



I am not aware of any IPR applicable to this draft that should be disclosed

in accordance with IETF IPR rules.



I am aware of IPR applicable to this draft, and it has already been

disclosed to the IETF.



I am aware of IPR applicable to this draft, but that has not yet been

disclosed to the IETF. I will work to ensure that it will be disclosed in a

timely manner.



Thanks,

- Hari
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce