[Pce] 答复: AD review of draft-ietf-pce-pcep-extension-native-ip-30
Hi, John: I have uploaded the updated version at https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-native-ip-32 and wish it address all your concerns. If there is no more comments, we can put forward it to the IESG LC review then. Thanks in advance for your efforts! Some detail replies can see inline below. Best Regards Aijun Wang China Telecom 发件人: forwardingalgori...@ietf.org <mailto:forwardingalgori...@ietf.org> [mailto:forwardingalgori...@ietf.org] 代表 【外部账号】 John Scudder 发送时间: 2024年7月26日 23:59 收件人: Aijun Wang mailto:wangai...@tsinghua.org.cn> > 抄送: draft-ietf-pce-pcep-extension-native...@ietf.org <mailto:draft-ietf-pce-pcep-extension-native...@ietf.org> ; pce@ietf.org <mailto:pce@ietf.org> ; bhassa...@yahoo.com <mailto:bhassa...@yahoo.com> ; fsh...@huawei.com <mailto:fsh...@huawei.com> ; tan...@huawei.com <mailto:tan...@huawei.com> ; zhu.ch...@zte.com.cn <mailto:zhu.ch...@zte.com.cn> 主题: Re: AD review of draft-ietf-pce-pcep-extension-native-ip-30 Hi Aijun, Thanks for the update. I have a few more comments, below. I have trimmed for brevity, indicated by […], anything trimmed is agreed or anyway doesn’t need more discussion. If you can update to reflect these comments I think we can send it for IETF last call. On Jul 22, 2024, at 5:37 AM, Aijun Wang mailto:wangai...@tsinghua.org.cn> > wrote: Hi, John: I have updated draft according to your suggestions at <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-native-ip__;!!NEt6yMaO-gk!B09SQ9s42Y1hsFo8BANfznJ4lysLpngvzlzwp9ULLAbS_FzVRmaT6Jx-RsCqbWt6uHiW1t3973FwFYcuh7li0A$> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-native-ip__;!!NEt6yMaO-gk!B09SQ9s42Y1hsFo8BANfznJ4lysLpngvzlzwp9ULLAbS_FzVRmaT6Jx-RsCqbWt6uHiW1t3973FwFYcuh7li0A$ For the document track, I think it is OK to move it forward as the experimental track, we will try to update it later to the standard track after its experimental deployment. The detail responses are inline below【WAJ】 If there is more suggestions, please let us know. Or else, can we schedule the IESG Last Call then? Best Regards Aijun Wang China Telecom […] During the establishment procedure, PCC should report to the PCE the status of the BGP session via the PCRpt message, with the status @@ -453,7 +547,16 @@ When PCC receives this message with the R bit set to 1 in SRP object in PCInitiate message, the PCC should clear the BGP session that is indicated by the BPI object. ++--- +jgs: The term "clear the BGP session" isn't standard (although it is +common colloquial usage). Looking at RFC 4271, in one place (Section 3) +it does talk about "resetting any BGP connections" so I think you would +be on firm ground if you want to say "reset". Or you might consider +referencing the AutomaticStop event (RFC 4271, Section 8.1.2, Event 8). 【WAJ】： Here, “clear the BGP session” is just want to express the deletion of the BGP configuration on PCC, not reset the BGP connection. Should it be more clearer, if we instead say "clear the BGP session configuration"?--Have updated the descriptions accordingly. Yes, that’s an improvement. This leaves it ambiguous whether the session should be torn down immediately or not, do you intend that? E.g. in some implementations, a configuration change is not reflected in the operational state until a commit (or equivalent) is performed. 【WAJ】How about “the PCC should clear the BGP configuration and tear down the BGP session that is indicated by the BPI object.”? I think it is more clear. I have updated the contents according to the above statements. […] Such explicit routes operate the same as static routes installed by network management protocols (Network Configuration Protocol (NETCONF)/YANG). The procedures of such explicit route addition and @@ -582,6 +689,9 @@ The PCInitiate message should be sent to the on-path routers respectively. In the example, for explicit route from R1 to R7, the ++--- +jgs: What does “respectively” mean here? Can it be removed? 【WAJ】Here, we just want to describe such message should be sent every router on the path, each may has different content, for example, the different next hop information. OK thanks. In that case, while removing the word “respectively” would be enough, I suggest you revise it to use the language you’ve used above. That is, OLD: The PCInitiate message should be sent to the on-path routers respectively. NEW: The PCInitiate message should be sent to every router on the path. 【WAJ】Done […] BGP Peer Info Object-Class is 46 BGP Peer Info Object-Type is 1 for IPv4 and 2 for IPv6 @@ -1071,6 +1233,10 @@ - 2: Peer IP can't be reached, BGP Session Failure -
[Pce] 答复: New draft to update IANA registration policy
Hi, Dhruv: Thanks for your quick draft. I think IETF review is enough because the required RFCs needs to be passed all the same stages Although there maybe some different criteria, the related RFCs can assure the interoperability of protocol from different vendors. The document is written clearly. If there is no objection, we can move it faster to be published. Best Regards Aijun Wang China Telecom 发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 Dhruv Dhody 发送时间: 2024年7月23日 5:19 收件人: pce@ietf.org 主题: [Pce] New draft to update IANA registration policy Hi, I have written a small draft to update the registration policy for all "standards action" to "IETF review" for PCEP registry. https://datatracker.ietf.org/doc/draft-dhody-pce-iana-update/ The approach that the draft currently takes is to make a blanket change to IETF-review for all "standards action" registry to allow experimental track documents to request allocation. There are some registries where the space is tight but IMHO IETF-review is fine -- our WG and LC process should be enough to handle the case of less bits which ideally require creating a new field/registry as we did in the past for LSP object flags! Thoughts? It might be a good idea to move this quickly as John suggested in his AD review of Native-IP draft [1]. Thanks! Dhruv [1] https://mailarchive.ietf.org/arch/msg/pce/xBn2_9E9vy6h5AnYEMMf3I9vbqM/ ___ Pce mailing list -- pce@ietf.org To unsubscribe send an email to pce-le...@ietf.org
[Pce] 答复: AD review of draft-ietf-pce-pcep-extension-native-ip-30
Hi, John: I have updated draft according to your suggestions at https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-native-ip For the document track, I think it is OK to move it forward as the experimental track, we will try to update it later to the standard track after its experimental deployment. The detail responses are inline below【WAJ】 If there is more suggestions, please let us know. Or else, can we schedule the IESG Last Call then? Best Regards Aijun Wang China Telecom -邮件原件- 发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 【外部账号】 John Scudder 发送时间: 2024年7月20日 4:35 收件人: draft-ietf-pce-pcep-extension-native...@ietf.org; pce@ietf.org 抄送: bhassa...@yahoo.com; fsh...@huawei.com; tan...@huawei.com; Aijun Wang ; zhu.ch...@zte.com.cn 主题: AD review of draft-ietf-pce-pcep-extension-native-ip-30 Hi Authors, Working Group, Thanks for this document and your patience while I worked through it. I have several comments below, in line with the text according to my usual practice -- I’ve supplied my questions and comments in the form of an edited copy of the draft. Questions and comments are made in-line and prefixed with “jgs:”. You can use your favorite diff tool to review them; I’ve attached the iddiff output for your convenience if you’d like to use it. I’ve also pasted a traditional diff below in case you want to use it for in-line reply. I also have one general concern to bring up here. My general concern is that it will be hard to move forward as a Standards Track document, without significant updates. I don't want to put you through that unless you are eager to put in the extra work. By contrast, I think the document is nearly ready for publication as an Experimental document. Reviewing the Shepherd write-up, it appears this proposal has already been discussed, and I want to suggest it again as a practical, lower-effort, way forward. Two examples of aspects of the document that would need work before it's ready for publication on the Standards Track are its security posture, and its precision of description of elements of procedure. Regarding the security posture, I've put specific suggestions in the Security Considerations that would bring it up to (what I consider) an acceptable level for an Experimental document. See those suggestions for an outline of work that would have to be completed before ready for Standards Track. Regarding elements of procedure, there are various points in the document that provide quick hints about how the protocol should be used. One example is in Section 5.1 (chosen only because I happened to have it open on my screen): "To cleanup the existing Native IP instructions, the SRP object MUST set the R (remove) bit." This is probably clear enough to experienced PCEP and BGP practitioners, and so I judge it adequate for an experimental document. For a Standards Track document, I would want you to provide more detail about exactly what you mean, that doesn't assume as much expertise. I’ve flagged a few others in the document as I've reviewed it, but not comprehensively. If you decide to stick with Standards Track I'd need to do a second pass to provide this level of critique. One sticking point about moving to Experimental would be the allocation you make from the PCECC-CAPABILITY sub-TLV, which has a Standards Action policy. I would propose to remedy this by asking the WG to write and progress a tiny draft to reclassify that sub-registry suitably, for example to IETF Review. Note that this wouldn't need to hold up progress, since there is already a temporary allocation, which can be extended if there is adopted work to reclassify the registry. (The WG might consider at the same time, whether to reclassify some of the other Standards Action sub-registries, and I’ve suggested you consider whether you want to make your own new sub-registries SA or if IETF Review might be better). Finally, I want to flag to the WG as a whole my suggestion to add a new boilerplate section to be used with all PCE docs that use RBNF, going forward (see first comment in my review). Regards, —John --- draft-ietf-pce-pcep-extension-native-ip-30.txt 2024-07-18 15:55:14 +++ draft-ietf-pce-pcep-extension-native-ip-30-jgs-comments.txt 2024-07-19 16:28:15 @@ -159,8 +159,25 @@ 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. ++--- +jgs: (For further context see my comment on Section 5.1.) +I propose that from now on, PCE documents that use RBNF should include +a statement to this effect: + +``` +2.1. Use of RBNF + +The message formats in this document are illustrated using Routing +Backus-Naur Form (RBNF) encoding, as specified in [RFC5511]. The use of +RBNF is illustrative only and may elide certain important details; the +normative specification of messages is found in the prose description. +If there is any divergence betwee
[Pce] 答复: IPR poll for draft-li-pce-controlled-id-space
I am not aware of any IPR applicable to this draft that should be disclosed in accordance with IETF IPR rules. Best Regards Aijun Wang China Telecom 发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 Andrew Stone (Nokia) 发送时间: 2024年5月18日 3:19 收件人: Dhruv Dhody ; mach.c...@huawei.com; lizhen...@huawei.com; jie.d...@huawei.com; Cheng Li ; shiha...@huawei.com; wang...@chinatelecom.cn; chengweiqi...@chinamobile.com; chaozhou...@yahoo.com; pce@ietf.org; pce-cha...@ietf.org 主题: [Pce] IPR poll for draft-li-pce-controlled-id-space 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 To unsubscribe send an email to pce-le...@ietf.org
Re: [Pce] Adoption Poll for draft-dhodylee-pce-pcep-ls
Support for its forwarding.PCEP has almost all the corresponding parts of BGP to control the devices, implement and deploy the PCEP-LS can assist the simplification of SDN controller/PCE.Aijun WangChina TelecomOn Apr 13, 2024, at 00:34, daniele.i...@gmail.com wrote:Hi Julien, all, Adrian got the point. It would be an interesting experiment to see. And yes, the idea of PCEP-LS started from those cases where PCEP is there and BGP is not, hence I support (as author) the adoption of the draft. Cheers,Daniele From: Pce On Behalf Of Adrian FarrelSent: Thursday, April 4, 2024 7:17 PMTo: julien.meu...@orange.com; pce@ietf.orgSubject: Re: [Pce] Adoption Poll for draft-dhodylee-pce-pcep-ls Thanks, Julien. Once upon a time, I was quite skeptical about this idea, and unhappy to see it progress. But I have become used to the idea, and two things help me believe we should adopt this: 1. As an Experiment, this can be tried out and we can see how well it works. If it is nonsense, no harm done. The authors' willingness to proceed as Experimental is reassuring. 2. The applicability to optical networks (separate draft) is convincing because it is easier to believe that optical devices do not want to add BGP-LS to their code stack (even if it is only a couple of thpusand lines of code). So, I support adoption and commit to working with the authors to improve the draft. I think the current description of the Experiment is pretty good, but work will be needed to sort out the IANA stuff. I just posted a draft to help with Experimental Error-Types. Best, Adrian On 04/04/2024 18:18 CEST julien.meu...@orange.com wrote: 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 ___Pce mailing listPce@ietf.orghttps://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-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. Aijun Wang China Telecom > On Apr 5, 2024, at 23:14, Andrew Stone (Nokia) wrote: > > > 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
[Pce] 答复: WGLC for draft-ietf-pce-stateful-pce-optional-07
Support for its forwarding. Best Regards Aijun Wang 发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 Dhruv Dhody 发送时间: 2024年3月7日 18:21 收件人: pce@ietf.org 抄送: pce-chairs ; draft-ietf-pce-stateful-pce-optio...@ietf.org 主题: Re: [Pce] WGLC for draft-ietf-pce-stateful-pce-optional-07 Hi WG, Considering this is a busy time just before the IETF meeting, we are extending the WGLC for a week. Please respond by Thursday March 14th. It is important to be explicitly vocal during the last call and we request you to please respond to this thread. Thanks! Dhruv On Wed, Feb 21, 2024 at 3:02 PM Dhruv Dhody mailto:d...@dhruvdhody.com> > wrote: Hi WG, This email starts a 3-weeks working group last call for draft-ietf-pce-stateful-pce-optional-07. https://www.ietf.org/archive/id/draft-ietf-pce-stateful-pce-optional-07.html 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 13 March 2024. A general reminder to the WG to be more vocal during the last-call/adoption. Thanks, Dhruv & Julien ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[Pce] 答复: Secdir early review of draft-ietf-pce-pcep-extension-native-ip-29
Hi, Ned: Thanks for your review. Some detail replies are inline below. If you have no further comments, I will upload it to address your concerns/comments then. Aijun Wang -邮件原件- 发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 Ned Smith via Datatracker 发送时间: 2024年2月1日 3:54 收件人: sec...@ietf.org 抄送: draft-ietf-pce-pcep-extension-native-ip@ietf.org; pce@ietf.org 主题: [Pce] Secdir early review of draft-ietf-pce-pcep-extension-native-ip-29 Reviewer: Ned Smith Review result: Has Nits 1) Section 5 header should capitalize "messages" 【WAJ】：Done, together with the sub section 5.1 and 5.2 2) The introduction says, "It is necessary to use the central control mode described in [RFC8283]". This reads like a mandatory constraint on implementers but is listed as an informative reference. If the I-D doesn't actually depend on RFC8283, but the authors are assuming this context, then the wording could be adjusted to describe the author's assumptions rather than describe it in (almost) normative style. Alternatively, it is a normative requirement that shouldn't exist in the introduction and the reference should move to the normative list. 【WAJ】We would like to keep it as an informative reference. How about the following description:(change "necessary" to "feasible") "It is feasible to use the central control mode described in RFC 8283... ... " or your suggestions? 3) Figure 16 - It isn't clear if TBD1 and TBD2 are gaps in the I-D that the WG has yet to complete vs. extension / extensibility properties that a subsequent I-D might define. 【WAJ】TBD1 and TBD2 will be assigned the values by the IANA later. They are added after the other early IANA temporary allocations. 4) Section 10 "The communication of PCE and PCC described in this document should also follow the same procedures, treat the three newly defined objects (BPI, EPR, PPA) associated with the same symbolic path name as the attribute of the same path in the LSP-DB (LSP State Database)." The "should" in this sentence reads as though it is normative. Consider making it upper case. The sentence is potentially easily misread as it isn't clear which procedures is meant by "...the same procedures,...". 【WAJ】How about the following descriptions: The communication of PCE and PCC described in this document SHOULD follow the state synchronization procedures described in RFC8232, treat the three newly defined objects (BPI, EPR, PPA) associated with the same symbolic path name as the attribute of the same path in the LSP-DB (LSP State Database). ___ 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] 答复: Opsdir early review of draft-ietf-pce-pcep-extension-native-ip-29
Hi, Sheng: Thanks for your review. I have updated the draft to address your concerns/comments, and will upload it together with other reviews. Aijun Wang -邮件原件- 发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 Sheng Jiang via Datatracker 发送时间: 2024年1月30日 22:56 收件人: ops-...@ietf.org 抄送: draft-ietf-pce-pcep-extension-native-ip@ietf.org; pce@ietf.org 主题: [Pce] Opsdir early review of draft-ietf-pce-pcep-extension-native-ip-29 Reviewer: Sheng Jiang Review result: Has Nits I have reviewed this document as part of the OPS directorate's ongoing effort to review all IETF documents being processed by the IESG. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Document: draft-ietf-pce-pcep-extension-native-ip-29 Reviewer: Sheng Jiang Review Date: 2024-01-30 Result: Has Nits This Standards Track document defines the Path Computation Element Communication Protocol (PCEP) extension for Central Control Dynamic Routing (CCDR) based applications in Native IP networks. 114: requireHs --> requires 127: nexthops --> next hops 464: lead --> leads 618: nexthop --> next hop 702: soley --> solely 845: multihop --> multi-hop There are many places that the "s" after the third person singular verbs are missing. ___ 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] 答复: 答复: I-D Action: draft-ietf-pce-pcep-extension-native-ip-28.txt
Hi, Dhruv: Thanks for your careful reviews and updates! I have uploaded the updated version of this draft, with some additional editorial corrections. Let’s set it to the IESG/John review then. Happy New Year to you, and to all PCE experts! Some additional replies are inline below. Best Regards Aijun Wang China Telecom 发件人: Dhruv Dhody [mailto:d...@dhruvdhody.com] 发送时间: 2023年12月28日 20:09 收件人: Aijun Wang 抄送: pce@ietf.org 主题: Re: [Pce] 答复: I-D Action: draft-ietf-pce-pcep-extension-native-ip-28.txt Hi Aijun, I did one more pass. This time I have gone ahead and made an update and created -29 xml directly (to save up on back and forth time). If you are happy with the changes that I have made please go ahead and post it and we should be ready to send this to IESG/John. The main changes are - (1) Two error conditions related to the capability exchange are added 【WAJ】THANKS! (2) RBNF was incorrect, we need both CCI and one of the (BPI, EPR and PPA) objects. It was mistakenly sending either CCI or (BPI, EPR and PPA) objects before! 【WAJ】THANKS! (3) Figures were crossing 72 characters limit and thus reformatted 【WAJ】THANKS! the new format looks more friendly (4) The order of message exchange for EPR was incorrect in the figures 【WAJ】THANKS! As indicated in the document, the EPR object should be sent to the PCCs in the reverse order of the E2E path. (5) IANA considerations was updated 【WAJ】THANKS! (6) Many editorial changes 【WAJ】THANKS! Additional major editorial changes are the followings: A: T bit should be also bit 7 in the description of section 7.2(BGP Peer Info Object) B: “If some traffic enter into the network via the R2 router to router R7”---à “If some traffic enter into the network via the R2 router, pass through R5 and exit at R7” Please find the attached files. Thanks! Dhruv On Wed, Nov 15, 2023 at 2:27 PM Aijun Wang mailto:wangai...@tsinghua.org.cn> > wrote: Hi, Dhruv and All: We updated the draft to address the comments received during the IETF 118 meeting. The main update contents are the followings: 1) Add the explanation of "Raw Mode" and "Tunnel Mode" 2) Add the "error code" field within the BPI object and the definition of "error code" 3) Some editorial updates. Please let me know if the above updates address your concerns? Best Regards Aijun Wang China Telecom -邮件原件- 发件人: forwardingalgori...@ietf.org <mailto:forwardingalgori...@ietf.org> [mailto:forwardingalgori...@ietf.org <mailto:forwardingalgori...@ietf.org> ] 代表 internet-dra...@ietf.org <mailto:internet-dra...@ietf.org> 发送时间: 2023年11月15日 16:54 收件人: i-d-annou...@ietf.org <mailto:i-d-annou...@ietf.org> 抄送: pce@ietf.org <mailto:pce@ietf.org> 主题: [Pce] I-D Action: draft-ietf-pce-pcep-extension-native-ip-28.txt Internet-Draft draft-ietf-pce-pcep-extension-native-ip-28.txt is now available. It is a work item of the Path Computation Element (PCE) WG of the IETF. Title: Path Computation Element Communication Protocol (PCEP) Extensions for Native IP Networks Authors: Aijun Wang Boris Khasanov Sheng Fang Ren Tan Chun Zhu Name:draft-ietf-pce-pcep-extension-native-ip-28.txt Pages: 33 Dates: 2023-11-15 Abstract: This document defines the Path Computation Element Communication Protocol (PCEP) extension for Central Control Dynamic Routing (CCDR) based applications in Native IP networks. It describes the key information that is transferred between Path Computation Element (PCE) and Path Computation Clients (PCC) to accomplish the End to End (E2E) traffic assurance in the Native IP network under PCE as a central controller. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/ There is also an HTMLized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-native-i <https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-native-ip-28> p-28 A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-pcep-extension-nati <https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-pcep-extension-native-ip-28> ve-ip-28 Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts ___ Pce mailing list Pce@ietf.org <mailto:Pce@ietf.org> https://www.ietf.org/mailman/listinfo/pce ___ Pce mailing list Pce@ietf.org <mailto:Pce@ietf.org> https://www.ietf.org/mailman/listinfo/pce ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[Pce] 答复: I-D Action: draft-ietf-pce-pcep-extension-native-ip-28.txt
Hi, Dhruv and All: We updated the draft to address the comments received during the IETF 118 meeting. The main update contents are the followings: 1) Add the explanation of "Raw Mode" and "Tunnel Mode" 2) Add the "error code" field within the BPI object and the definition of "error code" 3) Some editorial updates. Please let me know if the above updates address your concerns? Best Regards Aijun Wang China Telecom -邮件原件- 发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 internet-dra...@ietf.org 发送时间: 2023年11月15日 16:54 收件人: i-d-annou...@ietf.org 抄送: pce@ietf.org 主题: [Pce] I-D Action: draft-ietf-pce-pcep-extension-native-ip-28.txt Internet-Draft draft-ietf-pce-pcep-extension-native-ip-28.txt is now available. It is a work item of the Path Computation Element (PCE) WG of the IETF. Title: Path Computation Element Communication Protocol (PCEP) Extensions for Native IP Networks Authors: Aijun Wang Boris Khasanov Sheng Fang Ren Tan Chun Zhu Name:draft-ietf-pce-pcep-extension-native-ip-28.txt Pages: 33 Dates: 2023-11-15 Abstract: This document defines the Path Computation Element Communication Protocol (PCEP) extension for Central Control Dynamic Routing (CCDR) based applications in Native IP networks. It describes the key information that is transferred between Path Computation Element (PCE) and Path Computation Clients (PCC) to accomplish the End to End (E2E) traffic assurance in the Native IP network under PCE as a central controller. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/ There is also an HTMLized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-native-i p-28 A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-pcep-extension-nati ve-ip-28 Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts ___ 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] 答复: Call for slot in the PCE WG at IETF 118
Hi, Dhruv: I would like to ask one time slot to present the major changes to draft https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/ The presentation information are the followings below: - the draft(s) you want to discuss: https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/ - the expected presenter name: Aijun Wang/China Telecom - will you be attending in-person or remote: In-Person - the requested duration, including question time as part of the slot: 15 Minutes - the reason why you want to be on the agenda; What do you want to achieve? Why is a presentation necessary to achieve it? To get the feedbacks and make consensus on some significant updates. Best Regards Aijun Wang China Telecom 发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 Dhruv Dhody 发送时间: 2023年10月22日 15:06 收件人: pce@ietf.org 抄送: pce-chairs 主题: Re: [Pce] Call for slot in the PCE WG at IETF 118 Hi, Gentle reminder to make your slot requests by tomorrow! Thanks! PCE Chairs & Secretary On Sat, Oct 7, 2023 at 4:16 PM Dhruv Dhody mailto:d...@dhruvdhody.com> > wrote: Hi, The PCE WG would be meeting during the IETF 118 [1] week. If you need agenda time to progress some work, please send a slot request directly to the chairs/secretary mailto:pce-cha...@ietf.org> > by Monday, Oct 23rd by including: - the draft(s) you want to discuss, - the expected presenter name, - will you be attending in-person or remote - the requested duration, including question time as part of the slot, - the reason why you want to be on the agenda; What do you want to achieve? Why is a presentation necessary to achieve it? Please note - Asking for a slot does not mean you will get one. We will be prioritizing moving WG work first as well as drafts that were discussed on the mailing list. Please make sure to introduce your new draft or summarize an update on the mailing list. The last date to submit drafts is also Monday, Oct 23rd [2]. Also, let us know if you have requested agenda time in a different WG session for the same topic. Thanks! PCE Chairs & Secretary [1] https://datatracker.ietf.org/meeting/118/agenda.html [2] https://datatracker.ietf.org/meeting/important-dates/ ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[Pce] 答复: Document Shepherd Review of draft-ietf-pce-pcep-extension-native-ip-25
Hi, Dhruv: Thanks for your detail review！ We have updated the draft according to your suggestions, please check whether they address your concerns. The significant updates may be the followings: 1. Message flow procedures. I have updated the original table style to the flow chart style to reflect the time relationship between these messages. 2. BPI object encoding format to include the status field to reflect the BGP session status during the procedures. 3. Management Considerations. Detail responses are inline below. Best Regards Aijun Wang China Telecom 发件人: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] 代表 Dhruv Dhody 发送时间: 2023年8月31日 17:25 收件人: pce@ietf.org; draft-ietf-pce-pcep-extension-native...@ietf.org 主题: [Pce] Document Shepherd Review of draft-ietf-pce-pcep-extension-native-ip-25 # Document Shepherd Review of draft-ietf-pce-pcep-extension-native-ip-25 I have done a shepherd review of this I-D. I have some concerns that should be resolved before we send this to our AD. I continue to believe that this I-D is better suited as experimental; authors seem to disagree. 【WAJ】We would like to keep it in Standard track. ## Major - The use of the PCErr message to report an established BGP session as 'broken' is not right. The PCErr message is always sent in response to a message from a peer. We should use a PCRpt message with the status as 'down' in this case. Section 5.2 should also include the use of PCRpt messages during synchronization. 【WAJ】Have updated the BPI object encoding to include the “status” field, and uses it report the status of BGP session between BGP peers. - The I-D is silent on Native-IP path update procedures. I think this should be highlighted -- The EPR update is done as per the make-before-break procedures, i.e., the PCECC first updates new native-ip instructions based on the updated path and then informs the source node to switch traffic before cleaning up the former instructions as described in [RFC9050]. 【WAJ】 <https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-native-ip-25#section-6.2> https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-native-ip-25#section-6.2 has the corresponding descriptions: “In order to avoid the transient loop during the deploy of explicit peer route, the EPR object should be sent to the PCCs in the reverse order of the E2E path. To remove the explicit peer route, the EPR object should be sent to the PCCs in the same order of E2E path.” . And, based on your suggestions, add one more sentence in the end of this section：“If the PCE needs to update the path, it should first instruct new CCI with updated EPR corresponding to the new nexthop to use and then instruct the removal of older CCI” - Section 7.4, it is difficult to decode this object. All you have is the length of the full object from the object header and it is difficult to decode how many prefixes exist with additional TLV of variable length allowed. It is also unclear on the advantage of using RFC 3209 subobjects here since the mix of subobject types is anyway not allowed. I suggest changing this to - 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer IPv4 Address| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | No. of Prefix | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Prefix #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Prefix #1 Len | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | : | | : | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Prefix #n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Prefix #n Len | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Additional TLVs// +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 【WAJ】Update the associated encoding according to your suggestions。 - Section 9, I am worried about this - When the PCE sends out the PCInitiate message with the BPI object embedded to establish the BGP session between the PCC peers, it should wait enough time to get the BGP session successful establishment report from the underlay PCCs. If the PCE can't get such report
Re: [Pce] IPR poll for draft-chen-pce-bier-11
I am not aware of any IPR applicable to this draft that should be disclosed in accordance with IETF IPR rules. Aijun Wang > On Sep 26, 2023, at 05:16, Andrew Stone (Nokia) > wrote: > > > 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 ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[Pce] 答复: Rtgdir early review of draft-ietf-pce-pcep-extension-native-ip-23
Hi, Ines: Thanks for your review. I have updated the draft according to your suggestions. The detail replies are inline below: Best Regards Aijun Wang China Telecom -邮件原件- 发件人: Ines Robles via Datatracker [mailto:nore...@ietf.org] 发送时间: 2023年7月22日 0:47 收件人: rtg-...@ietf.org 抄送: draft-ietf-pce-pcep-extension-native-ip@ietf.org; pce@ietf.org 主题: Rtgdir early review of draft-ietf-pce-pcep-extension-native-ip-23 Reviewer: Ines Robles Review result: Has Issues Review: draft-ietf-pce-pcep-extension-native-ip-23 Reviewer: Ines Robles Summary: The document defines the Path Computation Element Communication Protocol (PCEP) extension for Central Control Dynamic Routing (CCDR) based application in Native IP network. No major issues found. Minor issues found as follows: Section 3: Terminology: * "The following terms are defined in this document" --> The following terminology is used in this document? Since the mentioned terms are not defined in the document, for example, the case of CCDR [WAJ] Update to the sentence as you suggested "The following terminology is used in this document" * Also, The document claims that it defines QoS, but it is not mentioned in the text. [WAJ] Delete it. Section 4.1: TBD1: Path is a Native IP path --> TBD1: Path is a Native IP TE path ? (To be aligned with IANA section description) [WAJ] Update Section 6: Error-value=TBD18, BPI/PPR --> Error-value=TBD18, BPI/PPA ? [WAJ] Update to BPI/PPA Section 6.1: "... Peer IP address)" closed parenthesis, but it is not open. [WAJ] Delete the parenthesis, also add some contents to the mentioned sentence. Figure 1: the arrow from PCE to R3 is bidirectional, the arrow from PCE to R1 and R7 are unidirectional, is this correct? [WAJ] They should be all bidirectional, updated. Section 6.2: "... explicit routes operate similar to static routes..." --> in which aspects is similar? in which aspects are dissimilar? [WAJ]Change the sentence to "Such explicit routes operate the same as static routes installed by network management protocol(NETCONF/YANG)" "...network management protocols..." --> it would be nice to add some examples of network management protocols between brackets. [WAJ] Added. One example, NETCONF/YANG Figure 2: The same as Fig. 1. The arrow from PCE to R1 is unidirectional, R2, R4 are bidirectional, is this correct? [WAJ] Bidirectional, Updated. Together with Figure 3&4 Section 9: "..cares only..." --> ...focuses only on...? [WAJ] Updated. Section 10: "...light weight BGP session setup..": It would be nice to add a reference to it. [WAJ] Delete the "light weight", because it is not one formal terminology. Section 12: Should the security considerations mention RFC9050? [WAJ] Added. Section 13.4: errors:: --> errors: [WAJ] Updated. Question: Should this document add a section for Manageability Considerations, like in RFC9050? [WAJ]Because there is no special consideration for the manageability considerations, I add one sentence at the section 10 "Deployment Considerations", as "Manageability considerations that described in RFC9050 should be followed" Thanks for this document, Ines. ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] Proposed PCE WG Charter update
Hi, Dhruv:This work for me.How about the proposed add item for the “milestone” then?Aijun WangChina TelecomOn Jul 7, 2023, at 18:03, Dhruv Dhody wrote:Hi Aijun,Two things, (1) We dont want a charter that is open-ended with the proposed text "...and other possible forward data plane"; the correct thing to do would be to do a quick recharter when we have something new. (2) Instead of adding a Native-IP in that list, we suggest using the term CCDR and club this with PCECC with this change -OLD:- In cooperation with the TEAS Working Group, development of PCE- based architectures for Traffic Engineering including PCE as a Central Controller (PCECC). The PCEP extensions are developed in the PCE Working Group.NEW:- In cooperation with the TEAS Working Group, development of PCE- based architectures for Traffic Engineering including PCE as a Central Controller (PCECC) and Central Control Dynamic Routing (CCDR). The PCEP extensions are developed in the PCE Working Group.ENDI made this change in GitHub - https://github.com/ietf-wg-pce/charter/tree/mainThanks! Dhruv & JulienOn Fri, Jul 7, 2023 at 6:47 AM Aijun Wang <wangai...@tsinghua.org.cn> wrote:Hi, Dhruv: I recommend the following changes to the current charter: 1) Further, the PCE WG also handle protocol extensions for new path setup types of Segment Routing (SR), BIER, and Detnet.è Further, the PCE WG also handle protocol extensions for new path setup types of Segment Routing (SR), Native IP, BIER, Detnet and other possible forward data plane.2）Add one items in the “Milestone” è July 2023 Submit PCEP extension for Native IP as a Proposed Standard Thanks in advance. Best Regards Aijun WangChina Telecom 发件人: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] 代表 Dhruv Dhody发送时间: 2023年7月4日 13:15收件人: pce@ietf.org主题: Re: [Pce] Proposed PCE WG Charter update Hi WG, A gentle reminder for your comments on the proposed text for recharter! We can also use a few "I have read the proposed charter update text and I support rechartering!" :) Thanks! Dhruv On Wed, Jun 21, 2023 at 11:07 AM Dhruv Dhody <d...@dhruvdhody.com> wrote:Hi WG, The PCE WG charter (-07) was last updated in 2014. Your chairs and AD discussed the need to bring the charter up to date. We have made a proposed small update (-08) and placed it in our WG's Github - https://github.com/ietf-wg-pce/charter A diff of the changes can be seen at - https://author-tools.ietf.org/iddiff?url1=https://raw.githubusercontent.com/ietf-wg-pce/charter/main/charter-ietf-pce-07.txt=--html=https://raw.githubusercontent.com/ietf-wg-pce/charter/main/charter-ietf-pce-08.txt We request the WG to review the proposed charter update. We suggest using the mailing list for discussion and proposing substantial changes. Minor edits may also be suggested via PR directly on the GitHub. Please provide all your comments before 5th July. We would then forward the request to our AD. Thanks! Dhruv & Julien ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[Pce] 答复: Proposed PCE WG Charter update
Hi, Dhruv: I recommend the following changes to the current charter: 1) Further, the PCE WG also handle protocol extensions for new path setup types of Segment Routing (SR), BIER, and Detnet. è Further, the PCE WG also handle protocol extensions for new path setup types of Segment Routing (SR), Native IP, BIER, Detnet and other possible forward data plane. 2）Add one items in the “Milestone” è July 2023 Submit PCEP extension for Native IP as a Proposed Standard Thanks in advance. Best Regards Aijun Wang China Telecom 发件人: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] 代表 Dhruv Dhody 发送时间: 2023年7月4日 13:15 收件人: pce@ietf.org 主题: Re: [Pce] Proposed PCE WG Charter update Hi WG, A gentle reminder for your comments on the proposed text for recharter! We can also use a few "I have read the proposed charter update text and I support rechartering!" :) Thanks! Dhruv On Wed, Jun 21, 2023 at 11:07 AM Dhruv Dhody mailto:d...@dhruvdhody.com> > wrote: Hi WG, The PCE WG charter (-07) was last updated in 2014. Your chairs and AD discussed the need to bring the charter up to date. We have made a proposed small update (-08) and placed it in our WG's Github - https://github.com/ietf-wg-pce/charter A diff of the changes can be seen at - https://author-tools.ietf.org/iddiff?url1=https://raw.githubusercontent.com/ietf-wg-pce/charter/main/charter-ietf-pce-07.txt <https://author-tools.ietf.org/iddiff?url1=https://raw.githubusercontent.com/ietf-wg-pce/charter/main/charter-ietf-pce-07.txt=--html=https://raw.githubusercontent.com/ietf-wg-pce/charter/main/charter-ietf-pce-08.txt> =--html=https://raw.githubusercontent.com/ietf-wg-pce/charter/main/charter-ietf-pce-08.txt We request the WG to review the proposed charter update. We suggest using the mailing list for discussion and proposing substantial changes. Minor edits may also be suggested via PR directly on the GitHub. Please provide all your comments before 5th July. We would then forward the request to our AD. Thanks! Dhruv & Julien ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[Pce] 答复: Adoption Poll for draft-dhody-pce-stateful-pce-vendor
Hi, All: Support its adoption. Will it be more clear that points out RFC7470 defined the Vendor-Information Object and Vendor-Information-TLV for stateless PCE(PCReq/PCRep Message), then this document extends it to stateful PCE? Especially includes the vendor information in PCRpt/PCUpd/PCInitiate Message. In the "Abstract" and "Introduction" parts, the corresponding sentences have all no such explicit statements. Best Regards Aijun Wang China Telecom -邮件原件- 发件人: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] 代表 julien.meu...@orange.com 发送时间: 2023年6月20日 15:47 收件人: pce@ietf.org 主题: [Pce] Adoption Poll for draft-dhody-pce-stateful-pce-vendor Hi all, It has been a while since draft-dhody-pce-stateful-pce-vendor started to document how to extend the scope of RFC 7470. It is now time to consider its adoption by the WG. Do you think draft-dhody-pce-stateful-pce-vendor-16 [1] is ready to become a PCE work item? Please express your support and/or concerns using the mailing list. Thanks, Dhruv & Julien [1] https://datatracker.ietf.org/doc/draft-dhody-pce-stateful-pce-vendor Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] I-D Action: draft-ietf-pce-pcep-extension-native-ip-22.txt
Hi, All experts: The updated version are mainly to address the comments received during the WGLC, for example, the correlation of BGP session setup and the PCEP procedures( section 9: BGP Considerations), the downref adjustment, the phrase for the mandatory existing of BPI, EPR, PPA object and some editorial nits etc. Please refer to the diff file https://author-tools.ietf.org/iddiff?url1=draft-ietf-pce-pcep-extension-nati ve-ip-21=draft-ietf-pce-pcep-extension-native-ip-22=--html to view the detail updation. Please check whether the updates address your concerns. If there is no more issues, we will try to move forward (the IESG review) then. Best Regards Aijun Wang China Telecom -Original Message- From: pce-boun...@ietf.org On Behalf Of internet-dra...@ietf.org Sent: Wednesday, June 7, 2023 11:01 AM To: i-d-annou...@ietf.org Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-pcep-extension-native-ip-22.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This Internet-Draft is a work item of the Path Computation Element (PCE) WG of the IETF. Title : PCEP Extension for Native IP Network Authors : Aijun Wang Boris Khasanov Sheng Fang Ren Tan Chun Zhu Filename: draft-ietf-pce-pcep-extension-native-ip-22.txt Pages : 28 Date: 2023-06-06 Abstract: This document defines the Path Computation Element Communication Protocol (PCEP) extension for Central Control Dynamic Routing (CCDR) based application in Native IP network. It describes the key information that is transferred between Path Computation Element (PCE) and Path Computation Clients (PCC) to accomplish the End to End (E2E) traffic assurance in Native IP network under central control mode. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-native-i p-22 A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-pcep-extension-nati ve-ip-22 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts ___ 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] WGLC for draft-ietf-pce-pcep-extension-native-ip-20
Hi, Quan: Thanks for your support and suggestions! I have already updated the reference to RFC9050 as your suggestion. Regarding to the recommendation of second point, if it will not arise again the obscure of its meaning, keeping it simple will be better. If there is no more argument for this simplification, we will update document later accordingly. Aijun Wang China Telecom > On May 31, 2023, at 11:15, xiong.q...@zte.com.cn wrote: > > 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, or PPA object > MUST be present." It is a little confused. Maybe that can be changed to "One > BPI, EPR, or PPA object MUST be present and others should be ignored." > > Best Regards, > Quan > > > > > <<[Pce] WGLC for draft-ietf-pce-pcep-extension-native-ip-20 > < Tue, 16 May 2023 22:16 UTCShow header > 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 ___ 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
Hi, Zhenqiang:Thanks for your support.Before we proposed and designed the solution that described in https://datatracker.ietf.org/doc/html/rfc8821, and also the PCEP extension that described this WGLC document, we have analyzed the characteristics and challenges of SRv6 based solutions.As indicated in https://datatracker.ietf.org/doc/html/rfc8821#name-introduction, we are trying to find the solution that can meet the following requirements:Same solution for native IPv4 and IPv6 traffic.Support for intra-domain and inter-domain scenarios.Achieve E2E traffic assurance, with determined QoS behavior, for traffic requiring a service assurance (prioritized traffic).No changes in a router's forwarding behavior.Based on centralized control through a distributed network control plane.Support different network requirements such as high traffic volume and prefix scaling.Ability to adjust the optimal path dynamically upon the changes of network status. No need for reserving resources for physical links in advance.Aijun WangChina TelecomOn May 29, 2023, at 10:19, li_zhenqi...@hotmail.com wrote: Hi All,I support it, I have read the latest version and it is ready for publication in my opinion. Scenarios to be addressed is described in RFC8735. Based on the progress of SRv6, I think SRv6 is an alternative solution. Best Regards,Zhenqiang Lili_zhenqi...@hotmail.com From: Dhruv DhodyDate: 2023-05-17 06:15To: pceCC: pce-chairs; draft-ietf-pce-pcep-extension-native-ipSubject: [Pce] WGLC for draft-ietf-pce-pcep-extension-native-ip-20Hi 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 listPce@ietf.orghttps://www.ietf.org/mailman/listinfo/pce___ 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
Hi, Tom: I think two phases approach may be more appropriate. As I replied you also in the IDR list, we propose the following update later: 1) PCE sends the BPI object with PCInitiate message, then PCC replies with “Ack, start BGP session”. 2) PCC reports the successful results to PCE after the BGP session is established successfully. In case of any failure during the process, PCC can report the error information accordingly. Regarding to your worry about the “hundreds of clients” configuration, I think there may be some misunderstandings, or we should describe more clearly in the documentation to avoid such worry: Actually, in such situation, only the two edge routers and RR need to be configured the new BGP session via the PCE, all other RR clients need not be configured again. The BGP prefixes advised by PPA(Peer Prefix Advertisement) Object via the PCInitiate message will be advertised via the existing BGP sessions between RR and its other clients. If we take the scenario illustrated in Figure 1 as the example, we can notice that the PCInitiate message is sent only to R1/R7/R3(RR), not to the R5 and R6. For the tolerance of BGP session establish duration, I think it should be determined by the PCE itself, because there is no guarantee way to assure the underlying establishment time lapse. The PCE can determine when it should retry, and when it will give up and determine the failure itself if it can’t still receive the responses from the PCC. Aijun Wang China Telecom > On May 24, 2023, at 23:45, tom petch wrote: > From: Aijun Wang > Sent: 24 May 2023 15:47 > > Hi, Tom: > > As I explained in previous mail, the procedure of PCEP described in this > draft and the establishment of underlying BGP sessions that initiated by the > BPI object that included in the PCInitiate message is asynchronous. > The PCC will report the successful information only after the specific BGP > session has been established. We think it’s unnecessary to expose the details > BGP FSM states to the PCE—-If there is no successful report from the PCC, the > PCE can consider the BGP session is still undergoing. > > Does the above considerations solve your concerns? If necessary, we can > consider add some extra state reports from the PCC. > > > > Not really. The BGP session setup will fail until the peer is configured so > how long does the PCE wait for that, how often does it retry, when does it > give up and declare a failure? If one PCE is impatient, another leisurely, > then we may not have interoperability. I would expect some guidance on this. > > The I-D talks of RR with hundreds of clients which makes me wonder what else > might happen, such as a DoS attack. > > Tom Petch > > Aijun Wang > China Telecom > >> On May 24, 2023, at 17:24, tom petch wrote: >> >> Adding a new concern about session setup >> >> From: Pce on behalf of tom petch >> Sent: 22 May 2023 12:35 >> From: Pce on behalf of Dhruv Dhody >> >> Sent: 16 May 2023 23:15 >> >> >> I do not understand how this operates. I would expect there to be two >> phases. first the boxes are configured with the information needed by BGP >> and then one or more is instructed to initiate the BGP session. Here I see >> PCInitiate providing the configuration information and s.6.1 then says that >> the BGP session the operates in a normal fashion; but if the PCE immediately >> attempts to initiate a session, it will likely fail because the peer is not >> yet configured. I assume it must then back off, wait and try again later >> and then report success or failure (after an extended period of time). Such >> behaviour could be found in a number of protocols. >> >> None of this seems to be catered for. >> >> Tom Petch >> >> >> This email starts a 2-weeks working group last call for >> draft-ietf-pce-pcep-extension-native-ip-20 [1]. >> >> >> I had a look and decided that it is mostly beyond me - I am not up to speed >> with all the 15 Normative References, in particular with RFC8821. I would >> prefer that this I-D provided a better bridge to the material in RFC8821. >> >> I note that RFC8821 is an as yet unapproved downref which reinforces that >> view. >> >> I note too that the Abstract references this and 8735 as anchors which >> Abstracts must not do. >> >> The I-D uses the word 'draft' in many places. These must be changed. >> >> The I-D has a large number of TBDnnn with no note requesting that they are >> replaced; I find these easy to miss. >> >> p.9 2) >> seems to end mid-sentence. >> >> The English is n
Re: [Pce] WGLC for draft-ietf-pce-pcep-extension-native-ip-20
Hi, Dhruv:I will send one independent mail for the early allocation request. After reading the link that you given, it states once the document is stable, then we can start the request.The early allocation is the prerequisite for the future implementation and can also ease the review works for ADs and RFC EDITOR.Aijun WangChina TelecomOn May 25, 2023, at 00:49, Dhruv Dhody wrote:Hi Aijun, If you have a need for an early allocation, please send an email to pce-cha...@ietf.org and we will follow https://datatracker.ietf.org/doc/html/rfc7120#section-3But note that as per your Implementation Status [https://www.ietf.org/archive/id/draft-ietf-pce-pcep-extension-native-ip-21.html#section-12], there are no known implementations though! Thanks! DhruvOn Wed, May 24, 2023 at 9:19 PM Adrian Farrel <adr...@olddog.co.uk> wrote:
In the past, I would have agreed with Tom on this.
But we are routinely seeing a pause of more than 200 days between a WG issuing a Publication Request and the AD starting their review (which leads to updates and discussion before IETF last call). IANA don't do their provisional assignments until IETF last call.
If there are implementations of what is presumably a stable draft, I think early assignment is reasonable. It shouldn't take more than 10 minutes of the chairs' and AD'S time.
Cheers,
Adrian
On 24/05/2023 16:33 BST tom petch <ie...@btconnect.com> wrote:
From: Aijun Wang <wangai...@tsinghua.org.cn>
Sent: 24 May 2023 16:02
As I remember, it is the IANA first allocate the necessary values, then go to the RFCEditor.
Can we ask the IANA to (early) allocate the value now?
At this stage in the process, I doubt if it is worth the extra work. Such a request goes via chairs and AD. I see it more when users want to implement and it may be some time before the I-D gets to the stage that this one is now at. And later reviews - Last Call, IESG - may come up with changes to the TBDnnn that then confuse the picture. I prefer the 'normal' process but with perhaps a bit more of a nudge to the RFC Editor to make sure that they pick up all the usages e.g. pointing out to the RFC Editor up front or in the IANA Considerations that there are many TBDnn in the body of the I-D.
Thinking about it, I am a bit hazy on the normal process between IANA and RFC Editor. The e-mails that I see are when things go wrong and either the RFC Editor or IANA (or both) are unclear as to what is intended and need guidance from the WG
Tom Petch
Aijun Wang
China Telecom
On May 24, 2023, at 17:12, tom petch <ie...@btconnect.com> wrote:
From: Aijun Wang <wangai...@tsinghua.org.cn>
Sent: 23 May 2023 07:59
Hi, Tom:
Thanks for your review.
I have uploaded the new version to address your comments.
I am trying to find some more convenient methods to describe the un-allocated "TBDnnn" from the IANA. Do you have any suggestions that can't be "too easy to miss"?
My purpose is that once the IANA allocates the value to each of these values according to our requests (https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-native-ip-21#section-14)
, I can replace them easily in the updated version.
Mmm I did look at other I-D for another way but think that this is unusual in the number of TBDnnn in the body of the I-D, not in the IANA Considerations. I did not see a request for early allocation so the values will not be assigned until the I-D is about to leave the RFC Editor Queue so it is the RFC Editor, not you, who has to find all the instances of TBDnnn and replace them. Common practice is to add a
-- Note to the RFC Editor
in each and every place where such action is needed outside the IANA Considerations. There are a lot of them; 44 I think. I think that at least there should be a Note to the RFC Editor in IANA Considerations to the effect that these values appear in many places and need editing.
I will post separately a concern about BGP session setup.
Tom Petch
For the interaction between BGP and PCEP, we think the paces or procedures described in this document can be controlled by the PCE--Once the PCE se
Re: [Pce] WGLC for draft-ietf-pce-pcep-extension-native-ip-20
As I remember, it is the IANA first allocate the necessary values, then go to the RFCEditor. Can we ask the IANA to (early) allocate the value now? Aijun Wang China Telecom > On May 24, 2023, at 17:12, tom petch wrote: > > From: Aijun Wang > Sent: 23 May 2023 07:59 > > Hi, Tom: > > Thanks for your review. > > I have uploaded the new version to address your comments. > > I am trying to find some more convenient methods to describe the un-allocated > "TBDnnn" from the IANA. Do you have any suggestions that can't be "too easy > to miss"? > > My purpose is that once the IANA allocates the value to each of these values > according to our requests > (https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-native-ip-21#section-14) > > , I can replace them easily in the updated version. > > > > Mmm I did look at other I-D for another way but think that this is unusual > in the number of TBDnnn in the body of the I-D, not in the IANA > Considerations. I did not see a request for early allocation so the values > will not be assigned until the I-D is about to leave the RFC Editor Queue so > it is the RFC Editor, not you, who has to find all the instances of TBDnnn > and replace them. Common practice is to add a > -- Note to the RFC Editor > in each and every place where such action is needed outside the IANA > Considerations. There are a lot of them; 44 I think. I think that at least > there should be a Note to the RFC Editor in IANA Considerations to the effect > that these values appear in many places and need editing. > > I will post separately a concern about BGP session setup. > > Tom Petch > > > For the interaction between BGP and PCEP, we think the paces or procedures > described in this document can be controlled by the PCE--Once the PCE > sends the command to PCC, it will collect the status of such command. Only > when the previous command is executed successfully, then the next command can > be issued. Section 6 cover the descriptions of main procedures. > > For your other comments, please see replies inline. > > > > Huaimo also gives us more valuable suggestions to refine the document > offline. I have also incorporated them together in the updated version. > > > > Thanks all you together! > > > > Future reviews from other experts can be based on the updated version. > > > > > > Best Regards > > > > Aijun Wang > > China Telecom > > > > -Original Message- > From: pce-boun...@ietf.org On Behalf Of tom petch > Sent: Monday, May 22, 2023 7:35 PM > To: Dhruv Dhody ; pce@ietf.org > Cc: pce-chairs ; > draft-ietf-pce-pcep-extension-native...@ietf.org > Subject: Re: [Pce] WGLC for draft-ietf-pce-pcep-extension-native-ip-20 > > > > From: Pce mailto:pce-boun...@ietf.org>> on behalf of > Dhruv Dhody mailto:d...@dhruvdhody.com>> > > Sent: 16 May 2023 23:15 > > > > This email starts a 2-weeks working group last call for > draft-ietf-pce-pcep-extension-native-ip-20 [1]. > > > > > > I had a look and decided that it is mostly beyond me - I am not up to speed > with all the 15 Normative References, in particular with RFC8821. I would > prefer that this I-D provided a better bridge to the material in RFC8821. > > > > I note that RFC8821 is an as yet unapproved downref which reinforces that > view. > > > > I note too that the Abstract references this and 8735 as anchors which > Abstracts must not do. > > [WAJ] Remove the anchors in the abstract. > > > > The I-D uses the word 'draft' in many places. These must be changed. > > [WAJ] Changed the "draft" to "document" within the entire document. > > > > The I-D has a large number of TBDnnn with no note requesting that they are > replaced; I find these easy to miss. > > [WAJ] Do you have any suggestions that can't be "easy to miss"? > > > > p.9 2) > > seems to end mid-sentence. > > [WAJ] Updated > > > > The English is not quite in several places and could be confusing. Thus p.5 > "Further only one > > of BPI, EPR, or PPA object MUST be present. " > > I can interpret in two ways although subsequent text makes one the preferred > one. > > [WAJ] Change the phrase to "Further only one and one kind of BPI,EPR, or PPA > object MUST be present", is it better? > > > > I suspect that there are many potential interactions with BGP, especially > when things are not going quite right, and that the I-D do
Re: [Pce] WGLC for draft-ietf-pce-pcep-extension-native-ip-20
Hi, Tom: As I explained in previous mail, the procedure of PCEP described in this draft and the establishment of underlying BGP sessions that initiated by the BPI object that included in the PCInitiate message is asynchronous. The PCC will report the successful information only after the specific BGP session has been established. We think it’s unnecessary to expose the details BGP FSM states to the PCE—-If there is no successful report from the PCC, the PCE can consider the BGP session is still undergoing. Does the above considerations solve your concerns? If necessary, we can consider add some extra state reports from the PCC. Aijun Wang China Telecom > On May 24, 2023, at 17:24, tom petch wrote: > > Adding a new concern about session setup > > From: Pce on behalf of tom petch > Sent: 22 May 2023 12:35 > From: Pce on behalf of Dhruv Dhody > > Sent: 16 May 2023 23:15 > > > I do not understand how this operates. I would expect there to be two > phases. first the boxes are configured with the information needed by BGP and > then one or more is instructed to initiate the BGP session. Here I see > PCInitiate providing the configuration information and s.6.1 then says that > the BGP session the operates in a normal fashion; but if the PCE immediately > attempts to initiate a session, it will likely fail because the peer is not > yet configured. I assume it must then back off, wait and try again later and > then report success or failure (after an extended period of time). Such > behaviour could be found in a number of protocols. > > None of this seems to be catered for. > > Tom Petch > > > This email starts a 2-weeks working group last call for > draft-ietf-pce-pcep-extension-native-ip-20 [1]. > > > I had a look and decided that it is mostly beyond me - I am not up to speed > with all the 15 Normative References, in particular with RFC8821. I would > prefer that this I-D provided a better bridge to the material in RFC8821. > > I note that RFC8821 is an as yet unapproved downref which reinforces that > view. > > I note too that the Abstract references this and 8735 as anchors which > Abstracts must not do. > > The I-D uses the word 'draft' in many places. These must be changed. > > The I-D has a large number of TBDnnn with no note requesting that they are > replaced; I find these easy to miss. > > p.9 2) > seems to end mid-sentence. > > The English is not quite in several places and could be confusing. Thus p.5 > "Further only one > of BPI, EPR, or PPA object MUST be present. " > I can interpret in two ways although subsequent text makes one the preferred > one. > > I suspect that there are many potential interactions with BGP, especially > when things are not going quite right, and that the I-D does not cover them > all. The language used is not that of BGP (e.g. Established, speaker). The > timing too of BGP can be quite slow, in setup and in shutdown and I wonder > how a PCC copes with that. > > As I say, largely beyond me but the English needs some attention; using the > terminology of BGP would help. > > Tom Petch > > > 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 > > ___ > 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] WGLC for draft-ietf-pce-pcep-extension-native-ip-20
Hi, Tom: Thanks for your review. I have uploaded the new version to address your comments. I am trying to find some more convenient methods to describe the un-allocated "TBDnnn" from the IANA. Do you have any suggestions that can't be "too easy to miss"? My purpose is that once the IANA allocates the value to each of these values according to our requests (https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-native- ip-21#section-14) , I can replace them easily in the updated version. For the interaction between BGP and PCEP, we think the paces or procedures described in this document can be controlled by the PCE--Once the PCE sends the command to PCC, it will collect the status of such command. Only when the previous command is executed successfully, then the next command can be issued. Section 6 cover the descriptions of main procedures. For your other comments, please see replies inline. Huaimo also gives us more valuable suggestions to refine the document offline. I have also incorporated them together in the updated version. Thanks all you together! Future reviews from other experts can be based on the updated version. Best Regards Aijun Wang China Telecom -Original Message- From: pce-boun...@ietf.org On Behalf Of tom petch Sent: Monday, May 22, 2023 7:35 PM To: Dhruv Dhody ; pce@ietf.org Cc: pce-chairs ; draft-ietf-pce-pcep-extension-native...@ietf.org Subject: Re: [Pce] WGLC for draft-ietf-pce-pcep-extension-native-ip-20 From: Pce < <mailto:pce-boun...@ietf.org> pce-boun...@ietf.org> on behalf of Dhruv Dhody < <mailto:d...@dhruvdhody.com> d...@dhruvdhody.com> Sent: 16 May 2023 23:15 This email starts a 2-weeks working group last call for draft-ietf-pce-pcep-extension-native-ip-20 [1]. I had a look and decided that it is mostly beyond me - I am not up to speed with all the 15 Normative References, in particular with RFC8821. I would prefer that this I-D provided a better bridge to the material in RFC8821. I note that RFC8821 is an as yet unapproved downref which reinforces that view. I note too that the Abstract references this and 8735 as anchors which Abstracts must not do. [WAJ] Remove the anchors in the abstract. The I-D uses the word 'draft' in many places. These must be changed. [WAJ] Changed the "draft" to "document" within the entire document. The I-D has a large number of TBDnnn with no note requesting that they are replaced; I find these easy to miss. [WAJ] Do you have any suggestions that can't be "easy to miss"? p.9 2) seems to end mid-sentence. [WAJ] Updated The English is not quite in several places and could be confusing. Thus p.5 "Further only one of BPI, EPR, or PPA object MUST be present. " I can interpret in two ways although subsequent text makes one the preferred one. [WAJ] Change the phrase to "Further only one and one kind of BPI,EPR, or PPA object MUST be present", is it better? I suspect that there are many potential interactions with BGP, especially when things are not going quite right, and that the I-D does not cover them all. The language used is not that of BGP (e.g. Established, speaker). The timing too of BGP can be quite slow, in setup and in shutdown and I wonder how a PCC copes with that. [WAJ] Once the PCC receives the PCInitiate message that include BPI (BGP Peer Info) object, it will try to build the BGP session between the peers that indicates in the BPI object. Only when it establishes the BGP session successfully, it will report the PCE via the PCRpt message(as that described in section https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-native-i p-21#section-6.1). Then the PCE can send other instruction to the PCCs. Actually, the procedures described in this document is asynchronous. As I say, largely beyond me but the English needs some attention; using the terminology of BGP would help. Tom Petch 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/> https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/ ___ Pce mailing list <mailto:Pce@ietf.org> Pce@ietf.org <https://www.ietf.org/mailman/listinfo/pce> https://ww
Re: [Pce] IPR Poll on draft-ietf-pce-pcep-extension-native-ip-20
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 Aijun Wang China Telecom From: pce-boun...@ietf.org On Behalf Of Hariharan Ananthakrishnan Sent: Wednesday, May 17, 2023 11:16 AM To: wang...@chinatelecom.cn; bhassa...@yahoo.com; zhu.ch...@zte.com.cn; fsh...@huawei.com; tan...@huawei.com Cc: pce@ietf.org Subject: [Pce] IPR Poll on draft-ietf-pce-pcep-extension-native-ip-20 Hi Authors, In preparation for WG LC on this I-D, 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] I-D Action: draft-ietf-pce-pcep-extension-native-ip-20.txt
Hi, All: We have made some updates again to prepare for the WGLC. Any comments are welcome. We would also like to ask the Chairs to start the WGLC in recent days. Thanks in advance. Best Regards Aijun Wang China Telecom -Original Message- From: pce-boun...@ietf.org On Behalf Of internet-dra...@ietf.org Sent: Thursday, April 6, 2023 4:02 PM To: i-d-annou...@ietf.org Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-pcep-extension-native-ip-20.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This Internet-Draft is a work item of the Path Computation Element (PCE) WG of the IETF. Title : PCEP Extension for Native IP Network Authors : Aijun Wang Boris Khasanov Sheng Fang Ren Tan Chun Zhu Filename: draft-ietf-pce-pcep-extension-native-ip-20.txt Pages : 29 Date: 2023-04-06 Abstract: This document defines the Path Computation Element Communication Protocol (PCEP) extension for Central Control Dynamic Routing (CCDR) based application in Native IP network. The scenario and framework of CCDR in native IP is described in [RFC8735] and [RFC8821]. This draft describes the key information that is transferred between Path Computation Element (PCE) and Path Computation Clients (PCC) to accomplish the End to End (E2E) traffic assurance in Native IP network under central control mode. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-native-i p-20 A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-pcep-extension-nati ve-ip-20 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts ___ 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 Last Call for draft-ietf-pce-segment-routing-ipv6-15
Hi, All: I support its publication. While reviewing the document, one question emerged about the design of SRv6-ERO Suboject (and also the SRv6-RRO Suboject): Why don’t use the TLV format for the optional fields in these two objects? Taking such approach can loose the requirement of order of the optional fields, and will be easier for future extension. Best Regards Aijun Wang China Telecom -Original Message- From: 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
[Pce] 答复: WG Adoption of draft-chen-pce-pcep-ifit-06
Hi, All: I support its adoption. One questions to the authors: Is it enough that only the headend support the defined iFIT capabilities? What’s the procedures when the nodes on the LSP/SR path doesn’t support the defined iFIT capabilities? Aijun Wang China Telecom 发件人: Dhruv Dhody [mailto:d...@dhruvdhody.com] 发送时间: 2022年6月24日 16:59 收件人: pce@ietf.org 抄送: draft-chen-pce-pcep-i...@ietf.org 主题: WG Adoption of draft-chen-pce-pcep-ifit-06 Hi WG, This email begins the WG adoption poll for draft-chen-pce-pcep-ifit-06. https://datatracker.ietf.org/doc/draft-chen-pce-pcep-ifit/ 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 July 2022. Please be more vocal during WG polls! Thanks! Dhruv & Julien ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[Pce] 答复: New Version Notification for draft-ietf-pce-local-protection-enforcement-06.txt
Hi, Andrew: I think the update contents will be helpful for the reader to understand the usage of "UNPROCTED MANDATORY" and "UNPROTECTED PREFERRED" type. Support for its forwarding. Aijun Wang China Telecom -邮件原件- 发件人: Stone, Andrew (Nokia - CA/Ottawa) [mailto:andrew.st...@nokia.com] 发送时间: 2022年6月21日 22:14 收件人: Aijun Wang ; pce@ietf.org 主题: Re: New Version Notification for draft-ietf-pce-local-protection-enforcement-06.txt Hi Aijun, PCE WG Document was updated with additional descriptive text on the use case/scenarios. We appreciate any additional feedback or comments regarding the WGLC from the group! Thanks! Andrew On 2022-06-20, 12:18 PM, "internet-dra...@ietf.org" wrote: A new version of I-D, draft-ietf-pce-local-protection-enforcement-06.txt has been successfully submitted by Andrew Stone and posted to the IETF repository. Name: draft-ietf-pce-local-protection-enforcement Revision: 06 Title: Local Protection Enforcement in PCEP Document date: 2022-06-20 Group: pce Pages: 12 URL: https://www.ietf.org/archive/id/draft-ietf-pce-local-protection-enforcement-06.txt Status: https://datatracker.ietf.org/doc/draft-ietf-pce-local-protection-enforcement/ Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-pce-local-protection-enforcement Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-local-protection-enforcement-06 Abstract: This document updates [RFC5440] to clarify usage of the local protection desired bit signalled in Path Computation Element Protocol (PCEP). This document also introduces a new flag for signalling protection strictness in PCEP. The IETF Secretariat ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WG Last Call of draft-ietf-pce-local-protection-enforcement-05
Hi, Andrew: Thanks for your explanation. I think adding these descriptions into the document would be helpful to the reader to know the necessary of the protocol extension. I support its forwarding. Aijun Wang China Telecom > On Jun 10, 2022, at 23:20, Stone, Andrew (Nokia - CA/Ottawa) > wrote: > > Hi Aijun, > > Replies inline below with > > Thanks > Andrew > > > On 2022-06-09, 11:32 PM, "Pce on behalf of Aijun Wang" on behalf of wangai...@tsinghua.org.cn> wrote: > >Hi, All: >After reading this draft, my feel is that it make the situation more > complex. Won’t it be more difficult for interoperability from different > vendors, or from the different versions of the same vendor? >And, is there any situation that the customer want “UNPROTECTED MANDATORY” > service? or “UNPROTECTED PREFERRED” service? > > > The intent is to actually make path and SID selection behavior more > consistent between PCE's, as right now the existing language is vague to the > nature of a link with multiple sids which may or may not support protection, > and interop tests have exposed differences of interpretation and thus > implementation, so I would argue things are already difficult from an > interoperability point of view while this document clarifies that. In > addition, the additional definitions are solving TE requirements such as > UNPROTECTED_MANDATORY, which I'll comment on more further below (which indeed > are customer situations). UNPROTECTED PREFERRED is a guidance on how PCE > should interpret when L bit is not set and is being backwards compatible with > existing known implementations prior to this document. > > > >How about just clarify the usages of “L” bit in RFC5440, for example: when > this flag is set, it mean “PROTECTED MANDATORY”, or else, if it is unset, > then it depends on the transit router’s capabilities?( I am struggle to image > which kind of customers will declare explicitly that they don’t want > protection if the service providers does not charge more for the possible > protection action) > >And, if possible, can authors explain in more detail why the customer has > the following requirements: >“For another example, UNPROTECTED MANDATORY is when an operator may > intentionally prefer an LSP to not be locally protected, and thus > would rather local failures to cause the LSP to go down and/or rely > on other protection mechanisms such as a secondary diverse path.” > >Clarifying the necessary of different requirements is the base for the > extension of protocol. > > > > > If the document declares only L bit means PROTECTED MANDATORY, then > the capability to do UNPROTECTED MANDATORY cannot be achieved. Aside from > that, when L bit is not set, without this document then PCE implementation > have no guidance on which SID should be selected in the scenario a link has > multiple SIDs (one backup supported, one not) leading to interoperable > differences on the same network which may have multiple vendors deployed. as > per section 4 in the document, both compatibility and new requirements are > coupled and being addressed by the document. > > Regarding the use case for UNPROTECTED MANDATORY, one scenario which sparked > this involved a provider offering different levels of service, capacity and > guarantees to their end customers on a network with very explicit TE > requirements and expected TE behavior. For one type of service, disjoint TE > paths would be established. The operator did not want any interim re-routing > of traffic flow off of the defined TE path as the volume of that data being > carried would negatively impact the links in which it may be temporarily > traversing via LFA. In addition, due to the network design and diversity > design, re-routing of the impacted path was either undesired (from a network > management point of view) OR not feasible (no alternative path that’s also > disjoint), so the traffic would stay in LFA until the path was brought down > intentionally by PCE, before switching to the protected path anyways. The key > thing is for this service, temporary fast rerouting on a non TE managed path > was not wanted. In another service type, fast re-route protection was offered > but without a diverse backup path. Essentially different levels of service > had different TE and SLA requirements operating on the same network. > Recently, draft-schmutzer-pce-cs-sr-policy has formalized the concept of > Circuit Style Segment Routing Policies, which also has a need for UNPROTECTED > MANDATORY (see section 5). > > > > >Aijun Wang >China Telecom > >> On Jun 7, 202
Re: [Pce] WG Last Call of draft-ietf-pce-local-protection-enforcement-05
Hi, All: After reading this draft, my feel is that it make the situation more complex. Won’t it be more difficult for interoperability from different vendors, or from the different versions of the same vendor? And, is there any situation that the customer want “UNPROTECTED MANDATORY” service? or “UNPROTECTED PREFERRED” service? How about just clarify the usages of “L” bit in RFC5440, for example: when this flag is set, it mean “PROTECTED MANDATORY”, or else, if it is unset, then it depends on the transit router’s capabilities?( I am struggle to image which kind of customers will declare explicitly that they don’t want protection if the service providers does not charge more for the possible protection action) And, if possible, can authors explain in more detail why the customer has the following requirements: “For another example, UNPROTECTED MANDATORY is when an operator may intentionally prefer an LSP to not be locally protected, and thus would rather local failures to cause the LSP to go down and/or rely on other protection mechanisms such as a secondary diverse path.” Clarifying the necessary of different requirements is the base for the extension of protocol. Aijun Wang China Telecom > On Jun 7, 2022, at 17:19, julien.meu...@orange.com wrote: > Dear all, > > This message starts a 2-week Working Group Last Call > fordraft-ietf-pce-local-protection-enforcement-05 [1]. > > Please share your comments using the PCE mailing list. Any levels of reviews > are very welcome and all feedback remain useful to check the readiness of the > document. > > This LC will end on Wednesday June 22, 2022. > > Thanks, > > Dhruv & Julien > > > [1] > https://datatracker.ietf.org/doc/html/draft-ietf-pce-local-protection-enforcement > > ___ > 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] WGLC for draft-ietf-pce-lsp-extended-flags-02
Hi, Dhruv: It’s possible to use variable length, but most of the flag field are fixed size, because this field needs to be compared in bits. Align them with the same width will be more easier. Even with your mentioned examples, the used flags are only 16bits until now(16 years past since RFC5088 published). The reason that I raised this concern is that I have not imaged another 32bit flag need to be defined for LSP, regardless of the length as 64 or more longer. And for the variable length flag, there need to be more error considerations in the future bit-defined document. For example, if you define bit 35, you should consider the error that the length of received LSP-EXTENDED-FLAG is only 4(32bit), and describes the mismatch reason in the error information? Until now, I have not seen which defined flag has exceeds the 32bit. If there is enough necessary to do so, I don’t object, but currently I don’t see the image, why don’t we keep the thing simple. And, I support the forwarding of this draft. The current flag field has no room for further extension. Aijun Wang China Telecom > On May 12, 2022, at 11:59, Dhruv Dhody wrote: > > > Hi Aijun, > > As a WG member... > >> On Thu, May 12, 2022 at 6:58 AM Aijun Wang wrote: >> Hi, Dhruv and Quan: >> Is there any reason to define the extended flag in variable length? > > The aim was to fix it once and not worry about running out of flags ever > again. > Moreover, there is a precedence of this technique in the context of PCE, so > the implementations already handle these cases well. > > https://www.rfc-editor.org/rfc/rfc5088.html#section-4.5 > https://www.rfc-editor.org/rfc/rfc5089.html#section-4.5 > > >> Should it be more reasonable that just define one 32 bit extended flag and >> if necessary, define another extended flag TLV? > > Yes, it can be done that way. Is it more reasonable? That is debatable... > Open to feedback from the WG. > > >> And, as I read section 3.2: >> https://www.ietf.org/archive/id/draft-ietf-pce-lsp-extended-flags-02.html#section-3.2 >> “…. … >> If a PCEP speaker receives the LSP-EXTENDED-FLAG TLV of a length less than >> the one supported by the implementation, it will consider the bits beyond >> the length to be unset. >> … ….” >> >> Will the above lead to misbehavior in some situations? >> > > A (TLV L=8) -- B (TLV L=4) > When A receives an LSP-EXTENDED-FLAG TLV with Length = 4, even though it > understands/supports more flags than 32, it considers that those other flags > are unset for B. > When B receives an LSP-EXTENDED-FLAG TLV with Length = 8, since B only > understands limited bits, it considers all the other ones as unassigned and > ignores them. > > Note that this behavior is similar to how considering A supports 10 flags and > B supports 3 flags would be handled even though the L=4 for both. > > What am I missing? > >> Anyway, I recommend the fixed length(then the length field is unnecessary) >> and clear description/usages of each bit of the flag. >> > > This document creates the TLV and a registry. The actual bits and their usage > belong in other documents. > > Thanks! > Dhruv (as a WG member) > > >> Aijun Wang >> China Telecom >> >>>> On May 11, 2022, at 21:28, Dhruv Dhody wrote: >>>> >>> >>> Hi WG, >>> >>> This email starts a 2-weeks working group last call for >>> draft-ietf-pce-lsp-extended-flags-02 [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 25th May 2022. >>> >>> 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-lsp-extended-flags/ >>> ___ >>> 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] WGLC for draft-ietf-pce-lsp-extended-flags-02
Hi, Dhruv and Quan: Is there any reason to define the extended flag in variable length? Should it be more reasonable that just define one 32 bit extended flag and if necessary, define another extended flag TLV? And, as I read section 3.2: https://www.ietf.org/archive/id/draft-ietf-pce-lsp-extended-flags-02.html#section-3.2 “…. … If a PCEP speaker receives the LSP-EXTENDED-FLAG TLV of a length less than the one supported by the implementation, it will consider the bits beyond the length to be unset. … ….” Will the above lead to misbehavior in some situations? Anyway, I recommend the fixed length(then the length field is unnecessary) and clear description/usages of each bit of the flag. Aijun Wang China Telecom > On May 11, 2022, at 21:28, Dhruv Dhody wrote: > > > Hi WG, > > This email starts a 2-weeks working group last call for > draft-ietf-pce-lsp-extended-flags-02 [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 25th May 2022. > > 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-lsp-extended-flags/ > ___ > 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-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. 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 3. Section 3.3 and 3.4 should be put in one independent section, such as “Application of the Path MTU Metric”? Best Regards Aijun Wang China Telecom From: 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] WGLC for draft-ietf-pce-vn-association-05
Hi, WG: I have read this draft and support its publication with the following suggestions from Adrian Farrel. Best Regards Aijun Wang China Telecom From: pce-boun...@ietf.org On Behalf Of Adrian Farrel Sent: Saturday, February 26, 2022 4:39 PM To: 'Dhruv Dhody' ; pce@ietf.org Cc: draft-ietf-pce-vn-associat...@ietf.org; 'pce-chairs' Subject: Re: [Pce] WGLC for draft-ietf-pce-vn-association-05 Hi, Here is my review of draft-ietf-pce-vn-association-05 as part of the WG last call. I think the document is technically ready to proceed, but it needs quite a bit of work to polish the text. After the number of edits I am proposing I feel like I have rewritten the document! My comments are below. Thanks, Adrian ==Minor== 3. In order to set up the end-to-end tunnel, multiple segments need to be stitched, by the border nodes in each domain who receives the instruction from their child PCE (PNC). What end-to-end tunnel? This has not been mentioned before and I can't see one in the figure. --- 3. Local polices on the PCE MAY define the computational and optimization behavior for the LSPs in the VN. Why is this "MAY"? Isn't it good enough to write: Local polices on the PCE define the computational and optimization behavior for the LSPs in the VN. --- 3. If an implementation encounters more than one VNAG, it MUST consider the first occurrence and ignore the others. I think... If an implementation encounters more than one VNAG object in a PCEP message, it MUST process the first occurrence and it MUST ignore the others. --- 3. Operator-configured Association Range MUST NOT be set for this association-type and MUST be ignored. I know what you are trying to say, but you have crossed the line into describing implementations. Perhaps OLD This Association-Type is dynamic in nature and created by the Parent PCE (MDSC) for the LSPs belonging to the same VN or customer. These associations are conveyed via PCEP messages to the PCEP peer. Operator-configured Association Range MUST NOT be set for this association-type and MUST be ignored. NEW The Association IDs (VNAG IDs) for this Association Type are dynamic in nature and created by the Parent PCE (MDSC) for the LSPs belonging to the same VN or customer. Operator configuration of VNAG IDs is not supported so there is no need for an Operator-configured Association Range to be set. Thus, the VN Association Type (TBD1) MUST NOT be present in the Operator-Configured Association Range TLV if that TLV is present in the OPEN object. If an implementation encounters the VN Association Type in an Operator-Configured Association Range TLV, it MUST ignore the associated Start-Assoc-ID and Range values. END --- 4. o VIRTUAL-NETWORK-TLV: Used to communicate the VN Identifier. It is confusing that you say VN Identifier (which sounds like VNAG identifier), but then the text and figure shows "VN name" or "Virtual Network Name". You need to: - select Identifier or Name - select VN or Virtual Network --- 4. (for VIRTUAL-NETWORK-TLV) Length: Variable Length Length of what and in what units? Just the Virtual Network Name or the whole TLV? Probably in octets. What is the maximum allowed value? Surely not 2^16. --- 4. How does internationalization work for the Virtual Network Name? Why is ASCII acceptable? --- 4. Does the Virtual Network Name need to be unique across all VNAGs? I suspect that it doesn't because its use is basically out of scope of this work. --- Does section 5 add anything to the document? There has already been discussion of parent and child PCEs and a lot of the material in this section is a direct quote from elsewhere in the document. I would suggest a very hard look to see whether anything needs to be retained or the whole section can be removed. --- 9.6 I think the whole point of this document is to change network operations --- ==Nits== LSP is going to need to be expanded on first use in each of: - the document title - the abstract - section 1 --- Abstract s/extend/extend the/ s/virtual network control/control of virtual networks/ s/using PCE/using the PCE/ --- 1. para 1 Should include a reference to RFC 5440 OLD computations in response to Path Computation Clients' (PCCs) requests. NEW computations in response to requests from Path Computation Clients (PCCs). END --- 1. OLD A stateful PCE has access to not only the information carried by the network's Interior Gateway Protocol (IGP), but also the set of active paths and their reserved resources for its computations. NEW For its computations, a state
Re: [Pce] draft-ietf-pce-pcep-extension-native-ip-14.txt---with HyperLink Correction
Hi, Susan: Thanks for your review. Have updated the Figure 4 in section 6.3 and will upload later together with other possible comments. Have sent the presentation material to Jie Dong for the coming IDR interim meeting on Aug. 23. Wish the brief introduction can help the experts in IDR and PCE get the key points of this solution. Thanks for your efforts. Best Regards Aijun Wang China Telecom From: Susan Hares Sent: Thursday, August 19, 2021 10:34 PM To: 'Aijun Wang' Cc: pce@ietf.org; 'idr-chairs' ; 'pce-chairs' ; 'Dongjie (Jimmy)' Subject: RE: [Pce] draft-ietf-pce-pcep-extension-native-ip-14.txt---with HyperLink Correction Aijun: The text changes you made were excellent. In section 6.3, it might be helpful to the reader to indicate which routers in figure 4 are BGP routers. Please plan to make a short presentation on this draft at the IDR interim on 8/23/2021. Please send your presentation to Jie Dong (Dongjie (Jimmy) jie.d...@huawei.com <mailto:jie.d...@huawei.com> by 8/22. Thank you, Susan Hares From: Aijun Wang [mailto:wangai...@tsinghua.org.cn] Sent: Monday, August 16, 2021 4:34 AM To: 'Susan Hares' Cc: pce@ietf.org <mailto:pce@ietf.org> ; 'idr-chairs'; 'pce-chairs' Subject: RE: [Pce] draft-ietf-pce-pcep-extension-native-ip-14.txt---with HyperLink Correction Hi, Susan: Thanks for your suggestions. I have uploaded the updated version of the draft. Wish to get your thorough review for this document. I am glad to make a short presentation on the IDR interim meeting on 10/11 for the overall solutions. Best Regards Aijun Wang China Telecom From: Susan Hares mailto:sha...@ndzh.com> > Sent: Friday, July 30, 2021 9:29 PM To: 'Aijun Wang' mailto:wangai...@tsinghua.org.cn> > Cc: pce@ietf.org <mailto:pce@ietf.org> ; 'idr-chairs' mailto:idr-cha...@ietf.org> >; 'pce-chairs' mailto:pce-cha...@ietf.org> > Subject: RE: [Pce] draft-ietf-pce-pcep-extension-native-ip-14.txt---with HyperLink Correction Aijun: Thank you for your kind response. Just a brief word on these comments. [Sue] Based on BGP policy, these routes may or may not be redistributed by the BGP peers. [WAJ] Such info will not be redistributed via BGP. The BGP session that established via BPI object will only advertise Prefixes that included in the PPA object. [Sue2] May I suggest then you add the following text if the PCE-BGP interface should not send the route: “Although the BGP policy might redistribute the routes installed by explicit route, the PCE-BGP implementation needs to prohibit the redistribution of the explicit route” distributed by …. I look forward to your next draft. I will provide reviews of sections 6 to the end of the draft. I’m pleased you are working on this draft as part of BGP auto-configuration efforts. I hope that you will consider a short presentation at the IDR interim on 10/11 regarding your efforts in PCE. Cheers, Sue From: Aijun Wang [mailto:wangai...@tsinghua.org.cn] Sent: Friday, July 30, 2021 9:08 AM To: Susan Hares Cc: pce@ietf.org <mailto:pce@ietf.org> ; idr-chairs; pce-chairs Subject: Re: [Pce] draft-ietf-pce-pcep-extension-native-ip-14.txt---with HyperLink Correction Hi, Susan: Thanks for your review! Detail responses are inlines below. Aijun Wang China Telecom On Jul 30, 2021, at 05:50, Susan Hares mailto:sha...@ndzh.com> > wrote: Aijun: I apologize for missing PCE session today. I re-injured a knee just before the session. Let me provide you suggestions for sections 6.1, 6.2, and 6.3 that may resolve some of the issues. This specification provides one mechanism for BGP auto-configuration. I’m happy to continue to review this draft and provide suggestions. Cheerily, Susan Hares Section 6.1 = Old text:/ The procedures for establishing the BGP session between two peers By using the PCInitiate and PCRpt message pair is show below: / New text:/ The PCInitiate message can be used to configure the parameters for a BGP peer session using the PCInitiate and PCRpt message pair. This pair of PCE messages is exchanged with a PCE function Attached to each BGP peer which needs to be configured. After the BGP peer session has been configured via this pair of PCE messages the BGP session establishment process operates in a normal fashion. All BGP peers are configured for peer to peer communication whether the peers are E-BGP peers or I-BGP peers. One of the IBGP topologies requires that multiple I-BGPs peers operate in a route-reflector I-BGP peer topology. The example below shows 2 I-BGP route reflector clients interacting with one Route Reflector (RR), but Route Reflector topologies may have up to 100s of clients. Centralized configuration via PCE provides
Re: [Pce] draft-ietf-pce-pcep-extension-native-ip-14.txt---with HyperLink Correction
Hi, Susan: Thanks for your suggestions. I have uploaded the updated version of the draft. Wish to get your thorough review for this document. I am glad to make a short presentation on the IDR interim meeting on 10/11 for the overall solutions. Best Regards Aijun Wang China Telecom From: Susan Hares Sent: Friday, July 30, 2021 9:29 PM To: 'Aijun Wang' Cc: pce@ietf.org; 'idr-chairs' ; 'pce-chairs' Subject: RE: [Pce] draft-ietf-pce-pcep-extension-native-ip-14.txt---with HyperLink Correction Aijun: Thank you for your kind response. Just a brief word on these comments. [Sue] Based on BGP policy, these routes may or may not be redistributed by the BGP peers. [WAJ] Such info will not be redistributed via BGP. The BGP session that established via BPI object will only advertise Prefixes that included in the PPA object. [Sue2] May I suggest then you add the following text if the PCE-BGP interface should not send the route: “Although the BGP policy might redistribute the routes installed by explicit route, the PCE-BGP implementation needs to prohibit the redistribution of the explicit route” distributed by …. I look forward to your next draft. I will provide reviews of sections 6 to the end of the draft. I’m pleased you are working on this draft as part of BGP auto-configuration efforts. I hope that you will consider a short presentation at the IDR interim on 10/11 regarding your efforts in PCE. Cheers, Sue From: Aijun Wang [mailto:wangai...@tsinghua.org.cn] Sent: Friday, July 30, 2021 9:08 AM To: Susan Hares Cc: pce@ietf.org <mailto:pce@ietf.org> ; idr-chairs; pce-chairs Subject: Re: [Pce] draft-ietf-pce-pcep-extension-native-ip-14.txt---with HyperLink Correction Hi, Susan: Thanks for your review! Detail responses are inlines below. Aijun Wang China Telecom On Jul 30, 2021, at 05:50, Susan Hares mailto:sha...@ndzh.com> > wrote: Aijun: I apologize for missing PCE session today. I re-injured a knee just before the session. Let me provide you suggestions for sections 6.1, 6.2, and 6.3 that may resolve some of the issues. This specification provides one mechanism for BGP auto-configuration. I’m happy to continue to review this draft and provide suggestions. Cheerily, Susan Hares Section 6.1 = Old text:/ The procedures for establishing the BGP session between two peers By using the PCInitiate and PCRpt message pair is show below: / New text:/ The PCInitiate message can be used to configure the parameters for a BGP peer session using the PCInitiate and PCRpt message pair. This pair of PCE messages is exchanged with a PCE function Attached to each BGP peer which needs to be configured. After the BGP peer session has been configured via this pair of PCE messages the BGP session establishment process operates in a normal fashion. All BGP peers are configured for peer to peer communication whether the peers are E-BGP peers or I-BGP peers. One of the IBGP topologies requires that multiple I-BGPs peers operate in a route-reflector I-BGP peer topology. The example below shows 2 I-BGP route reflector clients interacting with one Route Reflector (RR), but Route Reflector topologies may have up to 100s of clients. Centralized configuration via PCE provides mechanisms to scale auto-configuration of small and large topologies. [WAJ] Will update the draft later accordingly to your suggestions. old text:/ In the example in Figure 1, if the routers R1 and R7 are within one AS and R3 acts as a router reflector. PCInitiate message should be sent to route reflector clients R1 (M1) and R7 (M4),a nd the route reflector clients (R3 M2 & M3) respectively. For inter-AS scenario, such message can be sent directly to ASBR router to build EBGP session./ New text:/ The route reflector topology for a single AS is shown in Figure 1. The BGP routers R1, R3, and R7 are within a single AS. R1 and R7 are BGP router-reflector clients, and R3 is a Route Reflector. The PCInitiate message should be sent all of the BGP routers that need to be configured R1 (M3), R3 (M2 & M3), and R7 (M4). / [WAJ] Will update the draft later accordingly to your suggestions. --- Section 6.2. My understanding for your email is that the explicit route establishment procedures are installing a static route which is not to be redistributed via BGP peer. [WAJ] Yes, the information deployed via EPR object will not redistributed via BGP. If this understanding is correct, please clearly state this fact and modify the diagrams to indicate a static route A suggestion for text for this case is: Old text: / The detail procedures for the explicit route establishment procedures are sh
Re: [Pce] draft-ietf-pce-pcep-extension-native-ip-14.txt---with HyperLink Correction
Hi, Susan: Thanks for your review! Detail responses are inlines below. Aijun Wang China Telecom > On Jul 30, 2021, at 05:50, Susan Hares wrote: > > > Aijun: > > I apologize for missing PCE session today. I re-injured a knee just before > the session. Let me provide you suggestions for sections 6.1, 6.2, and 6.3 > that may resolve some of the issues. > > This specification provides one mechanism for BGP auto-configuration. I’m > happy to continue to review this draft and provide suggestions. > > Cheerily, Susan Hares > > > Section 6.1 > = > Old text:/ > The procedures for establishing the BGP session between two peers > By using the PCInitiate and PCRpt message pair is show below: / > > New text:/ > The PCInitiate message can be used to configure the parameters for > a BGP peer session using the PCInitiate and PCRpt message pair. > This pair of PCE messages is exchanged with a PCE function > Attached to each BGP peer which needs to be configured. > After the BGP peer session has been configured > via this pair of PCE messages the BGP session establishment process > operates in a normal fashion. > > All BGP peers are configured for peer to peer communication whether the > peers are E-BGP peers or I-BGP peers. One of the IBGP topologies > requires > that multiple I-BGPs peers operate in a route-reflector I-BGP peer > topology. > The example below shows 2 I-BGP route reflector clients interacting > with one Route Reflector (RR), but Route Reflector topologies may have > up to 100s of clients. Centralized configuration via PCE provides > mechanisms to scale auto-configuration of small and large topologies. [WAJ] Will update the draft later accordingly to your suggestions. > > old text:/ > In the example in Figure 1, if the routers R1 and R7 are within one AS > and R3 acts as a router reflector. PCInitiate message should be sent > to route reflector clients R1 (M1) and R7 (M4),a nd the route reflector > clients (R3 M2 & M3) respectively. For inter-AS scenario, such message > can be sent directly to ASBR router to build EBGP session./ > > New text:/ > The route reflector topology for a single AS is shown in Figure 1. > The BGP routers R1, R3, and R7 are within a single AS. R1 and R7 > are BGP router-reflector clients, and R3 is a Route Reflector. > > The PCInitiate message should be sent all of the BGP routers that > need to be configured R1 (M3), R3 (M2 & M3), and R7 (M4). / [WAJ] Will update the draft later accordingly to your suggestions. > > --- > Section 6.2. > > My understanding for your email is that the explicit route > establishment procedures are installing a static route > which is not to be redistributed via BGP peer. [WAJ] Yes, the information deployed via EPR object will not redistributed via BGP. > > If this understanding is correct, please clearly state this > fact and modify the diagrams to indicate a static route > A suggestion for text for this case is: > > Old text: / > The detail procedures for the explicit route establishment > procedures are show below. / > > New text: / > The explicit route establishment procedures can be used > to install a route via PCE in the PCC/BGP Peer. [WAJ] Correct. > Based on BGP policy, these routes may or may not > be redistributed by the BGP peers. [WAJ] Such info will not be redistributed via BGP. The BGP session that established via BPI object will only advertise Prefixes that included in the PPA object. > PCE explicit routes > operate similar to static routes installed > by network management protocols (netconf/restconf) > but the routes are associated with the PCE routing module. [WAJ]Correct > > An example of the use case where the of the use case where > explicit route installed by PCE is redistributed by BGP is > described in section 6.3. [WAJ] No. The information in EPR object is not redistributed by BGP. Section 6.3 describes how to deploy the prefixes that should be advertised by BGP session that established via BPI object. The information within PPA has no relation with the information in EPR object. > An example of the procedure > where the explicit route installed by PCE is not redistributed > by BGP is described in this section (see figure 2 below for the > topology). [WAJ]I think this sentence should be omitted. > Explicit route installations (like NM static routes) > must carefully install and uninstall static routes in an specific > order so that the pathways are established without loops. / [WAJ] Will update the draft later accordingly. >
Re: [Pce] draft-ietf-pce-pcep-extension-native-ip-14.txt---with HyperLink Correction
Hi, Susan, Mike and All other experts: I have just upload the updated version of this draft, would you like to review it again to refine it? And you can also refer the presentation on this IETF meeting for additional update introduction(https://datatracker.ietf.org/meeting/111/materials/slides-111-p ce-sessa-21-native-ip-00.pdf). Thanks in advance. Best Regards Aijun Wang China Telecom From: Susan Hares Sent: Wednesday, July 28, 2021 5:58 AM To: 'Aijun Wang' ; pce@ietf.org Cc: 'idr-chairs' ; 'pce-chairs' Subject: RE: [Pce] draft-ietf-pce-pcep-extension-native-ip-14.txt---with HyperLink Correction Aijun: Thank you for your quick response. I’ve answered questions below. Would you let me know when you update your draft? I’ll re-read the sections that changed and make additional suggestions. If you think it would be useful to add 2 (or more) next hops per EPR, please let me know. [WAJ] Adding 2 (or more) next hops per EPR is one viable solution to achieve the ECMP effects, but it seems that the current format is more flexible and extensible? For example, if we want to add the UCMP features, as Mike proposed, we can add some information within the “Optional TLV” field of the EPR to indicate what percentage traffic should be allocated to each nexthop. I’m glad to keep reviewing your changes. Cheers, Sue From: Aijun Wang [mailto:wangai...@tsinghua.org.cn] Sent: Tuesday, July 27, 2021 3:19 AM To: 'Susan Hares'; pce@ietf.org <mailto:pce@ietf.org> Cc: 'idr-chairs'; 'pce-chairs' Subject: RE: [Pce] draft-ietf-pce-pcep-extension-native-ip-14.txt---with HyperLink Correction Hi, Susan and all: Update one hyperlink on the contents, please refer to this mail for comments responses. From: pce-boun...@ietf.org <mailto:pce-boun...@ietf.org> mailto:pce-boun...@ietf.org> > On Behalf Of Aijun Wang Sent: Tuesday, July 27, 2021 12:04 PM To: 'Susan Hares' mailto:sha...@ndzh.com> >; pce@ietf.org <mailto:pce@ietf.org> Cc: 'idr-chairs' mailto:idr-cha...@ietf.org> >; 'pce-chairs' mailto:pce-cha...@ietf.org> > Subject: Re: [Pce] draft-ietf-pce-pcep-extension-native-ip-14.txt Hi, Susan: Thanks for your reviews, let me first address your current questions and wait for the further discussions on the overall solution. Best Regards Aijun Wang China Telecom From: pce-boun...@ietf.org <mailto:pce-boun...@ietf.org> mailto:pce-boun...@ietf.org> > On Behalf Of Susan Hares Sent: Tuesday, July 27, 2021 7:19 AM To: pce@ietf.org <mailto:pce@ietf.org> Cc: 'idr-chairs' mailto:idr-cha...@ietf.org> >; 'pce-chairs' mailto:pce-cha...@ietf.org> > Subject: [Pce] draft-ietf-pce-pcep-extension-native-ip-14.txt Greetings: Thank you for your work on draft-ietf-pce-pcep-extension-native-ip-14.txt. This comment should be consider feedback from me as a WG member of IDR and PCE. I have posted this information also on the This draft takes a step toward auto-configuration of BGP peers. IDR has created a set of requirements for BGP auto-configuration for Data Centers at: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-autoconf-considerations/ [WAJ] Yes, I have also reviewed this document and attended some discussions on it. The autoconf document tries to build the BGP from scratch without 3rd party(for example, PCE) assistance. It considers mainly the direct connected BGP peer setup process automatically and does not involve the prefix advertisement and explicit route setup. I think the aim of these two drafts is different but we can refer to some designed considerations from it. [Sue] You have understood that the bgp auto-configuration works on peer set-up. I simply wanted you to know that your PCE work linked that that work in BGP. I’ve put a copy of these comments at: https://trac.ietf.org/trac/idr/wiki/pce-pcep-extension-native-ip%20Hares%20c omments Cheers, Sue Comments on draft-ietf-pce-pcep-extension-native-ip-14 = Overview of errors 1) section 6 description of BGP routers needs clarification (sections 6.1, 6.2, and 6.3) for RR and RR Clients [WAJ] Please see the replies inline below. 2) BGP Session Establish Procedures �C are these restrict to RR and RR Clients? [WAJ] Yes. The BGP session is established between RR and its clients in large network. It can also be established between two nodes directly.(as described in https://datatracker.ietf.org/doc/html/rfc8821#section-3) The point �Cto-point (P2P) Peering was clear in RFC8821. [Sue] It would be useful to revise the draft to clearly define this is a single AS, RR location, and RR client locations. [WAJ] Has added some text as below. Actually, the procedures described in this draft is not limited to one AS, it can be applied to inter-AS scenario simultaneously. “In the example in Figure 1, if the router R1
Re: [Pce] Follow up about my question on the mic
Hi, Mike: Thanks for your suggestions. I have added the following sentences in section 6.2 as: "To accomplish ECMP effects, the PCE can send multiple EPR objects to the same node, with the same route priority and peer address value but different next hop addresses." Will update the draft later together with the comments from Susan. Thanks for your comments, would like to see your more suggestions on the solution. Best Regards Aijun Wang China Telecom From: mkold...@cisco.com Sent: Tuesday, July 27, 2021 8:41 PM To: Aijun Wang ; 'Mike Koldychev (mkoldych)' ; draft-ietf-pce-pcep-extension-native...@ietf.org Cc: pce@ietf.org Subject: RE: [Pce] Follow up about my question on the mic Hi Aijun, Thanks for clarifying Q1. Regarding Q2, you can probably mention that in the draft. Multiple EPR objects MAY be sent for the same destination, which results in ECMP to that destination. Thanks, Mike. From: Pce mailto:pce-boun...@ietf.org> > On Behalf Of Aijun Wang Sent: Monday, July 26, 2021 10:55 PM To: 'Mike Koldychev (mkoldych)' mailto:mkoldych=40cisco@dmarc.ietf.org> >; draft-ietf-pce-pcep-extension-native...@ietf.org <mailto:draft-ietf-pce-pcep-extension-native...@ietf.org> Cc: pce@ietf.org <mailto:pce@ietf.org> Subject: Re: [Pce] Follow up about my question on the mic Hi, Mike: Thanks for your questions. Please see the replies inline. If you have more questions based on the followings answers, we can discuss them accordingly. Best Regards Aijun Wang China Telecom From: pce-boun...@ietf.org <mailto:pce-boun...@ietf.org> mailto:pce-boun...@ietf.org> > On Behalf Of Mike Koldychev (mkoldych) Sent: Tuesday, July 27, 2021 6:36 AM To: draft-ietf-pce-pcep-extension-native...@ietf.org <mailto:draft-ietf-pce-pcep-extension-native...@ietf.org> Cc: pce@ietf.org <mailto:pce@ietf.org> Subject: [Pce] Follow up about my question on the mic Hi Authors, Just following up about my 2 questions during the PCE WG session about https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-native-i p-14. Question 1: Is every prefix going to be advertised (via the RR) to every node in the native-ip domain, even if those nodes are never on-path for that prefix? [WAJ] Yes, the behavior of RR is unchanged. If my understanding is correct, the "BGP peer nodes" (R1 & R7 in Figure 4) would receive the PPA (Prefixes) and would inject these prefixes into the RR. The RR would then flood these prefixes (as regular BGP IP routes) to every single node in the domain (R2, R4, R5, R6) with the next-hop being set to R1 or R7. Please let me know if my understanding is correct or am I missing something. So even though R5 and R6 in this example are off-path, they would receive the prefix route from the RR? [WAJ] Yes, R5 and R6 will also receive such prefix advertisements via the normal RR behavior. But on router R5, the route to the BGP nexthop (R1) is learned from the IGP protocol, not from the EPR(Explicit Peer Route) Object. Then after the recursive process, the forwarding path on R5 will be along the normal non-optimal path. Question 2: Have you thought about ECMP/UCMP (Equal/Unequal Cost Multipath)? How would you implement it in your protocol? [WAJ] Currently, we consider only the ECMP application. If PCE wants to deploy multiple ECMP paths between two adjacent nodes, it can send two EPR Objects to the corresponding PCC, with the "Route Priority" field be set to the same value. Thanks, Mike. ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] draft-ietf-pce-pcep-extension-native-ip-14.txt---with HyperLink Correction
Hi, Susan and all: Update one hyperlink on the contents, please refer to this mail for comments responses. From: pce-boun...@ietf.org On Behalf Of Aijun Wang Sent: Tuesday, July 27, 2021 12:04 PM To: 'Susan Hares' ; pce@ietf.org Cc: 'idr-chairs' ; 'pce-chairs' Subject: Re: [Pce] draft-ietf-pce-pcep-extension-native-ip-14.txt Hi, Susan: Thanks for your reviews, let me first address your current questions and wait for the further discussions on the overall solution. Best Regards Aijun Wang China Telecom From: pce-boun...@ietf.org <mailto:pce-boun...@ietf.org> mailto:pce-boun...@ietf.org> > On Behalf Of Susan Hares Sent: Tuesday, July 27, 2021 7:19 AM To: pce@ietf.org <mailto:pce@ietf.org> Cc: 'idr-chairs' mailto:idr-cha...@ietf.org> >; 'pce-chairs' mailto:pce-cha...@ietf.org> > Subject: [Pce] draft-ietf-pce-pcep-extension-native-ip-14.txt Greetings: Thank you for your work on draft-ietf-pce-pcep-extension-native-ip-14.txt. This comment should be consider feedback from me as a WG member of IDR and PCE. I have posted this information also on the This draft takes a step toward auto-configuration of BGP peers. IDR has created a set of requirements for BGP auto-configuration for Data Centers at: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-autoconf-considerations/ [WAJ] Yes, I have also reviewed this document and attended some discussions on it. The autoconf document tries to build the BGP from scratch without 3rd party(for example, PCE) assistance. It considers mainly the direct connected BGP peer setup process automatically and does not involve the prefix advertisement and explicit route setup. I think the aim of these two drafts is different but we can refer to some designed considerations from it. I’ve put a copy of these comments at: https://trac.ietf.org/trac/idr/wiki/pce-pcep-extension-native-ip%20Hares%20c omments Cheers, Sue Comments on draft-ietf-pce-pcep-extension-native-ip-14 = Overview of errors 1) section 6 description of BGP routers needs clarification (sections 6.1, 6.2, and 6.3) for RR and RR Clients [WAJ] Please see the replies inline below. 2) BGP Session Establish Procedures �C are these restrict to RR and RR Clients? [WAJ] Yes. The BGP session is established between RR and its clients in large network. It can also be established between two nodes directly.(as described in https://datatracker.ietf.org/doc/html/rfc8821#section-3) 3) Explicit routes [section 6.2] �C Is ECMP support as well as 1 prefix/1 next Hop? [WAJ] Yes, ECMP is supported. PCE needs to send two EPR(Explicit Peer Route) objects, with the same “Destination Adress” and “Route Priority”, but different “Next Hop Address” 4) IPv4/IPv6 restrictions [section 6.3] �C are you restricting the peer session or the AFI/SAFI supported by the Peer session? [WAJ] AFI/SAFI supported by the peer session. 5) Sections 7, 9, and 10 �C may need to change based on your answers to questions 1-4? Detailed questions - 1. Section 6 �C sub sections 6.1, 6.2 and 6.3. Problem: The text that describe the BGP peers and the diagram needs clarification on the BGP peering between BGP peers: R1, R7, and R3. If R1 and R7 are Route Reflector clients (RR clients) are attached to the R3 then it is important to indicate this point. [WAJ] Yes, R1 and R7 is RR clients. If you are using classic route reflection, then R1, R3 and R7 would need to be in the same Autonomous system. [WAJ] Yes, certainly. The RR (R3) determines what routes are sent to the RR clients. This problem impacts the text in section 6.1, 6.2, and 6.3 2.) Text change for Section 6.1 �C if R1 and R7 are RR clients. Here’s a change if R1 and R7 are Router Reflector Clients. Current text: / The PCInitiate message should be sent to PCC which acts as BGP router and route reflector(RR). In the example in Figure 1, it should be sent to R1(M1), R3(M2 & M3) and R7(M4), when R3 acts as RR./ Improved text: / The PCInitiate message should be sent to PCC which acts as BGP router reflector or a route reflector client. In the example in Figure 1, it should be sent to the route reflector clients R1(M1) and R7 (M4), and the route reflector R3 (M1 or M4)./ [WAJ] Has updated the draft with the following contents(almost same as your suggestions): The PCInitiate message should be sent to PCC which acts as BGP router and/or route reflector(RR). In the example in Figure 1, it should be sent to route reflector clients R1(M1) and R7(M4), and the route reflector R3(M2 & M3) when R3 acts as RR. PCInitiate message creates an auto-configuration function for these BGP peers providing the indicated Peer AS and the Local/Peer IP Address. 3) Section 6.1 �C BGP Session Establishment Procedure Question: Does the PC
Re: [Pce] draft-ietf-pce-pcep-extension-native-ip-14.txt
Hi, Susan: Thanks for your reviews, let me first address your current questions and wait for the further discussions on the overall solution. Best Regards Aijun Wang China Telecom From: pce-boun...@ietf.org On Behalf Of Susan Hares Sent: Tuesday, July 27, 2021 7:19 AM To: pce@ietf.org Cc: 'idr-chairs' ; 'pce-chairs' Subject: [Pce] draft-ietf-pce-pcep-extension-native-ip-14.txt Greetings: Thank you for your work on draft-ietf-pce-pcep-extension-native-ip-14.txt. This comment should be consider feedback from me as a WG member of IDR and PCE. I have posted this information also on the This draft takes a step toward auto-configuration of BGP peers. IDR has created a set of requirements for BGP auto-configuration for Data Centers at: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-autoconf-considerations/ [WAJ] Yes, I have also reviewed this document and attended some discussions on it. The autoconf document tries to build the BGP from scratch without 3rd party(for example, PCE) assistance. It considers mainly the direct connected BGP peer setup process automatically and does not involve the prefix advertisement and explicit route setup. I think the aim of these two drafts is different but we can refer to some designed considerations from it. I’ve put a copy of these comments at: https://trac.ietf.org/trac/idr/wiki/pce-pcep-extension-native-ip%20Hares%20c omments Cheers, Sue Comments on draft-ietf-pce-pcep-extension-native-ip-14 = Overview of errors 1) section 6 description of BGP routers needs clarification (sections 6.1, 6.2, and 6.3) for RR and RR Clients [WAJ] Please see the replies inline below. 2) BGP Session Establish Procedures �C are these restrict to RR and RR Clients? [WAJ] Yes. The BGP session is established between RR and its clients in large network. It can also be established between two nodes directly.(as described in https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-autoconf-considerations/ ) 3) Explicit routes [section 6.2] �C Is ECMP support as well as 1 prefix/1 next Hop? [WAJ] Yes, ECMP is supported. PCE needs to send two EPR(Explicit Peer Route) objects, with the same “Destination Adress” and “Route Priority”, but different “Next Hop Address” 4) IPv4/IPv6 restrictions [section 6.3] �C are you restricting the peer session or the AFI/SAFI supported by the Peer session? [WAJ] AFI/SAFI supported by the peer session. 5) Sections 7, 9, and 10 �C may need to change based on your answers to questions 1-4? Detailed questions - 1. Section 6 �C sub sections 6.1, 6.2 and 6.3. Problem: The text that describe the BGP peers and the diagram needs clarification on the BGP peering between BGP peers: R1, R7, and R3. If R1 and R7 are Route Reflector clients (RR clients) are attached to the R3 then it is important to indicate this point. [WAJ] Yes, R1 and R7 is RR clients. If you are using classic route reflection, then R1, R3 and R7 would need to be in the same Autonomous system. [WAJ] Yes, certainly. The RR (R3) determines what routes are sent to the RR clients. This problem impacts the text in section 6.1, 6.2, and 6.3 2.) Text change for Section 6.1 �C if R1 and R7 are RR clients. Here’s a change if R1 and R7 are Router Reflector Clients. Current text: / The PCInitiate message should be sent to PCC which acts as BGP router and route reflector(RR). In the example in Figure 1, it should be sent to R1(M1), R3(M2 & M3) and R7(M4), when R3 acts as RR./ Improved text: / The PCInitiate message should be sent to PCC which acts as BGP router reflector or a route reflector client. In the example in Figure 1, it should be sent to the route reflector clients R1(M1) and R7 (M4), and the route reflector R3 (M1 or M4)./ [WAJ] Has updated the draft with the following contents(almost same as your suggestions): The PCInitiate message should be sent to PCC which acts as BGP router and/or route reflector(RR). In the example in Figure 1, it should be sent to route reflector clients R1(M1) and R7(M4), and the route reflector R3(M2 & M3) when R3 acts as RR. PCInitiate message creates an auto-configuration function for these BGP peers providing the indicated Peer AS and the Local/Peer IP Address. 3) Section 6.1 �C BGP Session Establishment Procedure Question: Does the PCEInitiate (message and report) require the RR and RR client structure? [WAJ] No. not necessary. The BGP session setup procedures is same between RR and its clients. If so, the PCInitiate should have a parameter indicate what type of BGP peer (RR or RR client) each receiving BGP peer should be. 4) Section 6.2 �C Explicit Route Establishment Procedure Problem: It is unclear what the impact to the routing system of the setting of explicit route. Basic Details: (1 Rout
Re: [Pce] Follow up about my question on the mic
Hi, Mike: Thanks for your questions. Please see the replies inline. If you have more questions based on the followings answers, we can discuss them accordingly. Best Regards Aijun Wang China Telecom From: pce-boun...@ietf.org On Behalf Of Mike Koldychev (mkoldych) Sent: Tuesday, July 27, 2021 6:36 AM To: draft-ietf-pce-pcep-extension-native...@ietf.org Cc: pce@ietf.org Subject: [Pce] Follow up about my question on the mic Hi Authors, Just following up about my 2 questions during the PCE WG session about https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-native-i p-14. Question 1: Is every prefix going to be advertised (via the RR) to every node in the native-ip domain, even if those nodes are never on-path for that prefix? [WAJ] Yes, the behavior of RR is unchanged. If my understanding is correct, the "BGP peer nodes" (R1 & R7 in Figure 4) would receive the PPA (Prefixes) and would inject these prefixes into the RR. The RR would then flood these prefixes (as regular BGP IP routes) to every single node in the domain (R2, R4, R5, R6) with the next-hop being set to R1 or R7. Please let me know if my understanding is correct or am I missing something. So even though R5 and R6 in this example are off-path, they would receive the prefix route from the RR? [WAJ] Yes, R5 and R6 will also receive such prefix advertisements via the normal RR behavior. But on router R5, the route to the BGP nexthop (R1) is learned from the IGP protocol, not from the EPR(Explicit Peer Route) Object. Then after the recursive process, the forwarding path on R5 will be along the normal non-optimal path. Question 2: Have you thought about ECMP/UCMP (Equal/Unequal Cost Multipath)? How would you implement it in your protocol? [WAJ] Currently, we consider only the ECMP application. If PCE wants to deploy multiple ECMP paths between two adjacent nodes, it can send two EPR Objects to the corresponding PCC, with the "Route Priority" field be set to the same value. Thanks, Mike. ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] I-D Action: draft-ietf-pce-pcep-extension-native-ip-14.txt
Hi, All PCE experts:
The main updates of this version are the followings:
1. Add the "Tunnel Source IP Address/Destination IP Address" fields
within the BPI(BGP Peer Info) Object to indicate the tunnel endpoints when
traffic between the head and end needs to be via a tunnel.
There are situation that the traffic should be forwarded via one tunnel to
ensure only the traffic that match both (source prefix, destination prefix)
needs to be QoS assured.
The (source prefix, destination prefix) is advertised via the associated BGP
session.
2. Introduce the "T" bit in the BPI Object to indicate whether the
traffic will be passed via the tunnel or not.
3. The info within the EPR(Explicit Peer Route) Object will also be
filled based on the "T" bit in BPI Object.
4. Other editorial changes which were highlighted at
https://www.ietf.org/rfcdiff?difftype=--hwdiff=draft-ietf-pce-pcep-exte
nsion-native-ip-14.txt
Look forwards to your comments on these changes.
And, if there is no comments on the above updates, we would like to ask the
WG to begin the WG Last Call for this document.
Thanks in advance.
Best Regards
Aijun Wang
China Telecom
-Original Message-
From: pce-boun...@ietf.org On Behalf Of
internet-dra...@ietf.org
Sent: Monday, June 7, 2021 10:30 AM
To: i-d-annou...@ietf.org
Cc: pce@ietf.org
Subject: [Pce] I-D Action: draft-ietf-pce-pcep-extension-native-ip-14.txt
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Path Computation Element WG of the IETF.
Title : PCEP Extension for Native IP Network
Authors : Aijun Wang
Boris Khasanov
Sheng Fang
Ren Tan
Chun Zhu
Filename: draft-ietf-pce-pcep-extension-native-ip-14.txt
Pages : 28
Date: 2021-06-06
Abstract:
This document defines the Path Computation Element Communication
Protocol (PCEP) extension for Central Control Dynamic Routing (CCDR)
based application in Native IP network. The scenario and framework
of CCDR in native IP is described in [RFC8735] and [RFC8821]. This
draft describes the key information that is transferred between Path
Computation Element (PCE) and Path Computation Clients (PCC) to
accomplish the End to End (E2E) traffic assurance in Native IP
network under central control mode.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/
There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-native-i
p-14
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pcep-extension-native-ip-14
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
___
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] draft-dhodylee-pce-pcep-te-data-extn
Hi, Also as a telco, we are expecting the implementation of PCEP-LS, and once it is ready, we will try to deploy it in the network. Best Regards Aijun Wang China Telecom From: pce-boun...@ietf.org On Behalf Of ???(Naas Transformation ?) Sent: Friday, April 2, 2021 9:14 AM To: Gyan Mishra ; pce@ietf.org; draft-dhodylee-pce-pcep...@ietf.org; Dhruv Dhody ; Adrian Farrel Subject: Re: [Pce] draft-dhodylee-pce-pcep-te-data-extn Dear Gyan, As a telco, we are interested in the upgrade of PCEP. PCEP and H-PCE scenarios is always being considered as valuable tools for solving our issues in telco’s multi-domain environment. Regards, Peter From: Gyan Mishra mailto:hayabusa...@gmail.com> > Sent: Thursday, March 18, 2021 11:36 AM To: pce@ietf.org <mailto:pce@ietf.org> ; draft-dhodylee-pce-pcep...@ietf.org <mailto:draft-dhodylee-pce-pcep...@ietf.org> ; Dhruv Dhody mailto:d...@dhruvdhody.com> >; Adrian Farrel mailto:adr...@olddog.co.uk> > Subject: [Pce] draft-dhodylee-pce-pcep-te-data-extn Dear PCE WG, We presented the PCEP-LS [1] I-D [2] in the IETF 110 with a quick recap and a summary of past discussions. Some new scenarios such as PCECC, H-PCE were highlighted where the PCEP session could be reused. This is an experimental I-D with the aim to progress research and development efforts. This work is not a replacement for any of the existing mechanisms. There are specific scenarios highlighted where the reuse of PCEP sessions for this information is deemed useful. To make progress, it may not be useful to rehash the beauty context between everyone's favorite protocol :). What would be useful would be - finding out if there is still interest in this experimental work by some in the WG; are there strong technical objections for the experiment in its limited scope etc... As a next step, it would be good to define the scope of the experiments and expected output especially targeting the scalability concerns as well as impact in other protocols and the network, etc. Thanks! Gyan (on behalf of co-authors) [1] https://datatracker.ietf.org/meeting/110/materials/slides-110-pce-42-pcep-ls-00.pdf [2] https://datatracker.ietf.org/doc/draft-dhodylee-pce-pcep-ls/ == <http://www.verizon.com/> Gyan Mishra Network Solutions Architect Email gyan.s.mis...@verizon.com <mailto:gyan.s.mis...@verizon.com> M 301 502-1347 <https://gov-dooray.com/mail-receipts?img=505164536d774c31-255f27ea7e6d48ae-295471e8682825ad-295472e655bcd410.gif> 이 메일은 지정된 수취인만을 위해 작성되었으며, 중요한 정보나 저작권을 포함하고 있을 수 있습니다. 어떠한 권한 없이, 본 문서에 포함된 정보의 전부 또는 일부를 무단으로 제3자에게 공개, 배포, 복사 또는 사용하는 것을 엄격히 금지합니다. 만약, 본 메일이 잘못 전송된 경우, 발신인 또는 당사에 알려주시고, 본 메일을 즉시 삭제하여 주시기 바랍니다. This E-mail may contain confidential information and/or copyright material. This email is intended for the use of the addressee only. If you receive this email by mistake, please either delete it without reproducing, distributing or retaining copies thereof or notify the sender immediately. ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] draft-hsd-pce-sr-p2mp-policy wiki comments and action.
Hi, My consideration is that if the solution depends on the distribution protocol among the underlay nodes to accomplish the task, then PCE should follow the procedures described in RFC8231, RFC8281 etc. That is to say, in such situation, the instruction from the PCE needs only to be sent to the headend of the path. And, if the solution depends solely on the computation of the PCE, and PCE should interact not only the headend node, but also the transit node, tail-end node, follow the PCECC approach is more clear. Mixed of these two solutions should be avoided. Best Regards Aijun Wang China Telecom From: pce-boun...@ietf.org On Behalf Of Dhruv Dhody Sent: Monday, March 22, 2021 12:48 PM To: Bidgoli, Hooman (Nokia - CA/Ottawa) Cc: pce@ietf.org Subject: Re: [Pce] draft-hsd-pce-sr-p2mp-policy wiki comments and action. Hi Hooman, On Thu, Mar 18, 2021 at 10:06 PM Bidgoli, Hooman (Nokia - CA/Ottawa) mailto:hooman.bidg...@nokia.com> > wrote: Hi Dhruv I am very confused by your messaging. Originally it was pointed out that the draft should follow PCECC/CCI. The authors explained why they feel that is not a good fit. Now you are mentioning get in part with RFC 8231, 8281 etc... which is a new input. Thank you. I apologize if I was not clear. As I said in the mail, I still feel PCECC is the way to go. What I want to highlight is that if you consider it as an LSP operation instead, then it should be built on RFC 8623 (P2MP) instead. The 'recap' was to show how the extensions in PCEP have been done for SR and P2MP in the past in a consistent way. The authors/co-authors have tried to keep the draft in par with all the RFCs that you mentioned as much as possible. As it is mentioned in the draft clearly. That said this is new concept and there is a need for a new PCE concept and deviation, hence the draft and the purpose of IETF. RSVP-TE P2MP is built via S2Ls. Replication segment is nothing like S2L, replication segment can be connected via unicast SR. If you claim that the replication segment can not use RFC 8623, that gives it more of a reason to not consider it as an LSP operation in the first place. Again we are open for any constructive feedback on how this draft can be improved, in the boundary of https://datatracker.ietf.org/doc/draft-ietf-spring-sr-replication-segment/ https://datatracker.ietf.org/doc/draft-ietf-pim-sr-p2mp-policy/ Just to clarify, my feedback is on your choice of PCEP procedure and encoding for the replication segment taking existing PCEP extensions/procedures in mind. Hope the discussion was useful, it was for me... Thanks! Dhruv (as a WG member) Regards Hooman -Original Message- From: Pce mailto:pce-boun...@ietf.org> > On Behalf Of Dhruv Dhody Sent: Thursday, March 18, 2021 8:01 AM To: pce@ietf.org <mailto:pce@ietf.org> Subject: Re: [Pce] draft-hsd-pce-sr-p2mp-policy wiki comments and action. Hi, Speaking as a WG member... Let's continue the discussion on considering the replication segment as an LSP v/s PCECC operation. I just wanted to quickly recap - - We have stateful operations for RSVP-TE: RFC 8231, RFC 8281 - We then introduced SR with a minimal extension of new PST and a new SR-ERO subobject: RFC 8664 - We supported P2MP stateful operations for RSVP-TE with RBNF change in PCEP messages: RFC 8623 We have always tried our best to maintain consistency between RSVP-TE and SR in PCEP. Now, if one considers the Replication segment as an LSP operation, IMHO it needs to be built on RFC 8623 P2MP LSP operations. The current approach does not build on RFC 8623 instead uses the multi-path technique (related to ECMP in P2P [1]). This would deviate from RFC 8623 significantly. On the other hand, considering the replication segment as a PCECC/CCI operation gives you more leeway to choose an encoding with a new CCI Object type for the replication segment and it could be independent of RFC 8623. I *still* feel PCECC makes more sense at the higher level too (because of the additional instruction to the leaves and coordination required). Even if one disagrees with that and considers it an LSP operation, it then needs to build on RFC 8623. The current "mashup" approach (i.e. it is an LSP operation but does not follow P2MP LSP encoding) does not work well in maintaining consistency within our extensions. Thanks! Dhruv (as a WG member) [1] https://datatracker.ietf.org/doc/draft-koldychev-pce-multipath/ ___ Pce mailing list Pce@ietf.org <mailto:Pce@ietf.org> https://www.ietf.org/mailman/listinfo/pce ___ Pce mailing list Pce@ietf.org <mailto: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 Last Call for draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation)
Hi, 1. The concept of PCC requests the allocating of BSID for a LSP is clear, but the scenario that PCE allocate the BSID is not convincible. PCE can request the PCC to allocate the BSID for one LSP. It should not allocate the value directly. 2. What's the reason to include the BT=3, that is "SRv6 Endpoint Behavior and SID Structure"? It is one general information and not close connection to the normal usage of BSID. 3. Will it be more clear to define one new bit(R bit) within the Flag field of "TE-PATH-BINDING TLV" to indicate clearly the remove of BSID allocation to a LSP? Instead of the implicit method that depending on the presence of TE-PATH-BINDING TLV as described in current draft? 4. For BT=0, the length is set to 7. How to skip the padding trailing zeros to a 4-octet boundary when parsing? Best Regards Aijun Wang China Telecom -Original Message- From: pce-boun...@ietf.org On Behalf Of julien.meu...@orange.com Sent: Thursday, March 18, 2021 7:09 PM To: pce@ietf.org Cc: draft-ietf-pce-binding-label-...@ietf.org Subject: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation) Hi all, This message initiates a 2-week PCE WG Last Call for draft-ietf-pce-binding-label-sid-07. Please review and share your feedback, whatever it is, using the PCE mailing list. This WGLC will end on Thursday April 1st (no kidding). Moreover, we have received a request from the authors for a code point allocation to support interoperability testing. RFC 7120 requires to meet the following criteria to proceed: b. The format, semantics, processing, and other rules related to handling the protocol entities defined by the code points (henceforth called "specifications") must be adequately described in an Internet-Draft. c. The specifications of these code points must be stable; i.e., if there is a change, implementations based on the earlier and later specifications must be seamlessly interoperable. If anyone believes that the draft does not meet these criteria, or believes that early allocation is not appropriate for any other reason, please send an email to the PCE mailing list explaining why. If the chairs hear no objections by Thursday, March 25th, we will kick off the "early" allocation request. Thanks, Dhruv & Julien _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] Adoption of draft-xiong-pce-lsp-flag-03
Hi, Dhruv: Yes, support its adoption. I think the extension can give more spaces to describe the future state of LSP. One question, is it necessary to be variable length? How to keep align when the bit position is fixed but the length is variable? Aijun Wang China Telecom > On Feb 16, 2021, at 19:29, Dhruv Dhody wrote: > > > Hi WG, > > We *need* to hear from more of you before taking a call on adoption. It is a > straightforward "house-keeping" document, but we need to see explicit > expressions of support (and comments). > > We are extending the call till Friday, Feb 19th. Please respond with your > support (or not) for this adoption. > > Regards, > Dhruv & Julien > >> On Mon, Feb 1, 2021 at 11:17 PM Dhruv Dhody wrote: >> Hi WG, >> >> This email begins the WG adoption poll for draft-xiong-pce-lsp-flag-03. >> >> https://datatracker.ietf.org/doc/html/draft-xiong-pce-lsp-flag-03 >> >> This is a small draft that extends the flags in the LSP Objects by >> defining a new LSP-EXTENDED-FLAG TLV. Note that the existing >> sub-registry "LSP Object Flag Field" is almost fully assigned. >> >> https://www.iana.org/assignments/pcep/pcep.xhtml#lsp-object-flag-field >> >> 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 15th Feb. >> >> 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] I-D Action: draft-ietf-pce-pcep-extension-native-ip-10.txt
Hi, All:
The main updated contents of this draft are the followings:
1. Make clear again the key procedures to accomplish the Native IP TE
process(BGP Session Establish/Explicit Route Establish/BGP Prefix
Advertisement).
2.Update the definition of new introduced Object, for future extension.
3.Add "End to End Path Protection" section for the E2E backup path.
4.Add several parts for the "IANA consideration", to include the new path
setup type, PCECC-CAPABILITY, PCEP Object and PCEP-Error Object.
Wish to get your comments for the update. We are also preparing for the
presentation in coming IETF meeting.
Best Regards
Aijun Wang
China Telecom
-Original Message-
From: pce-boun...@ietf.org On Behalf Of
internet-dra...@ietf.org
Sent: Friday, February 5, 2021 11:58 AM
To: i-d-annou...@ietf.org
Cc: pce@ietf.org
Subject: [Pce] I-D Action: draft-ietf-pce-pcep-extension-native-ip-10.txt
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Path Computation Element WG of the IETF.
Title : PCEP Extension for Native IP Network
Authors : Aijun Wang
Boris Khasanov
Sheng Fang
Ren Tan
Chun Zhu
Filename: draft-ietf-pce-pcep-extension-native-ip-10.txt
Pages : 26
Date: 2021-02-04
Abstract:
This document defines the Path Computation Element Communication
Protocol (PCEP) extension for Central Control Dynamic Routing (CCDR)
based application in Native IP network. The scenario and framework
of CCDR in native IP is described in [RFC8735] and
[I-D.ietf-teas-pce-native-ip]. This draft describes the key
information that is transferred between Path Computation Element
(PCE) and Path Computation Clients (PCC) to accomplish the End to End
(E2E) traffic assurance in Native IP network under central control
mode.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/
There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-pce-pcep-extension-native-ip-10
https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-native-i
p-10
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pcep-extension-native-ip-10
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
___
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] WGLC for draft-ietf-pce-association-policy
Hi, Dhruv: Reusing "Association Error/Operator-configured association information mismatch" can give some clues, but it does not yet hit the crucial point. The content of this draft has illustrated some possible reasons ---(e.g. out of range value, badly encoded value...), but the returned error information blends them together again. Can we define some new error-value to reflect them more clearly? I think the parser of the association policy can give the detail information. And, seems no authors of this draft to response these questions? Best Regards Aijun Wang China Telecom -Original Message- From: Dhruv Dhody [mailto:d...@dhruvdhody.com] Sent: Monday, September 21, 2020 7:04 PM To: Aijun Wang Cc: pce@ietf.org; draft-ietf-pce-association-pol...@ietf.org; pce-chairs Subject: Re: [Pce] WGLC for draft-ietf-pce-association-policy Hi Aijun, See inline... On Mon, Sep 21, 2020 at 7:46 AM Aijun Wang wrote: > > HI, Dhruv and the authors this draft: > > How to ensure the interoperability? The document just says: > "Further, if one or more parameters received in the POLICY-PARAMETERS-TLV > received by the PCEP speaker are considered as unacceptable in the context of > the >associated policy (e.g. out of range value, badly encoded value...), the > PCEP speaker MUST NOT apply the received policy and SHOULD log this event." > There will be no more detail error information can be reported via such > opaque policy. How to debug the policy deployment then? > I agree, it would be wise to generate an error, we could reuse the error from RFC 8697. How about -> Further, if one or more parameters received in the POLICY-PARAMETERS-TLV received by the PCEP speaker are considered as unacceptable in the context of the associated policy (e.g. out of range value, badly encoded value...), the PCEP speaker MUST reject the PCEP message and send a PCErr message with Error-Type 26 "Association Error" and Error-Value 5 "Operator-configured association information mismatch" [RFC8697]. PCEP speaker SHOULD log this event. > And, if there are some examples to show what association requirements can't > be accomplished by the SVEC object, and can only be done via PAG, the > document may be more convincible. > SVEC object has an impact only on the diversity association and it was covered in https://www.rfc-editor.org/rfc/rfc8800.html#name-relationship-to-svec. Your suggestion to add an example is a good idea. Can the authors consider adding something in the appendix? Thanks! Dhruv [ still without hats :) ] > > Best Regards > > Aijun Wang > China Telecom > > -Original Message----- > From: Dhruv Dhody [mailto:d...@dhruvdhody.com] > Sent: Friday, September 18, 2020 12:40 PM > To: Aijun Wang > Cc: pce@ietf.org; draft-ietf-pce-association-pol...@ietf.org; > pce-chairs > Subject: Re: [Pce] WGLC for draft-ietf-pce-association-policy > > Hi Aijun, > > Thank you for your comments. > > I wanted to focus on the 3rd point. I remember this being discussed perhaps > in the previous incarnation of the draft. The main motivation in PCEP is to > provide a "standard" container and mechanism to associate (and encode the > policy) and leave the actual policy standardization out of the scope of PCEP. > > Another way to look at this would be, when a policy is well-known and needs > to be standardized (some may consider diversity or SR-Policy as those > policies), we define a new standard association-type for it with a standard > TLV. This I-D is used when we do not have a standard policy defined in PCEP > but would like to use the protocol as an opaque container to associate > policies to the path. What does that policy mean and how to encode/decode the > policy parameters are expected to be done out-of-band via other mechanisms > which are better suited for policy definitions and configurations at the PCEP > speakers. Hope this helps! > > Thanks! > Dhruv (hat-less!) > > On Fri, Sep 18, 2020 at 6:43 AM Aijun Wang wrote: > > > > Hi, Authors: > > > > I Just have a quick view of this draft, and has some points wanted > > to be > > clarified: > > 1. This draft defines one new association type (policy association > > type) that follows the procedures described in RFC8697 and attached > > TLV? Is it right? > > 2. According to the text described in > > https://tools.ietf.org/html/rfc8697#section-3.2, to define one new > > association type, the related draft should clarify its relationship > > between the SVEC object, if any. > > Should this draft to add such part? > > 3. For the definition of "Policy-Parameters-TLV", the "Policy > > Parameters" is opa
Re: [Pce] WGLC for draft-ietf-pce-association-policy
HI, Dhruv and the authors this draft: How to ensure the interoperability? The document just says: "Further, if one or more parameters received in the POLICY-PARAMETERS-TLV received by the PCEP speaker are considered as unacceptable in the context of the associated policy (e.g. out of range value, badly encoded value...), the PCEP speaker MUST NOT apply the received policy and SHOULD log this event." There will be no more detail error information can be reported via such opaque policy. How to debug the policy deployment then? And, if there are some examples to show what association requirements can't be accomplished by the SVEC object, and can only be done via PAG, the document may be more convincible. Best Regards Aijun Wang China Telecom -Original Message- From: Dhruv Dhody [mailto:d...@dhruvdhody.com] Sent: Friday, September 18, 2020 12:40 PM To: Aijun Wang Cc: pce@ietf.org; draft-ietf-pce-association-pol...@ietf.org; pce-chairs Subject: Re: [Pce] WGLC for draft-ietf-pce-association-policy Hi Aijun, Thank you for your comments. I wanted to focus on the 3rd point. I remember this being discussed perhaps in the previous incarnation of the draft. The main motivation in PCEP is to provide a "standard" container and mechanism to associate (and encode the policy) and leave the actual policy standardization out of the scope of PCEP. Another way to look at this would be, when a policy is well-known and needs to be standardized (some may consider diversity or SR-Policy as those policies), we define a new standard association-type for it with a standard TLV. This I-D is used when we do not have a standard policy defined in PCEP but would like to use the protocol as an opaque container to associate policies to the path. What does that policy mean and how to encode/decode the policy parameters are expected to be done out-of-band via other mechanisms which are better suited for policy definitions and configurations at the PCEP speakers. Hope this helps! Thanks! Dhruv (hat-less!) On Fri, Sep 18, 2020 at 6:43 AM Aijun Wang wrote: > > Hi, Authors: > > I Just have a quick view of this draft, and has some points wanted to > be > clarified: > 1. This draft defines one new association type (policy association > type) that follows the procedures described in RFC8697 and attached > TLV? Is it right? > 2. According to the text described in > https://tools.ietf.org/html/rfc8697#section-3.2, to define one new > association type, the related draft should clarify its relationship > between the SVEC object, if any. > Should this draft to add such part? > 3. For the definition of "Policy-Parameters-TLV", the "Policy > Parameters" is opaque value to the PCEP peers. The draft describes > the PCEP peers should know how to the encoding format of such policy > in advance. But from my POV, the encoding format is the main content > needs to be standardized. If such contents can't be standardized, what > benefit can we get from this standardization work? What's the reason not to > standardize this? > > > Best Regards > > Aijun Wang > China Telecom > > > -Original Message- > From: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] On Behalf Of > Dhruv Dhody > Sent: Thursday, September 17, 2020 5:42 PM > To: pce@ietf.org > Cc: draft-ietf-pce-association-pol...@ietf.org; pce-chairs > > Subject: Re: [Pce] WGLC for draft-ietf-pce-association-policy > > Hi WG, > > A reminder to the WG to be more vocal. I am copying this slide from > the chair's WG status slide > [https://www.ietf.org/proceedings/108/slides/slides-108-pce-1-introduc > tion-0 > 1] > > > Please be Vocal > > > > o During WG Adoption and WG LC calls, the response is less. > > > > o Please be vocal on the list to help us gauge the consensus better. > > > > o The working group mailing lists are looked at by the IESG, IAB, > > and > others (internal and external to IETF) to determine > interest/participation level in our standards process. > > > > o Please review ideas from your peers, these are community outputs > > of the > working group as a whole. > > > > The WG LC for the draft in question ends on Monday 21st Sept. Please > respond with your explicit support (or not) for its publication. > > Thanks! > Dhruv & Julien > > > > On Fri, Sep 4, 2020 at 10:43 AM Dhruv Dhody wrote: > > > > 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,
Re: [Pce] WGLC for draft-ietf-pce-association-policy
Hi, Authors: I Just have a quick view of this draft, and has some points wanted to be clarified: 1. This draft defines one new association type (policy association type) that follows the procedures described in RFC8697 and attached TLV? Is it right? 2. According to the text described in https://tools.ietf.org/html/rfc8697#section-3.2, to define one new association type, the related draft should clarify its relationship between the SVEC object, if any. Should this draft to add such part? 3. For the definition of "Policy-Parameters-TLV", the "Policy Parameters" is opaque value to the PCEP peers. The draft describes the PCEP peers should know how to the encoding format of such policy in advance. But from my POV, the encoding format is the main content needs to be standardized. If such contents can't be standardized, what benefit can we get from this standardization work? What's the reason not to standardize this? Best Regards Aijun Wang China Telecom -Original Message- From: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] On Behalf Of Dhruv Dhody Sent: Thursday, September 17, 2020 5:42 PM To: pce@ietf.org Cc: draft-ietf-pce-association-pol...@ietf.org; pce-chairs Subject: Re: [Pce] WGLC for draft-ietf-pce-association-policy Hi WG, A reminder to the WG to be more vocal. I am copying this slide from the chair's WG status slide [https://www.ietf.org/proceedings/108/slides/slides-108-pce-1-introduction-0 1] > Please be Vocal > > o During WG Adoption and WG LC calls, the response is less. > > o Please be vocal on the list to help us gauge the consensus better. > > o The working group mailing lists are looked at by the IESG, IAB, and others (internal and external to IETF) to determine interest/participation level in our standards process. > > o Please review ideas from your peers, these are community outputs of the working group as a whole. > The WG LC for the draft in question ends on Monday 21st Sept. Please respond with your explicit support (or not) for its publication. Thanks! Dhruv & Julien On Fri, Sep 4, 2020 at 10:43 AM Dhruv Dhody wrote: > > 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
Re: [Pce] I-D Action: draft-ietf-pce-pcep-extension-native-ip-07.txt
Hi, All Experts: The main update contents for this draft are the followings: 1. Describes the procedures in general for TE in native IP network, its refer to the traditional LSP TE. 2. Redefines the contents of the three objects, and their signal interaction procedures between PCE and PCC. 3. Add the error type and error value for the related procedures. Detail discussions are undergoing offline continuously, wish also to hear the comments from PCE experts. Thanks in advance. Best Regards Aijun Wang China Telecom -Original Message- From: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] On Behalf Of internet-dra...@ietf.org Sent: Friday, September 11, 2020 11:56 AM To: i-d-annou...@ietf.org Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-pcep-extension-native-ip-07.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element WG of the IETF. Title : PCEP Extension for Native IP Network Authors : Aijun Wang Boris Khasanov Sheng Fang Ren Tan Chun Zhu Filename: draft-ietf-pce-pcep-extension-native-ip-07.txt Pages : 18 Date: 2020-09-10 Abstract: This document defines the Path Computation Element Communication Protocol (PCEP) extension for Central Control Dynamic Routing (CCDR) based application in Native IP network. The scenario and framework of CCDR in native IP is described in [RFC8735] and [I-D.ietf-teas-pce-native-ip]. This draft describes the key information that is transferred between Path Computation Element (PCE) and Path Computation Clients (PCC) to accomplish the End to End (E2E) traffic assurance in Native IP network under central control mode. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-pce-pcep-extension-native-ip-07 https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-native-i p-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pcep-extension-native-ip-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] PCE WG LC for draft-ietf-pce-pcep-extension-for-pce-controller
Hi, Shuping: Please see the responses inline, wish to see the update of the draft soon. Best Regards Aijun Wang China Telecom From: Pengshuping (Peng Shuping) [mailto:pengshup...@huawei.com] Sent: Friday, August 14, 2020 7:46 PM To: Aijun Wang ; julien.meu...@orange.com; pce@ietf.org Subject: RE: [Pce] PCE WG LC for draft-ietf-pce-pcep-extension-for-pce-controller Hi Aijun, Thank you for your comments! Please find the responses in line below. From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Aijun Wang Sent: Friday, August 14, 2020 5:42 PM To: julien.meu...@orange.com <mailto:julien.meu...@orange.com> ; pce@ietf.org <mailto:pce@ietf.org> Subject: Re: [Pce] PCE WG LC for draft-ietf-pce-pcep-extension-for-pce-controller Hi，Dhruv, Julien and authors of this draft: I reviewed this draft and had the following comments for its WG LC: 1. Generally speaking, I support the direction that stated also in the draft as "A PCE-based central controller (PCECC) can simplify the processing of a distributed control plane by blending it with elements of SDN and without necessarily completely replacing it." [Shuping] Thank you for your support. 2. This draft states it focuses on LSP Path central control, but I think the procedures described in this draft is common to other CCI object(which may be defined in other documents). So would it be better to generalize the procedures? The specific part for other path type may be only the CCI objects. This can facilitate the extension of PCECC procedure in other scenario. [Shuping] Yes, you are right. We can add some text in the introduction to make it clear that though this document focuses on the basic PCECC LSP mode for the static LSPs, the procedures defined are generic enough to be used by other PCECC extensions. [WAJ] Not only the introduction part, but also the following procedures. It is better to generalize the (section 5 <https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-for-pce -controller-06#section-5> ), not strictly limit within the LSP path. 3. Section-5.5.1of this draft <https://tools.ietf.org/html/draft-ietf-pce-pcep-extension-for-pce-controlle r-06#section-5.5.1> describes the “Basic PCECC LSP Setup”, which is based on the LSP delegation mode. But for LSP delegate mode, the LSP must exist beforehand, which is constructed via the distributed protocol(RSVP etc.). In such scenario, is it necessary to allocate the Label via the PCE? [Shuping] This is similar to the case for RFC 8664 where a PCC-initiated SR path is delegated to the PCE. It is not mandatory for the path (label-stack) to be "constructed" beforehand. [WAJ] For the PCC-initiated SR path, only the headend need to be touched. It is different from the scenario described in Figure 2. 4. I think the most useful scenario for PCECC should be based on “PCE Initiate” message, which is used to initiate one new path from the PCE, together with the label allocation. [Shuping] I agree. 5. Similar consideration is for the “PCC allocation label”. What the reason to let the PCC allocate such label? Why can’t PCE allocate such information for each PCC from its appointed label space? [Shuping] It was suggested to be added because in some cases PCC may not be able to allocate a part of its label space for PCE to control and it would want to control the full label-space allocation. [WAJ] In such situation, we think the distributed only label allocation is fine. The PCE should not intervene this process. Adding PCE in the network should simplify the procedures, not make it complex. 6. For definition of CCI object, will it simplify the overall procedures if the CCI object for MPLS label includes both the IN and OUT label together? [Shuping] At the ingress, we would only have out-label, and at the egress, we would only have an in-label. In case of P2MP branch nodes, we would have one in-label and many out-labels as described in another I-D. For these reasons, we decided to have them as separate CCI instances. [WAJ] Separate CCI instances requires the binding function on the devices. How to avoid the problem when the CCI instances can’t be bound together? For example, the PCE download two out label, no in label, or vice versa? Best Regards, Shuping Best Regards Aijun Wang China Telecom -Original Message- From: pce-boun...@ietf.org <mailto:pce-boun...@ietf.org> [mailto:pce-boun...@ietf.org] On Behalf Of julien.meu...@orange.com <mailto:julien.meu...@orange.com> Sent: Thursday, August 6, 2020 12:19 AM To: pce@ietf.org <mailto:pce@ietf.org> Subject: [Pce] PCE WG LC for draft-ietf-pce-pcep-extension-for-pce-controller Hi all, This message initiates a 3-week WG Last Call on draft-ietf-pce-pcep-extension-for-pce-controller-06. Please review and share your feedback,
Re: [Pce] PCE WG LC for draft-ietf-pce-pcep-extension-for-pce-controller
Hi，Dhruv, Julien and authors of this draft: I reviewed this draft and had the following comments for its WG LC: 1. Generally speaking, I support the direction that stated also in the draft as "A PCE-based central controller (PCECC) can simplify the processing of a distributed control plane by blending it with elements of SDN and without necessarily completely replacing it." 2. This draft states it focuses on LSP Path central control, but I think the procedures described in this draft is common to other CCI object(which may be defined in other documents). So would it be better to generalize the procedures? The specific part for other path type may be only the CCI objects. This can facilitate the extension of PCECC procedure in other scenario. 3. Section-5.5.1of this draft <https://tools.ietf.org/html/draft-ietf-pce-pcep-extension-for-pce-controlle r-06#section-5.5.1> describes the “Basic PCECC LSP Setup”, which is based on the LSP delegation mode. But for LSP delegate mode, the LSP must exist beforehand, which is constructed via the distributed protocol(RSVP etc.). In such scenario, is it necessary to allocate the Label via the PCE? 4. I think the most useful scenario for PCECC should be based on “PCE Initiate” message, which is used to initiate one new path from the PCE, together with the label allocation. 5. Similar consideration is for the “PCC allocation label”. What the reason to let the PCC allocate such label? Why can’t PCE allocate such information for each PCC from its appointed label space? 6. For definition of CCI object, will it simplify the overall procedures if the CCI object for MPLS label includes both the IN and OUT label together? Best Regards Aijun Wang China Telecom -Original Message- From: 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 <mailto:Pce@ietf.org> Pce@ietf.org <https://www.ietf.org/mailman/listinfo/pce> https://www.ietf.org/mailman/listinfo/pce ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] teas
Hi, Loa: Thanks for your review. We have updated the draft accordingly. Detail responses are inline below. I also includes the word responses for your reference. Best Regards Aijun Wang China Telecom -Original Message- From: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] On Behalf Of Loa Andersson Sent: Friday, August 7, 2020 2:28 PM To: rtg-...@ietf.org; "review: ddraft-ietf-teas-pce-native-.all"@ietf.org; TEAS WG Chairs ; TEAS WG ; pce@ietf.org; 'Yemin (Amy' ; LucAndré Burdet Subject: [Pce] teas RtgDir review: ddraft-ietf-teas-pce-native-ip-09 Hello, I have been selected as the Routing Directorate reviewer for this draft. 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> 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-teas-pce-native-ip-09 Reviewer: Loa Andersson Review Date: 2020-07-08 IETF LC End Date: date-if-known Intended Status: copy-from-I-D - Experimental (see issues list). Summary: I'm departing from the normal list, since if this would have been a standard tracks document there would have been serious issues. However, the document describes a TE experiment in a native IP network. I think is so interesting that I wouldn't object if the issues I point are not (fully) resolved. Actually I would very much like to see published and followed up by a document that reports the results from the experiment. I have the following issues with the document. It is a framework that gives the framework for an experiment. Its intended status is Experimental. While agree that the accompanying specification should be Experimental I think that in accordance with earlier document a framework should be Informational. [WAJ] Actually, this draft define the architecture for traffic engineering within Native IP network(CCDR). Should we change the phrase from “framework” to “architecture”, and keep the document in “Experimental” track? We have also discussed the possible status of this draft, at https://mailarchive.ietf.org/arch/msg/teas/YIMuXe1rM46aewPgfzMJrP-hPUA/ The document describes the experiment in some detail, I would like to see more, especially evaluation criteria and bench marking. To have an overview of the test bed would be interesting. [WAJ] We have some simulation results, as described in https://tools.ietf.org/html/rfc8735. Experiment in real filed will have similar results because the effect of such solution depends mainly on the performance of PCE. More data can be obtained after the PCEP extension draft(https://tools.ietf.org/html/draft-ietf-pce-pcep-extension-native-ip-05) been standardized. This is also the reason that we put this document in “Experimental” Status now. I would recommend that someone take a look at the document from a language point of view. When I read I find myself correcting and clarifying the English (this is probably not a good idea, since my English is probably worse than the current authors). There are loads of not expanded abbreviations, authors should go through the document and compare to: <https://www.rfc-editor.org/materials/abbrev.expansion.txt> https://www.rfc-editor.org/materials/abbrev.expansion.txt to decide what needs to be expanded or not. I would also want to suggest that someone with experience of "Native IP networks". both specification and operation should look at the document. >From the early days of MPLS I remember that one motivation to create a strong tunnel technology was that the Route Reflectors no longer scaled. [WAJ] The solution descried in this document does not decrease the scalability of RR. The forwarding plan will not pass RR. I normally review document based on a word document, I have included the word-file, and it contains about everything form major issues to nits. /Loa -- Loa Anderssonemail: <mailto:l...@pi.nu> l...@pi.nu Senior MPLS Expert <mailto:loa.pi...@gmail.com> loa.pi...@gmail.com Bronze Dragon Consulting phone: +46 739 81 21 64 draft-ietf-teas-pce-native-ip-09(waj).docx Description: MS-Word 2007 document ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] [Teas] teas
Hi, Loa: Thanks for your review. We will update the draft in next week to reflect your comments. The detail responses will also be provided later. Comments from other experts are also welcome. Thanks in advance. Best Regards Aijun Wang China Telecom -Original Message- From: teas-boun...@ietf.org [mailto:teas-boun...@ietf.org] On Behalf Of Loa Andersson Sent: Friday, August 7, 2020 2:28 PM To: rtg-...@ietf.org; "review: ddraft-ietf-teas-pce-native-.all"@ietf.org; TEAS WG Chairs ; TEAS WG ; pce@ietf.org; 'Yemin (Amy' ; LucAndré Burdet Subject: [Teas] teas RtgDir review: ddraft-ietf-teas-pce-native-ip-09 Hello, I have been selected as the Routing Directorate reviewer for this draft. 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-teas-pce-native-ip-09 Reviewer: Loa Andersson Review Date: 2020-07-08 IETF LC End Date: date-if-known Intended Status: copy-from-I-D - Experimental (see issues list). Summary: I'm departing from the normal list, since if this would have been a standard tracks document there would have been serious issues. However, the document describes a TE experiment in a native IP network. I think is so interesting that I wouldn't object if the issues I point are not (fully) resolved. Actually I would very much like to see published and followed up by a document that reports the results from the experiment. I have the following issues with the document. It is a framework that gives the framework for an experiment. Its intended status is Experimental. While agree that the accompanying specification should be Experimental I think that in accordance with earlier document a framework should be Informational. The document describes the experiment in some detail, I would like to see more, especially evaluation criteria and bench marking. To have an overview of the test bed would be interesting. I would recommend that someone take a look at the document from a language point of view. When I read I find myself correcting and clarifying the English (this is probably not a good idea, since my English is probably worse than the current authors). There are loads of not expanded abbreviations, authors should go through the document and compare to: https://www.rfc-editor.org/materials/abbrev.expansion.txt to decide what needs to be expanded or not. I would also want to suggest that someone with experience of "Native IP networks". both specification and operation should look at the document. >From the early days of MPLS I remember that one motivation to create a strong tunnel technology was that the Route Reflectors no longer scaled. I normally review document based on a word document, I have included the word-file, and it contains about everything form major issues to nits. /Loa -- Loa Anderssonemail: l...@pi.nu Senior MPLS Expert loa.pi...@gmail.com Bronze Dragon Consulting phone: +46 739 81 21 64 ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[Pce] 答复: WG adoption poll for draft-barth-pce-segment-routing-policy-cp-06
Hi, Dhruv: I support the adoption of this draft. One comment for the current document, would like to see the author give some explanations or add some clarifications for them: Will it be more accurate to change draft name to include some key words as "Policy Association"? For none association type of SR-MPLS Policy via PCEP, is RFC8664 sufficient? For none association type of SRv6 via PCEP, there is also another WG draft https://tools.ietf.org/html/draft-ietf-pce-segment-routing-ipv6-04 As mentioned in the document, although the color/endpoint is not included in the above documents, but these enhancements is not the main part of this draft? Best Regards Aijun Wang China Telecom > -邮件原件- > 发件人: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] 代表 Dhruv > Dhody > 发送时间: 2020年6月7日 15:45 > 收件人: pce@ietf.org > 主题: [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/0 6/ > > 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
[Pce] 答复: WG LC for draft-ietf-pce-stateful-pce-lsp-scheduling
Yes/Support. This draft gives operators the flexibility to schedules the LSP resource on demand. Best Regards. Aijun Wang -邮件原件- 发件人: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] 代表 julien.meu...@orange.com 发送时间: 2019年12月6日 0:47 收件人: pce@ietf.org 主题: [Pce] WG LC for draft-ietf-pce-stateful-pce-lsp-scheduling Dear PCE WG, This message starts a 2-week PCE WG Last Call for draft-ietf-pce-stateful-pce-lsp-scheduling-10. Please review the document and share your comments and/or interest using the PCE mailing list by Thursday December 19. Thanks, Dhruv & Julien ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[Pce] 答复: Adoption of draft-li-pce-sr-path-segment?
Yes/Support. Aijun Wang -邮件原件- 发件人: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] 代表 julien.meu...@orange.com 发送时间: 2019年9月26日 0:21 收件人: pce@ietf.org 主题: [Pce] Adoption of draft-li-pce-sr-path-segment? Hi PCE WG, In our adoption poll queue, draft-li-pce-sr-path-segment has been there for a little while, after it was discussed face to face. We would now like you to voice your opinion on the list: do you think this I-D can be the foundation for a PCE WG's work item? Please send your feedback to the PCE mailing list, including any comment you would like to share, especially if you think the WG should not adopt it. This poll will end on October 9. Thanks, Dhruv & Julien _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[Pce] 答复: WG adoption poll for draft-sivabalan-pce-binding-label-sid-07
Yes/Support. I think such mechanism is necessary for the interoperation of SR and RSVP-TE, and can overcome some shortcomings of SR technology. Aijun Wang. -邮件原件- 发件人: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] 代表 Dhruv Dhody 发送时间: 2019年8月21日 1:45 收件人: pce@ietf.org 抄送: pce-chairs 主题: [Pce] WG adoption poll for draft-sivabalan-pce-binding-label-sid-07 Hi WG, This email begins the WG adoption poll for draft-sivabalan-pce-binding-label-sid-07 [1]. 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. One of the chairs did a pre-adoption review [2] and authors posted a new revision. Note that there are known implementations. This adoption poll will end on 6th September 2019. Thanks! Dhruv (for the chairs) [1] https://tools.ietf.org/html/draft-sivabalan-pce-binding-label-sid-07 [2] https://mailarchive.ietf.org/arch/msg/pce/oaBIRA9FnNsV6-JrKKRCdwtLysk ___ 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] 答复: PCE WG Adoption poll for draft-leedhody-pce-vn-association
Hi, All: Support for the adoption. One suggestion is the following: As described in section 3.2 <https://tools.ietf.org/html/draft-ietf-pce-association-group-10#section-3.2 > of [draft ietf-pce-association-group]: “PCEP extensions that define a new association type should clarify the relationship between the SVEC object and the association type, if any.” As the VN creation request if from the customer, can the “Requestion-ID-number” be used to association these PCE initiated associated LSPs? Add some text to clarify this may be more helpful. Best Regards. Aijun Wang China Telecom -邮件原件- 发件人: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] 代表 Adrian Farrel 发送时间: 2019年8月14日 23:51 收件人: pce@ietf.org 抄送: draft-leedhody-pce-vn-associat...@ietf.org 主题: Re: [Pce] PCE WG Adoption poll for draft-leedhody-pce-vn-association Hi PCE WG, The adoption poll for this draft was not overwhelming. Possibly this was because of the overlap with IETF-105 when you were all busy. Thanks to everyone who did respond to the poll. If there are any more of you out there who think the WG should adopt this work please speak up. Especially happy to hear form those who have read the draft, and those who plan to help with reviews and implementations. Thanks, Adrian (still trying to step down!) -Original Message- From: Pce < <mailto:pce-boun...@ietf.org> pce-boun...@ietf.org> On Behalf Of Adrian Farrel Sent: 14 July 2019 14:00 To: <mailto:pce@ietf.org> pce@ietf.org Cc: <mailto:draft-leedhody-pce-vn-associat...@ietf.org> draft-leedhody-pce-vn-associat...@ietf.org Subject: [Pce] PCE WG Adoption poll for draft-leedhody-pce-vn-association Hi WG, He authors of draft-leedhody-pce-vn-association have been asking for adoption and... - the base PCEP association extensions seem to be stable and advancing - I did an early review and the authors span a new version So, this starts an adoption poll for the draft. Because IETF-105 is imminent and you all have lots to do and read, we'll make this a three week poll ending on 4th August. Please send your comments of support or antipathy. In either case, please indicate whether or not you have read the draft, and if you support it, please say whether or not you propose to and even possibly implement the draft. Many thanks, Adrian (for the chairs) ___ Pce mailing list <mailto:Pce@ietf.org> Pce@ietf.org <https://www.ietf.org/mailman/listinfo/pce> https://www.ietf.org/mailman/listinfo/pce ___ Pce mailing list <mailto:Pce@ietf.org> Pce@ietf.org <https://www.ietf.org/mailman/listinfo/pce> https://www.ietf.org/mailman/listinfo/pce ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WG Adoption Call for draft-negi-pce-segment-routing-ipv6
Yes/Support. This draft give controller the capabilities to design the SRv6 Path via PCEP protocol. Aijun Wang China Telecom > On Feb 22, 2019, at 22:51, Andrew G. Malis wrote: > > Yes/support. This is a very important companion draft to > draft-ietf-pce-segment-routing. > > Cheers, > Andy > > >> On Fri, Feb 22, 2019 at 1:47 AM Dhruv Dhody wrote: >> 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 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? Do you plan to implement it? >> >> This poll will run until 8th March. >> >> Thanks, >> PCE Chairs >> >> [1] >> https://datatracker.ietf.org/doc/draft-negi-pce-segment-routing-ipv6/?include_text=1 >> >> ___ >> 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 mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[Pce] 答复: I-D Action: draft-ietf-pce-pcep-extension-native-ip-02.txt
Hi, all: The main update contents is that we aligned the associated extensions with the CCI object that introduced in https://tools.ietf.org/html/draft-ietf-pce-pcep-extension-for-pce-controller -00. A new CCI object type is defined and the original PCEP Objects extension in previous version are moved to the TLVs definition, which are associated with the newly extend CCI Object. Such processing may simplify and unify the procedures for controller based instructions. Thanks for Dhruv Dhody for the offline discussion. More feedback are welcome, especially from the persons that has PCInitiate Message implementation experiences. Best Regards. Aijun Wang Network R and Operation Support Department China Telecom Corporation Limited Beijing Research Institute,Beijing, China. -邮件原件- 发件人: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 发送时间: 2018年11月16日 15:59 收件人: i-d-annou...@ietf.org 抄送: pce@ietf.org 主题: [Pce] I-D Action: draft-ietf-pce-pcep-extension-native-ip-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element WG of the IETF. Title : PCEP Extension for Native IP Network Authors : Aijun Wang Boris Khasanov Sudhir Cheruathur Chun Zhu Sheng Fang Filename: draft-ietf-pce-pcep-extension-native-ip-02.txt Pages : 9 Date: 2018-11-15 Abstract: This document defines the PCEP extension for CCDR application in Native IP network. The scenario and architecture of CCDR in native IP is described in [I-D.ietf-teas-native-ip-scenarios] and [I-D.ietf-teas-pce-native-ip]. This draft describes the key information that is transferred between PCE and PCC to accomplish the end2end traffic assurance in Native IP network under central control mode. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-pce-pcep-extension-native-ip-02 https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-native-i p-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pcep-extension-native-ip-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ 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] 答复: WG adoption poll for draft-zhao-pce-pcep-extension-for-pce-controller-08
Hi, All: Yes/Support. One comments is that the author can also consider using the PCECC mechanism to edit dynamically the LSP path that formed by the traditional LSP path setup protocol. Such coordination can leverage the advantages of the central and distributed control protocol. Best Regards. Aijun Wang Network R and Operation Support Department China Telecom Corporation Limited Beijing Research Institute,Beijing, China. 发件人: Jonathan Hardwick [mailto:Jonathan.Hardwick=40metaswitch@dmarc.ietf.org] 发送时间: 2018年10月13日 22:47 收件人: pce@ietf.org 抄送: draft-zhao-pce-pcep-extension-for-pce-control...@ietf.org; pce-cha...@ietf.org 主题: [Pce] WG adoption poll for draft-zhao-pce-pcep-extension-for-pce-controller-08 This is the start of a two week poll on making draft-zhao-pce-pcep-extension-for-pce-controller-08 a PCE working group document. https://datatracker.ietf.org/doc/draft-zhao-pce-pcep-extension-for-pce-contr oller/ Please review the draft and send an email to the list indicating “yes/support” or “no/do not support”. If indicating no, please state your reasons. If yes, please also feel free to provide comments you'd like to see addressed once the document is a WG document. The poll ends on Friday, October 26. Many thanks, Jon and Julien ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[Pce] 答复: WG adoption poll for draft-li-pce-pcep-flowspec-03
Yes/Support 发件人: Jonathan Hardwick [mailto:jonathan.hardw...@metaswitch.com] 发送时间: 2018年2月20日 21:34 收件人: pce@ietf.org 抄送: draft-li-pce-pcep-flows...@ietf.org; pce-cha...@ietf.org 主题: [Pce] WG adoption poll for draft-li-pce-pcep-flowspec-03 Dear PCE WG This is the start of a two week poll on making draft-li-pce-pcep-flowspec-03 a PCE working group document. https://datatracker.ietf.org/doc/draft-li-pce-pcep-flowspec/ Please review the draft and send an email to the list indicating “yes/support” or “no/do not support”. If indicating no, please state your reasons. If yes, please also feel free to provide comments you'd like to see addressed once the document is a WG document. The poll ends on Tuesday, March 6. Many thanks, Jon and Julien ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[Pce] 答复: PCEP as an SDN controller protocol?
I agree with Jeff. The communication between distributed device2device is different from device2controller. The latter should be complementary of the former, not replace them. We operator just want to use such SBI protocol to enhance the coordination among the underlying devices, especially for the end-to-end optimal path programming. If the PCEP protocol can be extended to transfer some key parameters, we can easily deploy one unified solution to cover several different scenario, regardless they are in MPLS, Native IPv4, or IPv6 network. This can certainly relieve our burden to cope with the different solutions for different scenarios. We have also make the scenario/requirements presentation at Prague, If you are interesting, please refer the material at CCDR Presentation Material <https://www.ietf.org/proceedings/99/slides/slides-99-teas-sessa-13-ccdr-centrally-control-dynamic-routing-scenario-simulation-and-suggestion-01.pdf> . We have also compared the different approach protocols to fulfill them, and think PCEP may be the most candidate protocol to accomplish them. Best Regards. Aijun Wang Network R and Operation Support Department China Telecom Corporation Limited Beijing Research Institute,Beijing, China. 发件人: Pce [mailto:pce-boun...@ietf.org] 代表 Jeff Tantsura 发送时间: 2017年7月25日 6:12 收件人: Igor Bryskin; stephane.litkow...@orange.com; Jonathan Hardwick; pce@ietf.org 抄送: pce-cha...@ietf.org 主题: Re: [Pce] PCEP as an SDN controller protocol? We all know – every protocol has its strong and less strong sides, however the properties required for a distributed device2device communication are quite different from device2controller environment and should be evaluated as such. There’s a long list of pros and cons for either environments (objective functions) as well operational preferences, domain knowledge, and such Most of us here are biased ☺ To put it short – I believe there’s enough people who are interested in working on PCEP to extend it, personally I see value in having PCEP next to any other SBI’s mentioned below, however what I don’t want, is to overload semantics of PCEP (aka BGP kitchen sink ☺). Cheers, Jeff From: Pce <pce-boun...@ietf.org> on behalf of Igor Bryskin <igor.brys...@huawei.com> Date: Monday, July 24, 2017 at 14:52 To: "stephane.litkow...@orange.com" <stephane.litkow...@orange.com>, Jonathan Hardwick <jonathan.hardw...@metaswitch.com>, "pce@ietf.org" <pce@ietf.org> Cc: "pce-cha...@ietf.org" <pce-cha...@ietf.org> Subject: Re: [Pce] PCEP as an SDN controller protocol? Hi Stephanie, You said: < Why not limiting PCEP to path programming and path policies (traffic steering on path…) ? But why not to use for these purposes RESTCONF or gRPC/protobuffs? Do you see value in using explicit model based SBIs vs implicit (TLV-) based protocols such as PCE? Cheers,, Igor From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of stephane.litkow...@orange.com Sent: Monday, July 24, 2017 8:03 AM To: Jonathan Hardwick; pce@ietf.org Cc: pce-cha...@ietf.org Subject: Re: [Pce] PCEP as an SDN controller protocol? Hi, As soon as we started with the active stateful PCE, the PCE became an SDN controller who takes decision and programs the network. So as many already mentioned, PCEP as an SBI is already done. IMO, PCECC does not change significantly PCEP, it’s just bring a new kind of LSP style for this hop by hop path programming. A controller implementing hop by hop path programming will require more intelligence as it needs to program nodes in the right order to prevent transient loops… The question is more what is the exact scope of PCEP in term of SBI and do we want to create a protocol that does everything , including coffee J ? We already have plenty of protocols: BGP, IGP, Netconf. Each protocol has strength and weaknesses and I’m not sure that we need to mimic all features in all protocols. What is the gain here ? The best approach may be to use strength of protocols and use them for what they are good for: Example: IGP has good flooding capability with “limited scale”: interesting when all receivers need the same information BGP has good flooding capability with large scale and ability to target specific groups (using route targets/communities) : interesting when groups of receivers need the same information Netconf more generic and point to point … IMO: do we need PCEP-LS ? => This can be discussed, we already have two protocols to exchange the topology… do we need to add configuration capabilities in PCEP => not sure, we have Netconf for that. Why not limiting PCEP to path programming and path policies (traffic steering on path…) ? Brgds, From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Jonathan Hardwick Sent: Thursday, July 20, 2017 17:22 To: pce@ietf.org Cc: pce-c
[Pce] PCEP extension for TE solution in Native IP network
Hi, experts in PCE wg: Here we submitted one draft that describes the PCEP extension for TE solution in Native IP network, wish to hear your valuable comments on this topic. https://tools.ietf.org/html/draft-wang-pce-extension-native-ip-00 The companion draft that describes the overall solution is at https://tools.ietf.org/html/draft-wang-teas-pce-native-ip-01, and the initial introduction slides can be accessed at https://www.ietf.org/proceedings/96/slides/slides-96-teas-10.pdf Best Regards. Aijun Wang China Telecom Beijing Research Institute Network R and Operation Support Department ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
