[Pce] [PCE] New Version Notification for draft-peng-pce-entropy-label-position-02.txt

Hi all, I have updated the version of draft-peng-pce-entropy-label-position. This draft has been presented in IETF#106 meeting. Thanks for the feedback. It is very appreciated. I would like to make clarification as follows and discussions are very welcome. First, RFC8662 which has

[Pce] 答复: A pending item for draft-peng-pce-entropy-label-position

Hi Dhruv and Stephane, Thanks for your review and comments! I appreciated the comments from you last meeting and updated the draft this meeting. Multiple pairs MAY be inserted in the SR-MPLS label stack as defined in RFC8662 secssion 7.1. So from implementation view, the ingress

[Pce] 答复: cursory review of draft-xiong-pce-lsp-flag

Hi Dhruv and Loa, Thanks for your review and detailed discussion! For the IANA text, I will update that as you suggest. In my view, we need to clarify the LSP-EXTENDED-FLAG TLV is mandatory or not firstly. Then consider the error handling. There are two cases. First case, for the

[Pce] 答复: cursory review of draft-xiong-pce-lsp-flag

Hi Dhruv, Thanks for your quick reply and suggestion! The LSP-EXTENDED-FLAG TLV is not mandatory and I will modify and move the error handing to the draft-peng-pce-entropy-label which needs to use the flag. I will update the drafts as you suggest as soon as possible! Thanks, Qu

[Pce] 答复: IPR Poll on draft-xiong-pce-lsp-flag-03

Hi Hari, I am not aware of any IPR applicable to this draft that should be disclosed in accordance with IETF IPR rules. Thanks, Quan 原始邮件 发件人：HariharanAnanthakrishnan 收件人：熊泉00091065; 抄送人：pce@ietf.org; 日 期 ：2021年02月02日 04:30 主 题 ：IPR Poll on draft-xiong-pce-lsp-flag-03 Hi Authors

Re: [Pce] Adoption of draft-xiong-pce-lsp-flag-03

Yes/support as co-author. It is an important work and the extension is useful for other drafts. Thanks, Quan <<[Pce] Adoption of draft-xiong-pce-lsp-flag-03 Dhruv Dhody Mon, 01 February 2021 17:48 UTCShow header Hi WG, This email begins the WG adoption poll for draft-xiong-pce-lsp-flag-03.ht

Re: [Pce] Adoption of draft-xiong-pce-lsp-flag-03

Hi Cyril, Thanks for your review and comments! It is a good point. In my opinion, the TLV and the flag could be used in other PCEP Objects. But if the defination of extended flags are different, then the TLV is different. I think that would be a new TLV, not the LSP-EXTENDED-FLAG TLV. What

[Pce] [PCE]:New Version Notification for draft-peng-pce-entropy-label-position-05.txt

Dear Dhruv,Stephane,Zhenbin Li,Tarek and WG, I just submitted a new version of the draft-peng-pce-entropy-label-position-05. This draft has been presented in IETF 106 and 107. Many thanks for your comments and discussions. First, I think we have the consensus that in case of inter-do

Re: [Pce] Adoption of draft-xiong-pce-lsp-flag-03

Hi Adrian and Julien, Many thanks for your suggestions! I fully agree with you. The two wg drafts could be viewed as two implementations to use the flag carried in LSP-EXTENDED-FLAG TLV. I will add informative references to those two drafts if necessary. And I also suggest those two draft

Re: [Pce] [PCE]:New Version Notification for draft-peng-pce-entropy-label-position-05.txt

Hi Jeff, Many thanks for your review and comments! It is a good point. The limitations including MSD and ERLD has been described in detail in RFC8662. And I need to clarify this in my background. How about adding texts as following shown. "[RFC8662] proposes to use entropy labels fo

Re: [Pce] Adoption of draft-xiong-pce-lsp-flag-03

Hi Dhruv, Thanks for your suggestion! I agree with you to cite the draft-peng-pce-entropy-label-position as an example. But I am not sure about the two wg drafts including draft-ietf-pce-binding-label-sid-06 and draft-ietf-pce-sr-path-segment-03. As far as I know, the last unassigned bit

[Pce] Fw:New Version Notification for draft-peng-pce-entropy-label-position-06.txt

Dear WG, I submmited a new version of draft-peng-pce-entropy-label-position-06. This draft proposes the extensions for PCEP to configure the entropy label positions in SR-MPLS networks as described in RFC8662. Multiple EL/ELI pairs may be inserted in the label stack and the inserted positions S

Re: [Pce] WG Adoption of draft-tokar-pce-sid-algo-05

Hi Dhruv, I reviewed the draft and support the adoption. The draft is reasonable and necessary to extend PCEP to support the flex-algo. Thanks, Quan [Pce] WG Adoption of draft-tokar-pce-sid-algo-05 Dhruv Dhody Fri, 04 February 2022 17:14 UTCShow header Hi WG, This email begins the WG adoptio

Re: [Pce] IPR Poll for draft-ietf-pce-lsp-extended-flags-02

Hi Hari, I am not aware of any IPR applicable to this draft that should be disclosed in accordance with IETF IPR rules. Thanks, Quan https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WGLC for draft-ietf-pce-lsp-extended-flags-02

Hi Dhruv and Aijun, Thanks for your review and discussion! In my veiw, 32 bits (seems good enough at the present) and variable-length ( if more bits are ever needed) are both OK to the LSP-EXTENDED-FLAG. I suggest to keep in consistency with the existing RFC such as RFC5088. I am also happy to

Re: [Pce] draft-xiong-pce-nrp-id-01

Hi Dhruv, Thanks for your suggestions! That really helps to progress the this work. Please see in-line with Quan. [Pce] draft-xiong-pce-nrp-id-01 Dhruv Dhody Fri, 22 July 2022 18:32 UTCShow header Hi, Consider adding capability exchange before using this NRP-ID TLV. Quan>Good point, NRP capa

Re: [Pce] draft-xiong-pce-detnet-bounded-latency-00

Hi Dhruv, Thanks for your review and suggestions! That really helps to progress the this work. Please see in-line with Quan. [Pce] draft-xiong-pce-detnet-bounded-latency-00 Dhruv Dhody Fri, 22 July 2022 18:28 UTCShow header Hi, I am not able to understand how you would be adding the Queuing In

Re: [Pce] draft-xiong-pce-detnet-bounded-latency-00

Hi Dhruv, Thanks for your reply! I agree with you. PCEP extension work belongs in the PCE WG and requirement belongs in the DetNet WG. Thanks for your suggestion to progress this work. It would be better to list out the requirements for PCEP and then get a confirmation of those requireme

Re: [Pce] Routing directorate early review of draft-ietf-pce-lsp-extended-flags

Hi Jon and chairs, Thanks for your review and comments! I will update a new version to modify the first text of Section 3.2 shown as following: "The LSP Extended Flags field is an array of units of 32 flags and to be allocated starting from the most significant bit. The bits of the LSP Extended

Re: [Pce] Routing directorate early review of draft-ietf-pce-lsp-extended-flags

Hi Jon and chairs, Thanks for your suggestions! A new version of I-D, draft-ietf-pce-lsp-extended-flags-04.txt has been uploaded.Name:draft-ietf-pce-lsp-extended-flagsRevision: 04Title:Label Switched Path (LSP) Object Flag Extension of Stateful PCEDocument date:20

Re: [Pce] AD review of draft-ietf-pce-lsp-extended-flags-04

Hi John, Sorry for the delay! Thanks so much for the detailed review and comments! First of all, I think the iddiff output is very convenient and works better than traditional numbered list of comments. Just my view. LOL. I have submitted a new version based on your suggestions and the updates a

Re: [Pce] Opsdir last call review of draft-ietf-pce-lsp-extended-flags-05

Hi Bo, Thanks for your review! Please see inline with Quan>>. Quan < To: ops-...@ietf.org ; Cc: draft-ietf-pce-lsp-extended-flags@ietf.org ;last-c...@ietf.org ;pce@ietf.org ; Date: 2022年10月11日 21:31 Subject: Opsdir last call review of draft-ietf-pce-lsp-extended-flags-05 Reviewer: Bo Wu R

Re: [Pce] [Last-Call] Opsdir last call review of draft-ietf-pce-lsp-extended-flags-05

Hi Dhruv and Bo, Thanks for your review and suggestions! I have revised and update the draft as your comments. https://www.ietf.org/archive/id/draft-ietf-pce-lsp-extended-flags-07.html Best Regards, Quan Original From: DhruvDhody To: 熊泉00091065; Cc: nore...@ietf.org ;

Re: [Pce] [PCE]Éric Vyncke's No Objection on draft-ietf-pce-lsp-extended-flags-07: (with COMMENT)

Hi Eric, John and Dhruv, Thanks for your discussions and suggestions! I have updated the draft as Eric's comments in version -08. I revised the text in section 1 with "This document extends the flag field of the LSP Object for other use." I also revised the text in section 3.1 as Dhruv's suggest

Re: [Pce] [PCE]Roman Danyliw's No Objection on draft-ietf-pce-lsp-extended-flags-07: (with COMMENT)

Hi Roman, Thanks for your comments! I revised the text in section 9 as you suggested and updated the draft to version -08. Hope that will help to improve this draft and let me know if you have other suggestions. Regards, Quan From: RomanDanyliwviaDatatracker To: The IESG ; Cc: draft-iet

Re: [Pce] [PCE]Paul Wouters' No Objection on draft-ietf-pce-lsp-extended-flags-07: (with COMMENT)

Hi Paul, Thanks for your comment! The extended flags are stateful PCEP extension which need to observe the RECOMMENDED as per RFC8231. People could find that in Security Considerations section which is "it is RECOMMENDED that these PCEP extensions only be activated on authenticated and encryp

Re: [Pce] [PCE]Lars Eggert's Discuss on draft-ietf-pce-lsp-extended-flags-07: (with DISCUSS and COMMENT)

Hi Lars, John and Dhruv, Thanks for all your discussions and suggestions! I have updated the draft as Lars' comments in version -08. I revised the texts in line with RFC2119 terminology as Lars' DISCUSS suggested. A sentence was added in Section 3.1, paragraph 7 as Lars' COMMENT with "T

Re: [Pce] [PCE]Lars Eggert's Discuss on draft-ietf-pce-lsp-extended-flags-07: (with DISCUSS and COMMENT)

Hi Jonn and Dhruv, Thanks for your detailed review and suggestions! I submitted a -09 version to resolve the following three issues. 1, In Section 5, paragraph 2, "would" was replaced to "MUST". 2, In Section 9, a sentence was added at the end with "Assuming that recommendation is followed, then

Re: [Pce] IPR Poll on draft-rajagopalan-pce-pcep-color-02

Hi Hari, I am not aware of any IPR applicable to this draft that should be disclosed. Best Regards, Quan https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WG Adoption of draft-rajagopalan-pce-pcep-color-02

Hi WG, I support the adoption of this draft as a co-author. Color is useful to associate a TE tunnel or policy. It is reasonable to support the PCEP extensions for the path constraints and optimization objectives. Best Regards, Quan https://datatracker.ietf.org/doc/draft-rajagopalan-pce-p

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

Dear PCE WG, I support the WG LC of this draft. I reviewed this document in details and I think it is useful and reasonable for SRv6 networks with PCEP extension. Thanks the authors for the well-written draft and I have a suggestion for section 4.3.1 with text "V: The "SID verification" bit usag

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

Hi Cheng, Thanks for your reply! The suggested text maybe like this following shown. " * V: When this bit is set to 1, the PCC should perform the SID verification in validity of an Explicit Candidate Path as described in as per Section 5.1 of [RFC9256]. When a segment list of an expli

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

Hi Dhruv, Thanks for your reply! I agree with you and it is much better to align with SR-MPLS using LSP-ERROR-CODE TLV. Best Regards, Quan Original From: DhruvDhody To: 熊泉00091065; Cc: c...@huawei.com ;pce@ietf.org ;draft-chen-pce-sr-mpls-sid-verificat...@ietf.org ;zhan..

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

Hi Cheng, Thanks for your reply and update! Looks good to me with this version. Best Regards, Quan Original From: ChengLi To: 熊泉00091065;d...@dhruvdhody.com ; Cc: pce@ietf.org ;draft-chen-pce-sr-mpls-sid-verificat...@ietf.org ;Zhangka ; Date: 2023年03月06日 21:35 S

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

Dear Chairs and WG, I have read the new version and I support the WGLC. Some editorial suggestions are as following shown. In section 5.1, "Where: is as per [I-D.ietf-pce-pcep-extension-for-pce-controller]." It may update to RFC9050. In section 5.1, "Further only one and one kind of BPI, EPR

[Pce] FW: New Version Notification for draft-xiong-pce-detnet-bounded-latency-03.txt

Hi WG， I have submitted the draft-xiong-pce-detnet-bounded-latency-03[1] and resolve the comments from IETF115 and IETF116. The update from last version is as follows: A, change Deterministic Path Object to Deterministic Path ERO (DP-ERO) subobject due to the suggestion from Dhruv.

Re: [Pce] Proposed PCE WG Charter update

Dear Chairs and WG, I have read the proposed charter update text and I support rechartering. I think the updated rechartering has cover all the topics which WG is working on. Best Regards, Quan

Re: [Pce] WG Adoption of draft-chen-pce-bier-11

Hi Dhruv and WG, I support the adoption of this draft. I have reviewed the updated version and this draft can support the BIER-TE path establishment with PCEP extesnsions. The PCEP extensions is well-written including the BIER-TE related objects and procedures. Before adoption, I suggest to fix

Re: [Pce] WG Adoption of draft-chen-pce-bier-11

Hi Ran, The new version looks good to me! Thanks for your work. Best Regards, Quan Original From: 陈然00080434 To: 熊泉00091065;d...@dhruvdhody.com ;pce@ietf.org ; Cc: draft-chen-pce-b...@ietf.org ; Date: 2023年09月28日 08:59 Subject: Re: [Pce] WG Adoption of draft-chen-pce-bier-11 Hi Quan， Th

[Pce] Fw: New Version Notification for draft-peng-pce-entropy-label-position-10.txt

Dear Chairs and WG, I have updated the version of draft-peng-pce-entropy-label-position-10.txt. And the mainly update is the clarification about the MSD which is the comment from the IDR WG to corresponding BGP extensions [draft-ietf-idr-bgp-srmpls-elp]. The draft has been discussed in details.

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

Hi Dhruv, I support the adoption of this draft. Thanks for the work from authors. But I am confused about section 1 "PCEP extensions described in this document are applicable to all Path Setup Types". This draft mainly focus on the Circuit Style Policies and SR policy but path setup types inc

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

Hi Samuel, Thanks for your quick reply! Yes, I agree with you. The extensions may be applicable for RSVP-TE,SR,SRv6,native IP, but I am not sure about it with BIER-TE and PCECC. It works well for me to explicitly describe for each extension whether it is generic or applicable to specific setup t

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

Hi Samuel, Thanks for your detailed explanation! I am not sure either about the PCECC and BIER-TE. To me that I may recall, for example( maybe not right), the path-recomputation TLV is in the request message from PCC to PCE, but there is no request message in PCECC mode. And for BIER-TE, it may

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

Hi Samuel, Thanks for your work! Yes, I agree with you. It seems good to me with “PCEP extensions described in this document can be used with any Path Setup Type.” LOL. Best Regards, Quan Original From: SamuelSidor(ssidor) To: 熊泉00091065;d...@dhruvdhody.com ; Cc: draft-sidor-pce-circuit-st

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

Hi Samuel, Thanks for your work! The new version looks great to me! Best Regards, Quan Original From: SamuelSidor(ssidor) To: 熊泉00091065; Cc: d...@dhruvdhody.com ;draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org ;pce@ietf.org ; Date: 2023年12月15日 21:23 Subject: RE: [Pce] WG Ado

Re: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

Hi PCE WG, Authors,I have reviewed the latest version in details and I feel this draft is good written and I support the progression to RFC. And I have two minor suggestions. A，I noticed the [I-D.ietf-idr-segment-routing-te-policy] and [I-D.ietf-pce-multipath] are in the Normative References. I a

Re: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

Hi Mike, Thanks for your reply! I am not sure about this use case. From my understanding, serveral candidate paths may be associated to a SR policy in PCE environment, (if this may happen) but if all candidate paths are judged to invalid by PCE (for example as per draft-chen-pce-sr-policy-cp-va

Re: [Pce] IPR poll for draft-peng-pce-entropy-label-position

Hi Andrew, I am not aware of any IPR applicable to this draft that should be disclosed in accordance with IETF IPR rules. Thanks, Quan Original From: AndrewStone(Nokia) To: pce@ietf.org ;熊泉00091065;彭少富10053815;qinfeng...@chinamobile.com ;zhaojunf...@caict.ac.cn ;pce-chairs ; Date: 2024年0

Re: [Pce] WG Adoption of draft-peng-pce-entropy-label-position-10

Hi Dhruv and WG, I support the adoption as co-author. This draft is useful and reasonable for PCEP extensions to configure the entropy label positions in SR-MPLS networks as described in RFC8662. Thanks, Quan Original From: DhruvDhody To: pce@ietf.org ; Cc: pce-chairs ;draft-peng-pce-en

Re: [Pce] WG Adoption of draft-peng-pce-entropy-label-position-10

Hi Andrew, Thanks for your detailed review and suggestions! Much appreciated! Please see in line with [Quan]. - Is there any value in having a reference to draft-ietf-idr-bgp-srmpls-elp-00? From the read I don't see any other purpose than "this is also ongoing" and can likely be removed? [Qua

Re: [Pce] WG Adoption of draft-peng-pce-entropy-label-position-10

Hi Xuesong, Thanks for your support and comments! Much appreciated! Please see inline with [Quan]. 1. Introduction ...This document proposes a set of extensions for PCEP to configure the ELP information for SR- MPLS networks. " "ELP information" is mentioned here without clear definition (alt

Re: [Pce] WG Adoption of draft-peng-pce-entropy-label-position-10

Hi Andrew, Thanks for your reply! It seems we may agree on all comments. Please see inline with [Quan]. - Is there any value in having a reference to draft-ietf-idr-bgp-srmpls-elp-00? From the read I don't see any other purpose than "this is also ongoing" and can likely be removed? [Quan]: Th

Re: [Pce] WG Adoption of draft-peng-pce-entropy-label-position-10

Hi Ran, Thanks for your comments. I will fix the IANA request to "TBD1,2,3" in next version. Best Regards, Quan Original From: 陈然 To: d...@dhruvdhody.com ;pce@ietf.org ;draft-peng-pce-entropy-label-posit...@ietf.org ; Cc: pce-cha...@ietf.org ; Date: 2024年02月06日 09:05 Subject: Re: [Pce]

Re: [Pce] WG Adoption of draft-peng-pce-entropy-label-position-10

Hi Gyan, Thanks for your comments! This is a good question. From my understanding, RFC8662 did not describe the ERLD computation is required but specifuies that the ingress " should try to insert the minimum number of such pairs". Also as suggested by Andrew, the explaination will be added in

Re: [Pce] WG Adoption of draft-peng-pce-entropy-label-position-10

Hi Gyan, Thanks for your reply! The ELP computation is to compute the positions of the ELI/ELs which need to be inserted into the label stack and the computation should using the ERLD as an input parameter which can help to minimize the number of required ELI/EL pairs to be inserted. Agree wit

Re: [Pce] WG Adoption of draft-peng-pce-entropy-label-position-10

Hi Weiqiang, Thanks for your support and comments! Please see inline with [Quan]. Here I have some minor comments for the authors' consideration: 1. Section 2.1: Terminology Instead of solely referencing external documents for terminology, it would be beneficial to compile a dedicated list of te

Re: [Pce] WG Adoption of draft-peng-pce-entropy-label-position-10

Hi WG, Thanks for the review, suggestions and comments from Andrew Stone, Xuesong Geng, Ran Chen, Gyan Mishra and Weiqiang Cheng. Much appreciated! I have updated a new version and try to resolve all the comments based on the mailing list. Hope this version would be better for you.Thanks! A

Re: [Pce] WG Adoption of draft-peng-pce-entropy-label-position-10

Hi Samuel, Thanks for your detailed review and comments! Sorry for the delay due to the holiday.LoL. Happy Chinese New Year! Please see inline with [Quan]. Abstract: “…Label Indicator (ELI)/EL pairs SHOULD be inserted in the SR-MPLS label stack as per RFC8662…”. Is it good to start using req

Re: [Pce] WG Adoption of draft-peng-pce-entropy-label-position-10

Hi Samuel, Thanks for your reply! I am glad that most of your comments are addressed. The reason why I use the "SHOULD" is that "MUST" may be too strong which mentioned by Andrew's comment. I think it may be better to add PCErr message associated with "MUST" in case the PCE can not set it. So I

[Pce] Re: WG Adoption of draft-li-pce-controlled-id-space-16

Dear Chairs, I read the draft and support the adoption since it is reasonable to be an experimental draft. And it is useful to provide another option for PCECC model to collect the space information other than BGP-LS. But I am confused about the new TLV extensions which is used to advertise the

[Pce] Re: IPR poll for draft-ietf-pce-pcep-color

Hi Andrew, I am not aware of any IPR applicable to this draft that should be disclosed in accordance with IETF IPR rules. Sorry for the delay! I am not sure if I need to relply as a contributor. Thanks, Quan Original From: AndrewStone(Nokia) To: bala...@juniper.net ;vbee...@juniper.net

[Pce] Re: WGLC for draft-ietf-pce-pcep-color-04

Hi WG, I support the publication of this document since it resolve the RSVP-TE LSP to carry color attribute. I have a little suggestion for that it would be better to split the section 4 "TLV Format" into two sections to specify the Color TLV and Color capablity bit respectively. Sorry for the

[Pce] Re: Where the Controlled ID info shuold be carried/encoded?

Hi Cheng, Sorry for the late reply! This is a good question and I had proposed this issue when I replied the adoption call. I think it is appropriate to carry the information using PCEP-LS encoding such as the LS object. These TLV extensions is used to advertise the PCE-controlled ID spase to

[Pce] Re: I-D Action: draft-ietf-pce-sr-path-segment-10.txt

Hi Greg, Joel and all, Thanks for your discussion on the MPLS mailing list as following link shown~ https://mailarchive.ietf.org/arch/msg/mpls/e3CI8xeDN1OTu5FgAIB6tI_yRaY/ Allow me to take the discussion to PCE. As per RFC9545 and draft-ietf-spring-srv6-path-segment, a path segment can identify

[Pce] Re: I-D Action: draft-ietf-pce-sr-path-segment-10.txt

Hi Dhruv and Joel, Thanks for your suggestion! The adding texts in my last email mainly clarify the path segment related parameters (e.g association) within an SR policy. I think the PCE communicates with the tail instead of a notification, for example, as figure 3 shown, it send PCInitiate m

[Pce] Re: I-D Action: draft-ietf-pce-sr-path-segment-10.txt

Hi Cheng and Co-authors, I have updated the draft as discussed and the diff file is attached. Please review and comment and I will submit it before this weekend! Thanks! Best Regards, Quan Original From: ChengLi To: 熊泉00091065;d...@dhruvdhody.com ; Cc: pce@ietf.org ;draft-ietf-pce-sr-pa

[Pce] Re: I-D Action: draft-ietf-pce-sr-path-segment-10.txt

Hi Dhruv, Thanks for your review and suggestions! Please see inline with [Quan]. The new version is attached. Thanks! Best Regards, Quan Original From: DhruvDhody To: 熊泉00091065; Cc: c...@huawei.com ;draft-ietf-pce-sr-path-segm...@ietf.org ;pce@ietf.org ; Date: 2024年09月11日 23:26 Subject:

[Pce] 答复: PCEP extensions for SR-TP

Hi Marina, Thanks for your attention and comments! I think you have proposed a good question. The "path label " which my draft defined is inserted into ERO list and uniquely identifies a uni-directional path. So one label can be added to the Ingress ERO list for the forwarding dire

[Pce] 答复: RE: PCEP extensions for SR-TP

Hi Marina, Thanks for your comments! I understand your points now. I agree with you that two labels need to be added to the ERO sub-object list. That is forwarding path label and reverse path label. An And just one label will be inserted into the SR label stack and another one is sto

[Pce] 答复: RE: RE: PCEP extensions for SR-TP

Hi Marina, Thank you for the comments and suggestions! I have uodated the version of the draft. https://datatracker.ietf.org/doc/draft-xiong-pce-pcep-extension-sr-tp/ I still add the path label extension into the SR-ERO. The path is similiar with SR node or adjacency and we vie

Re: [Pce] Backward compatibility with earlier version of draft-ietf-pce-segment-routing

Hi Dhruv, I support to keep the Backward compatibility with earlier version. We have implemented the earlier version of using SR-PCE-CAPABILITY-TLV as the top-level TLV carried in OPEN message. SR Capibility exchange errors has appeared in the operator test while old and new implementations coe

Re: [Pce] WG Adoption Call for draft-negi-pce-segment-routing-ipv6

Hi all, Yes/Support. This draft proposes the extensions in SRv6 networks which is necessary for PCEP protocol. Thanks, Quan Hi WG, Please read & review draft-negi-pce-segment-routing-ipv6-04 [1] and send your comments to the mailing list. Should this draft be adopted by the PCE W

[Pce] 答复: SR-MPLS-TP: Question on draft-xiong-pce-pcep-extension-sr-tp

Hi Loa, Thanks for your review and inspired comment! It is very important and much appreciated. Refer to your question, we proposed the terminology of the "SR-MPLS-TP" in the following use case draft. https://datatracker.ietf.org/doc/draft-hu-mpls-sr-inter-domain-use-cases/ We pl

[Pce] 答复: Quick Review of SR Inter-domain and association

Hi Dhruv, Thanks for your review and suggestions! It is very appreciated! My clarification is as follows tagged with Quan>>. Best Regards, Quan <>I agree with you and thanks for your suggestion. The Stitching LSP association is created and maintained at parent PCE. The St

[Pce] 答复: Quick Review of SR Inter-domain and association

Hi Dhruv, Thanks for your reply! My clarification is as follows tagged with Quan>>. Best Regards, Quan 原始邮件 发件人：DhruvDhody 收件人：熊泉00091065; 抄送人：draft-xiong-pce-stateful-pce-sr-inter-dom...@ietf.org ;draft-hu-pce-stitching-lsp-associat...@ietf.org ;pce@ietf.org ; 日 期 ：2

Re: [Pce] Adrian stepping down as PCE co-chair

Thanks for the hard work to Adrian! It is very appreciated! Best wishes, Quan "BRUNGARD, DEBORAH A" Wed, 11 September 2019 20:14 UTCShow header Hi, As we noted earlier, Adrian stepped in to help us with the PCE document queue and help bring Dhruv on as a new chair. He has d

[Pce] Comments about the LSP Object Flag field

Hi all, As defined in [RFC8231], the length of LSP Object Flag field is 12 bits and it defined the value from bit 5 to bit 11. The bits from 1 to 3 are defined in [RFC8623] and the bit value 4 is used in [RFC8281]. So all bits of the flag has been occupied as the following shown.

[Pce] 答复: IPR Poll on draft-li-pce-sr-path-segment-08

Hi Hari and WG, I am not aware of any IPR applicable to this draft that should be disclosed in accordance with IETF IPR rules. Quan 原始邮件 发件人：HariharanAnanthakrishnan 收件人：chengl...@huawei.com ;mach.c...@huawei.com ;chengweiqi...@chinamobile.com ;jie.d...@huawei.com ;li

Re: [Pce] Adoption of draft-li-pce-sr-path-segment?

Hi WG, Support as a co-author. I think the draft is mature and steady and being implemented by ZTE Product. I support the adoption of this draft. Best Regards, Quan <<[Pce] Adoption of draft-li-pce-sr-path-segment? Wed, 25 September 2019 16:20 UTCShow header Hi PCE WG, In our ado

[Pce] [pce] :New Version Notification for draft-xiong-pce-lsp-flag-00.txt

Hi all, I have summitted the draft which proposes a new LSP-EXTENDED-FLAG TLV for LSP object to extend the length of the flag field. Could you please give me some suggestions about the format? Thanks, Quan 原始邮件 发件人：internet-dra...@ietf.org 收件人：熊泉00091065; 日 期 ：2019

[Pce] 答复: [pce] :New Version Notification for draft-xiong-pce-lsp-flag-00.txt

Hi Dhruv and Adrian, Thanks a lot for reviewing my draft and all your comments and suggestions are very appreciated! I agree with you and I will update the draft and fix it as follows: a, remove the repeat format of the existing LSP object. b, remove the ues bit 0 to indicate the L

[Pce] 答复: [pce] :New Version Notification for draft-xiong-pce-lsp-flag-00.txt

Hi Adrian and Dhruv, Thanks for your suggestion! I will consider the option as defined in RFC5088. I will update the draft as we discussed as soon as possible. More comments and suggestions are welcome! Best Regards, Quan 原始邮件 发件人：AdrianFarrel 收件人：'Dhruv Dhody' ;熊泉0

[Pce] 答复: IPR Poll on draft-li-pce-sr-bidir-path-06

Hi Hari, Thanks for your work! I am not aware of any IPR applicable to this draft that should be disclosed in accordance with IETF IPR rules. Thanks, Quan 原始邮件 发件人：HariharanAnanthakrishnan 收件人：chengl...@huawei.com ;mach.c...@huawei.com ;chengweiqi...@chin

Re: [Pce] Adoption of draft-li-pce-sr-bidir-path-06?

Dear Chairs, I support as a co-author. Thanks, Quan <<[Pce] Adoption of draft-li-pce-sr-bidir-path-06? Fri, 17 January 2020 10:12 UTCShow header Hi all, It is time to share your thoughts about draft-li-pce-sr-bidir-path-06. Do you believe the I-D is a right foundation for a PC

[Pce] Re: Path segment supporting multiple segment lists in a candidate path

Hi Dhruv, Thanks for your reply! I will take your suggestion for the new version. But I have two concerns. The PSID is defined as "SRv6 Path Segment Identifier" in draft-ietf-spring-srv6-path-segment and it is not mentioned in this documents , cause path segment should cover both SR-MPLS and SR

[Pce] Re: Path segment supporting multiple segment lists in a candidate path

Hi Dhruv, Thanks very much for your detailed revision! It looks much better to me. The new version diff is attatched. Thanks! Best Regards, Quan Original From: DhruvDhody To: 熊泉00091065; Cc: c...@huawei.com ;pce@ietf.org ;draft-ietf-pce-sr-path-segm...@ietf.org ; Date: 2024年09月25日 20

[Pce] Re: Path segment supporting multiple segment lists in a candidate path

Hi Cheng, Thanks for your suggestion! Got it about the PSID. And I also agree with the P flag in LSP. So I suggest to clarify it and the adding text may be as following shown. 4.5. Path Attributes Object The [I-D.ietf-pce-multipath] defines the PATH-ATTRIB object, which carries

[Pce] Path segment supporting multiple segment lists in a candidate path

Hi PCE WG, A new version has been submitted as per https://www.ietf.org/archive/id/draft-ietf-pce-sr-path-segment-11.txt. But in case of supporting multiple segment lists in a candidate path, it is required to add Path Segment TLV into Path Attributes Object as different path segment may iden

[Pce] Re: WG Last Call for draft-ietf-pce-iana-update

Hi Julien and PCE WG, Thanks for the useful and meaningful work! I support the progress of this document. I am a liitle confused that why RFC9357 is listed as informative references while other PCEP registries are listed as normative references. Thanks! Best Regards, Quan <<[Pce] WG Last Ca

[Pce] Re: WG Last Call for draft-ietf-pce-iana-update

Hi Dhruv, Thanks for your quick update! The new version looks great to me. Thanks! Best Regards, Quan Original From: DhruvDhody To: adr...@olddog.co.uk ; Cc: 熊泉00091065;julien.meu...@orange.com ;pce@ietf.org ; Date: 2024年09月18日 17:05 Subject: Re: [Pce] Re: WG Last Call for draft-ietf-p

[Pce] Re: WG Adoption of draft-fizgeer-pce-pcep-bfd-parameters-03

Hi, I agree with Reshad. I just read this draft and I am confused with the missing background and references about the S-BFD. For example, in section 4.3.2.2 and 4.3.2.3, it would be better to add explanations about the parameters such as the "Multiplier" and "Remote Discriminator". Regards,

[Pce] Re: WGLC for draft-ietf-pce-state-sync-11

Hi PCE WG and authors, Thanks for your hard work. I read this document and support the WG LC. And It would be much better if the following two comments can be addressed. 1,in section 3.3, the reference may be indicated when LSP-DB-VERSION TLV is first mentioned. 2,in section 6, a new PCEP-PATH-VE

[Pce] Re: WG Adoption of draft-koldychev-pce-operational-09

Hi WG, I think this document is useful and it helps me to understand the aspects of PCEP database. I support the adoption as an informational I-D. But I suggest to fix the following problems before adoption. 1,When I read this document, I found it a little hard to understand with the editorial

[Pce] Re: WG Adoption of draft-koldychev-pce-operational-09

Hi Andrew, Thanks for your clarification! It is much better for understanding. It would be better to add your explanation into the section 4.1 and remove the sentence "A Tunnel is identified by PLSP-ID". And from my veiw, the LSPs and Tunnels are all RSVP-signaled objects. But in PCEP-sepcific

[Pce] Re: WG Last Call for draft-ietf-pce-flexible-grid

Hi WG, I have read this document and I support the publication. But I have a minor suggestion about the SA object in section 4. If the Frequency Slot Selection TLV and Frequency Slot Restriction Constraint TLV are the optional TLVs, I suggest to remove them in Figure 2 as following shown. 0

[Pce] Fw: New Version Notification for draft-xpbs-pce-topology-filter-03.txt

Hi all, The authors submitted a new version -03 which has a big revision. Since the reference I-D.ietf-teas-yang-topology-filter has been adopted by TEAS WG, it will be a good start for us to discuss it in PCE WG. The update from last version is like following: 1, change TOPOLOGY Object to TOP

[Pce] Comments and revision on draft-xpbs-pce topology-filter

Hi WG, Thanks for all your great comments and suggestions from Dhruv, Andrew, Zafar and Samuel!They are very appreciated! The authors posted a new -04 version and the main updates are as following shown. A, The IGP domain identifier has been splited into optional TLVs as Dhruv suggested and t

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

Dear WG I have read this document and support WG adoption of this I-D which proposes extensions to support branch node handling needed for P2MP. And I also suggest to add an PCECC P2MP LSP setup sequence in section 4.3.3.1 to better speicify the use case with 3 instances of CCI objects in the P