Sounds good, thanks Haomian. Daniele
On Fri, May 30, 2025 at 5:24 AM Zhenghaomian <zhenghaom...@huawei.com> wrote: > Hi Daniele, > > Thank you for the valuable comments, we have updated the document to -12 > and addressed the following comments. > > For the general question on hierarchical PCEs, we believe the point is > valid – from this document we prefer to clarify that we don’t have the > opinion ‘peer sync is better than hierarchy’ but we only ‘keep this doc > focusing on the peer sync scenario’. The text is updated accordingly, > please check if there is further concerns. > > Best wishes, > Haomian > > -----邮件原件----- > 发件人: Daniele Ceccarelli via Datatracker <nore...@ietf.org> > 发送时间: 2025年2月3日 17:08 > 收件人: ops-...@ietf.org > 抄送: draft-ietf-pce-state-sync....@ietf.org; pce@ietf.org > 主题: Opsdir early review of draft-ietf-pce-state-sync-11 > > Reviewer: Daniele Ceccarelli > Review result: Has Nits > > Hello, > > please find below my OPS-DIR review. > The draft is well written and easy to read but would benefit from the > explanation of some decisions taken in the design and statements provided > without a justification. I really like the extensive usage of examples, > which clearly explain situations that might be hard to be understood using > the text only. > > The synchronization among multiple stateful PCEs and avoidance of > computation loops is for sure a valid use case but i was wondering why the > hierarchical PCE approach is not taken into account (it's also explicitly > said in the document). > Wouldn't it be easier to have a hierarchical PCE coordinating the various > PCEs instead of having them talking to each others? I guess the authors > have done this analysis already and providing a comparison between the two > approaches in the draft would be beneficial. > > Some more comments related to specific parts of the text below: > > - Abstract: For completeness, a stateful PCE can be used also for GMPLS, > not only for MPLS-TE. - Intro: "he hierarchical PCE use case is out of the > scope of this document." see my general comment above. - Intro, figure 1: > "when there is a change in LSP1, the PCC should report to PCE1. From > PCE2's perspective, PCC1 reporting the update of LSP1 to PCE2 is lower than > sync it from PCE1 to PCE2." > This statement should be justified. Why the communication PCC1-PCE2 should > be slower than PCE1-PCE2 ? - Section 3.1 only includes 3.1.1 and no extra > text, probably you don't need 3.1.1 and just 3.1 is fine. - Section 3.3: " > When propagating LSP state changes from a PCE to other PCEs, it MUST ensure > that a PCE always uses the freshest state coming from the PCC." i'm not > sure i understand who the subject is, and how it can ensure that the > freshest state is used. - Figure 6: Lenght isn't 16? How long is the LSP > state DB version number? > 64 bit? do you expect that many version number updates during the lifetime > of an LSP? - Section 3.5: You say taht PCC doesn't need to be aware of teh > computation priority. Then who tells the PCE what is the priority of each > association group? - Section 6: The need of a Path-Vector TLV makes me > think that the hierarchical approach would be simpler. With the > hierarchical approach you wouldn't need a message loop detection mechanisms. > > Thanks > Daniele > > > >
_______________________________________________ Pce mailing list -- pce@ietf.org To unsubscribe send an email to pce-le...@ietf.org
