On July 13, 2020 at 3:29:13 PM, Huaimo Chen wrote:
Huaimo: Hi! ... > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > I think that this document still needs work before publication. I consider > the first 3 points below to be close to DISCUSS-worthy. > > (1) In general, it feels like an editorial pass is needed to tighten up the > language used as specification in this document. There are several places > where the language feels loose -- as an example (from §4.4): ... > [HC]: We have updated the document according to rfc2119 as you suggested. Thanks for addressing this one instance. As I mentioned, there are other similar instances that would benefit from similar tightening up -- please reread through the document with an eye for "loose language". I trust that you will do the right thing. > (2) §4.1: "a PCE MUST synchronize to other PCEs within the network...Which > way is used to achieve this is out of scope for this document." If the > synchronization mechanism is out of scope, how can an implementation be > compliant with this specification? IOW, if there's nothing to normatively > refer to, then normative language shouldn't be used, or a mechanism should > be mandated. In either case, because synchronization between the PCEs seems > important for this specification, I would like to also see a discussion > about the specific effects on LSP scheduling instead of the generic pointer > to rfc7399. > > [HC]: The description related seems too broad. We have rephrased > the related text to focus on the state of a scheduled LSP > crossing multiple domains from an ingress domain to an egress domain. ... As mentioned separately...I think that changing the scenario is not a good idea at this point. It also leaves the single domain case unaddressed. > §4.3 says that the "stateful PCE...shall send a PCRpt message with the > scheduled LSP to other PCEs...to achieve...synchronization." Even though > normative language is not used, the intent seems to specifically point at > using PCRpt messages for synchronization... > > Besides the confusing use of language, rfc8231 defines PCRpt as a "message > sent by a PCC to a PCE to report the current state of an LSP", but I didn't > see where the use if defined between PCEs -- maybe I missed it. §6.1 does > reinforce that the "Path Computation State Report (PCRpt) is a PCEP message > sent by a PCC to a PCE to report the status of one or more LSPs as per > [RFC8231]....This message is also used to synchronize the scheduled LSPs to > other PCE as described in [RFC8231]". But this last point is what I can't > find in rfc8231. > > [HC]: We have updated/cleaned the text related. > The Path Computation State Report (PCRpt) is a PCEP message sent by > a PCC to a PCE as per [RFC8231]. A PCE can act as a PCC to send a PCRpt > message to another PCE. The "as described in [RFC8231]" text is still not accurate -- that document doesn't talk about using the PCRpt message between PCEs. I don't think that the "PCE can act as a PCC" part is well defined. Is it specified somewhere else? > (3) This whole document is about scheduling LSPs, which would seem to require > time synchronization. However, I found only one mention: "It is necessary to > synchronize the clocks of the PCEs and PCCs when relative time is used." > Should this sentence use normative language? Is there a recommended way to > achieve time synchronization? This seems to be an important manageability > consideration that impacts network operations. > > [HC]: Yes. We have changed it to use normative language, and > recommended Network Time Protocol [RFC5905] for time synchronization. The reference should be Normative. Thanks! Alvaro. _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
