Re: [Pce] Alvaro Retana's No Objection on draft-ietf-pce-stateful-pce-lsp-scheduling-19: (with COMMENT)

[Alvaro Retana <[e-mail]>]

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.