Hi Alvaro,
Thank you very much for your valuable comments.
My answers/explanations are inline below with prefix [HC2].
Best Regards,
Huaimo
________________________________
From: Alvaro Retana <[email protected]>
Sent: Tuesday, July 21, 2020 11:35 AM
To: Alvaro Retana via Datatracker <[email protected]>; The IESG <[email protected]>
Cc: [email protected] <[email protected]>;
[email protected]
<[email protected]>; [email protected]
<[email protected]>
Subject: Re: [Pce] Alvaro Retana's No Objection on
draft-ietf-pce-stateful-pce-lsp-scheduling-19: (with COMMENT)
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.
[HC2]: We will reread through the document carefully for "loose language" and
update it accordingly.
> (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.
[HC2]: We will update the text according to Dhruv's suggestion.
> §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?
[HC2]: RFC 8751 has a child PCE acting as PCC and
sending PCRpt messages to its parent PCE.
> (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.
[HC2]: We will move it to Normative References
Thanks!
Alvaro.
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
