Hi Cheng, Authors, Thanks for this document. It's fairly well written and I found many of the questions/thoughts I had were being answered as I kept reading. Below are some comments/feedback/questions. Thanks in advance!
- It’s likely worth defining the term computation loop as a reader may think it's simply PCEs spending time computing paths (or may think it’s routing loops), but really it’s message control+computation+path oscillation loops. Perhaps a simple sentence such as “The term computation loop used in this document describes a behavior of protocol message exchange looping between PCC and PCE, resulting in frequent path calculations and path updates to the network resulting in constant load on PCE and oscillation of data plane traffic after each subsequent update. “ - section 1.3 - RFC9059 is another good example use case that might be worth examine the behavior of since diversity covered the various conditions in great depth. However, I think the result might be be very similar though so it might be worth working through the same example flow (I have not yet..) - section 1.3 - nice to see scenario 5 was covered as that was a concern I had as I started reading. "both LSPs are configured almost at the same time" -> another example condition for that could be link diverse paths with a common node failure detected by each PCE and each PCE naturally independently reroute and result on the same link. - section 2 intro it might be worth remarking in a statement that various aspects of RFC8232 are required/used to implement this solution beyond RFC8231. For example, LSP-DB-VERSION support is critical, but is only RFC referenced at the very end of 3.3 after the its purpose is discussed. May make for an easier/more obvious read. - section 3.2 - 'SPEAKER-IDENTITY-TLV' term itself is not defined in RFC8232, but rather 'Speaker entity identifier TLV' or rather 'SPEAKER-ENTITY-ID' - should be changed? - section 3.4 "a PCE SHOULD update the LSP state only if the ORIGINAL-LSP-DB-VERSION present in the PCRpt is greater than the current ORIGINAL-LSP-DB-VERSION of the stored LSP state" - this text seems quite strict considering the value may wrap around. As well, RFC8232 doesn't seem to indicate LSP-DB-VERSION needs to be persisted for lifetime. What happens if PCC reboots and resets back to 1 on next connection? PCE may have kept the LSP state as stale during sync and thus no delete actually occurred on PCE1. If PCE1 then tries to update PCE2 with this, what should happen? Not clear to me from the text how it would be handled. - is PCC open message exchange, carried and sent between PCE and PCE defined somewhere in this or other documents? appreciate if you could point me to It as I could not find and it’s not clear to me from reading. The reason I ask is there may be data in the open used during computation. As a top of head example, RFC8664 carries MSD in the open message (yes, and in a metric object). If an implementation doesn't carry MSD in the metric object, it could rely on the open message, or may need to rely on the open message, for extra information to do PCE-init. Can PCE1 forward PCC Open information info to PCE2? Similarly information such as capabilities for PCE-INIT would also need to be known to help during computation. So if a PCC is currently not connected to PCE2, should it be relying on its once-known-in-the-past PCC information or can it use the live information it can learn from PCE1? - section 3.5 - Want to confirm understanding…. Let's say PCE1, PCE2 and PCE3 are deployed. PCC is connected to PCE1. PCE2 is highest priority. PCC delegates to PCE1, which then sub-delegates to PCE2. PCE3 learns undelegated. When PCE2 wants to send a PcUpdate, the text says "it MUST send a PCUpdate message to all state-sync sessions and to the PCC session on which it received the delegation". Therefore PCE2 MUST send the PcUpdate to PCE1 and PCE3. Emphasis here is PCE3. In normal operation PCE3 should ignore. What's the reason to send to PCE3? Is it to handle possible inconsistent/out of date synchronization of the delegation ownership? - section 3.5 paragraph 3 - might be worth adding: "LSPs part of the same association group SHOULD be assigned with the same PCE priority". The last paragraph in this section touches on it in an inverse way but it's likely worth indicating this directly. - section 3.5 last paragraph, perhaps should be a section on it's own (3.5.1 ?) since it's a specific sub behavior of computation priority of a certain type of LSPs rather than the general flow and concept of computation priority? - General question – any thought given to bandwidth optimization? Is a PCE with capabilities to perform bandwidth optimization out of scope? For example, under a split brain scenario, both PCE's may detect congestion a link. Both PCEs may attempt to move paths around to deal with this, further creating congestion elsewhere. This could oscillate/computation loop. Should this type of scenario be explicitly listed as out of scope? - nice diagrams and re-capture in section 4.3. Perhaps further title details? Such as: "Example 1 - Successful disjoint paths (requiring reroute)". "Example 2 - Successful disjoint paths (simultaneous turnup)". "Example 3 - Unfeasible disjoint paths (insufficient state-sync sessions)" - For PCEP-PATH-VECTOR, while it indicates it's for future use and I can see value for debugging by having it now, should it at least define some basic behavior now for loop detection? For example, if a PCE detects itself in the PCEP-PATH-VECTOR in a PcRpt should it ignore the PcRpt? or close the PCEP session? or ___? On 2024-01-02, 10:27 AM, "Pce on behalf of Cheng Li" <pce-boun...@ietf.org <mailto:pce-boun...@ietf.org> on behalf of c.l=40huawei....@dmarc.ietf.org <mailto:40huawei....@dmarc.ietf.org>> wrote: Hi PCE WG, This update mainly includes: * editorial modifications of some text, and references. * changed some 'SHOULD' to 'MUST' according to the context, e.g. the PCE with highest priority MUST be response instead of SHOULD be response. * added more detailed text in manageability considerations sub-section. Comments are welcome. IMHO, this draft may be ready for WGLC already 😊 Thanks, Cheng -----Original Message----- From: Pce <pce-boun...@ietf.org <mailto:pce-boun...@ietf.org>> On Behalf Of internet-dra...@ietf.org <mailto:internet-dra...@ietf.org> Sent: Tuesday, January 2, 2024 4:17 PM To: i-d-annou...@ietf.org <mailto:i-d-annou...@ietf.org> Cc: pce@ietf.org <mailto:pce@ietf.org> Subject: [Pce] I-D Action: draft-ietf-pce-state-sync-06.txt Internet-Draft draft-ietf-pce-state-sync-06.txt is now available. It is a work item of the Path Computation Element (PCE) WG of the IETF. Title: Inter Stateful Path Computation Element (PCE) Communication Procedures. Authors: Stephane Litkowski Siva Sivabalan Cheng Li Haomian Zheng Name: draft-ietf-pce-state-sync-06.txt Pages: 35 Dates: 2024-01-02 Abstract: The Path Computation Element (PCE) Communication Protocol (PCEP) provides mechanisms for PCEs to perform path computation in response to a Path Computation Client (PCC) request. The Stateful PCE extensions allow stateful control of Multi-Protocol Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) using PCEP. A Path Computation Client (PCC) can synchronize an LSP state information to a Stateful Path Computation Element (PCE). A PCC can have multiple PCEP sessions towards multiple PCEs. There are some use cases, where an inter-PCE stateful communication can bring additional resiliency in the design, for instance when some PCC-PCE session fails. This document describes the procedures to allow a stateful communication between PCEs for various use-cases and also the procedures to prevent computations loops. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-state-sync/ <https://datatracker.ietf.org/doc/draft-ietf-pce-state-sync/> There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-pce-state-sync-06.html <https://www.ietf.org/archive/id/draft-ietf-pce-state-sync-06.html> A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-state-sync-06 <https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-state-sync-06> 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 <https://www.ietf.org/mailman/listinfo/pce> _______________________________________________ Pce mailing list Pce@ietf.org <mailto: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
