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

From: Alvaro Retana via Datatracker <[email-masked]>
Date: Tue, 07 Jul 2020 11:38:12 -0700

Alvaro Retana has entered the following ballot position for
draft-ietf-pce-stateful-pce-lsp-scheduling-19: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-lsp-scheduling/

----------------------------------------------------------------------
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):

   In PCC-Initiated case, the PCC can send a PCRpt message for the
   scheduled LSP with updated parameters as well as scheduled
   information included in the SCHED-LSP-ATTRIBUTE TLV (see
   Section 5.2.1) or SCHED-PD-LSP-ATTRIBUTE TLV (see Section 5.2.2)
   carried in the LSP Object.  The PCE would take the updated resources
   and schedule into considerations and update the new path for the
   scheduled LSP to the PCC as well as synchronize to other PCEs in the
   network.  In case path cannot be set based on new requirements, the
   previous LSP will not be impacted and the same should be conveyed by
   the use of empty ERO in the PCEP messages.

"the PCC can send"  Does it have to?  If the information is not sent, then the
PCE will not be able to calculate the path, so something stronger than "can"
seems to be needed.

"PCE would take"  Does this mean that it is optional?  I can imagine how the
PCE may have local policies affecting the action...but I shouldn't have to
imagine anything.

"should be conveyed"  Again, do you have to?  Are there cases when it is ok not
to do it?

Not everything needs rfc2119 key words, but in some cases they would help.  In
this case, I can see a couple of variations possible.

rfc2119>
   ...the PCC MUST send...the PCE SHOULD take...MUST be conveyed...

non-rfc2119>
   ...the PCC sends...the PCE takes...is conveyed...

(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.

§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.

(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.

(4) rfc8413 should be a Normative reference because it "provides a framework
that describes and discusses the problem, and defines an appropriate
architecture for the scheduled reservation of TE resources", which is the basis
for the extensions defined in this document.

(5) §2.1: Some of the terminology terms have 2 references -- that caught my
attention.  For example, the definition of TED points at both rfc5440 and
rfc8231.  rfc5440 has a definition, but rfc8231 points at rfc4655.  Luckily,
the definitions in rfc5440 and rfc4655 are the same...but the added indirection
through rfc8231 is unnecessary.  Please revalidate the references and include
only one.

(6) §2.1: "Duration:  This value indicates the time duration..."   Please don't
use "duration" to define "duration".  Maybe s/time duration/length of time

(7) §4.1: "A PCC MUST delegate a scheduled LSP with information of its
scheduling parameters, including the starting time and the duration using PCRpt
message."  This sentence seems to refer to the use of the new TLVs defined
later in the test.  Please include a forward reference to make it easier for
the reader to figure out how this action would be done.

(8) §4.3: "The PCE SHOULD add the scheduled LSP into its scheduled LSP-DB and
update its scheduled TED."  When is it ok for the PCE not to add this
information?  IOW, why is MUST not used?  If the information is not added, what
is the effect on the required synchronization?

Later in this section: "The stateful PCE is required to update its local
scheduled LSP-DB and scheduled TED with the scheduled LSP."  Even though
normative language is not used here, the intent of requiring an update to the
databases seems different than above and results in confusion.

(9) §4.3: "the PCC knows that it is a scheduled path"  How?  I'm sure that it
is through the contents of the messages.  Please be specific.

(10) §5.1: "After a PCEP session has been established, a PCC and a PCE
indicates its ability to support LSP scheduling during the PCEP session
establishment phase."  Is it after or during?

(11) §5.1: "...the STATEFUL-PCE-CAPABILITY TLV defined in [RFC8231].  Note that
the STATEFUL-PCE-CAPABILITY TLV is defined in [RFC8231]..."  Redundant.

(12) §5.1: "we define a new flag bit B (SCHED-LSP-CAPABLITY) flag...B
(LSP-SCHEDULING-CAPABILITY..."  The names don't match.

(13) §5.1: "Setting PD bit requires setting B bit as specified in 5.2.2."  That
is not specified in §5.2.2.  However, it brings up the question about the
interpretation of only receiving the PD bit set -- I'm assuming that it should
be ignored unless the B but is also set, right?  If so, please specify it!

(14) §5.2: "this LSP is requesting scheduled parameters"  The request is by the
PCC, not the LSP...

(15) §5.2: "scheduled LSP attribute TLV"  Even though it may be obvious, the
SCHED-LSP-ATTRIBUTE TLV is not called "scheduled LSP attribute TLV" anywhere in
the document.

(16) §5.2: "For periodical LSPs, the SCHED-PD-LSP-ATTRIBUTE TLV can be used in
LSP Object for each periodic scheduled LSP carried in the PCEP messages." 
Don't you *have* to use it?  Otherwise, how would the periodic nature be known?

(17) §5.2: "Only one of these TLV SHOULD be present in the LSP object.  In case
more than one scheduling TLV is found, the first instance is processed and
others ignored."  This section talks about both the SCHED-LSP-ATTRIBUTE and the
SCHED-PD-LSP-ATTRIBUTE TLVs -- the sentence sounds as if only one of them
(either one) should be present.  Please rephrase -- it may be better to define
this behavior for each TLV independently (in §5.2.*).

(18) §5.2.1: "This TLV MUST NOT be included unless both PCEP peers have set the
B..."  What should the receiver do if the TLV is received when both peers
didn't set the B bit?

(19) §5.2.1: "Just before the wraparound, if the time at which the LSP is to be
activated is after the wraparound..."   I don't know how that is possible.

(20) §5.2.1: "...non-zero grace period or elastic range, but it MUST NOT
provide both for an LSP."  What should a receiver do if both sets are non-zero?

(21) §5.2.2: "This TLV MUST NOT be included unless both PCEP peers have set the
B...and PD..."  What should the receiver do if the TLV is received but both
bits were not set?

(22) §5.2.2: "A new registry "Opt" under SCHED-PD-LSP-ATTRIBUTE is created." 
The registry is not part of the definition of the field...this sentence is not
needed here.

(23) §5.2.2: "Opt value not defined"   I think you may mean an unknown value
(or maybe unsupported).

(24) Nits:

s/following terminologies are re-used/following terminology is re-used

s/computes a path/compute a path/g

s/by PCE itself/by a|the PCE itself

s/setup of LSP/setup of an LSP

s/ask PCC/ask the PCC

s/In PCC-Initiated case/In the PCC-Initiated case/g

s/In PCE-Initiated case/In the PCE-Initiated case/g

s/establish PCEP session/establish a PCEP session

s/Setting PD bit requires setting B bit/Setting the PD bit requires setting the
B bit

s/presence of SCHED-LSP-ATTRIBUTE/presence of the SCHED-LSP-ATTRIBUTE

s/in LSP Object/in the LSP Object/g

s/one of these TLV/one of these TLVs

s/B (LSP-SCHEDULING-CAPABILITY bit)/B (LSP-SCHEDULING-CAPABILITY) bit/g

s/Following flags/The following flags

s/remains same as/remain the same as in the

s/Options =/Opt =

s/In each of repeats, /During each repetition

§6.1: s/described in [RFC8231]/described in [RFC8231].

---

From: Huaimo Chen <[email-masked]>
Date: Mon, 13 Jul 2020 19:29:09 +0000

Hi Alvaro,

    Thank you very much for your valuable comments, which improve the quality of the document.
    My explanations/answers are inline below with prefix [HC].
    The comments have been addressed in version 22 of the document uploaded

Best Regards,
Huaimo

________________________________
From: Alvaro Retana via Datatracker <[email-masked]>
Sent: Tuesday, July 7, 2020 2:38 PM
To: The IESG <[email-masked]>
Cc: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; Adrian Farrel <[email-masked]>
Subject: Alvaro Retana's No Objection on draft-ietf-pce-stateful-pce-lsp-scheduling-19: (with COMMENT)

Please refer to https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html&amp;data=02%7C01%7Chuaimo.chen%40futurewei.com%7C434b7ffeba034a05e78408d822a4f7d2%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637297439231224552&amp;sdata=mCwVobys5l1PWRY5kMWJpEpJkiMERoWN3gEgdh0eNg8%3D&amp;reserved=0
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-pce-stateful-pce-lsp-scheduling%2F&amp;data=02%7C01%7Chuaimo.chen%40futurewei.com%7C434b7ffeba034a05e78408d822a4f7d2%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637297439231224552&amp;sdata=SmHFx7UDDZGg15NdjPtjkGsRQuweyNiH1Xr9X93yvgo%3D&amp;reserved=0

rfc2119>

non-rfc2119>

[HC]: We have updated the document according to rfc2119 as you suggested.

[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.
There is a PCE responsible for each of these domains.
The PCE for the ingress domain is called ingress PCE.
The PCE for the egress domain is called egress PCE.
The state of the LSP MUST be synchronized among these PCEs.

After a path for the LSP is computed, a PCRpt message with the
scheduled LSP inforamtion MUST be sent to every PCE along the path
from the ingress PCE to the egress PCE.
After receiving the PCRpt message,
the PCE MUST update its SLSP-DB according to the scheduled LSP inforamtion.

The ingress PCE acting as a PCC sends its next hop PCE the PCRpt message.
After receiving the PCRpt message, the next hop PCE acting as a PCC sends
its next hop PCE the PCRpt message. This continues until the egress
PCE receives the PCRpt message.

[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.

[HC]: Yes. We have changed it to use normative language, and
recommended Network Time Protocol [RFC5905] for time synchronization.

[HC]: We have moved it to Normative reference section.

[HC]: We have revalidated them and removed the unnecessary ones.

[HC]: We have changed it as you suggested.

[HC]: We have added a forward reference to the TLV.

[HC]: We have changed SHOULD to MUST.

[HC]: We have changed "is required to" to MUST

[HC]: We have indicated the specific TLV in the message.

[HC]: During. We have changed it to During.

[HC]: We have removed the first "defined in [RFC8231]".

[HC]: We have updated the text.

[HC]: You are right. We have added the text to state that it MUST be ignored.

[HC]: It SHOULD be "this LSP has scheduled parameters".
We have changed it accordingly.

[HC]: We have changed it to "SCHED-LSP-ATTRIBUTE TLV".

[HC]: We have changed can to MUST.

[HC]: We have rephrased it as you suggested.

[HC]: The receiver ignores the TLV. We have added the text about this.

[HC]: We have added details in version 20.

[HC]: We have addressed this in version 20.
The same space (32 bits) is used for grace period or elastic range.
A flag G-bit is defined to indicate which one is stored in the space.
G=1: the space stores the Grace period.
G=0: the space stores elastic range.

[HC]: The receiver ignores the TLV. We have added the text about this.

[HC]: We have removed it.

[HC]: We have changed it to "unknown Opt value".

(24) Nits:

s/ask PCC/ask the PCC

s/Options =/Opt =

[HC]: We have changed all the related text accordingly.

---

From: Alvaro Retana <[email-masked]>
Date: Tue, 21 Jul 2020 11:35:52 -0400

On July 13, 2020 at 3:29:13 PM, Huaimo Chen wrote:

Huaimo:

Hi!

...
> I think that this document still needs work before publication. I consider
> the first 3 points below to be close to DISCUSS-worthy.
>
...
> [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
> 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.
>
...

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.

> 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
> other PCE as described in [RFC8231]". But this last point is what I can't
> find in rfc8231.
>

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?

> recommended Network Time Protocol [RFC5905] for time synchronization.

The reference should be Normative.

Thanks!

Alvaro.

---

From: Dhruv Dhody <[email-masked]>
Date: Wed, 22 Jul 2020 09:54:48 +0530

Hi Huaimo, Alvaro,

<snip>
> good idea at this point.  It also leaves the single domain case

I suggested making these changes in section 4.1 -

   In case of multiple PCEs within a single domain, the PCE would need
   to synchronize their scheduling information with other PCEs
   within the domain. This could be achieved by proprietary database
   synchronization techniques or via a possible PCEP extension
   [I-D.litkowski-pce-state-sync]. The technique used to synchronize
   SLSP-DB is out of scope for this document.

Also, update section 4.3 with -

   o  The stateful PCE MUST update its local scheduled LSP-DB and
      scheduled TED with the scheduled LSP and synchronize the
      scheduling information with other PCEs in the domain.

> Is it specified somewhere else?

In this case, the right reference is draft-litkowski-pce-state-sync to
synchronize between PCEs using PCRpt/PCUpd.

My suggestion would be to change the text in Section 6.1 (version -19)
OLD:
   This message is also used
   to synchronize the scheduled LSPs to other PCE as described in
   [RFC8231]
NEW:
   This message could also be used
   to synchronize the scheduled LSPs to other PCE as described in
   [I-D.litkowski-pce-state-sync].
END

I can even live with removing the text completely.

BTW, just for information - PCE acting as PCC and using PCReq message
towards other PCEs goes back to RFC 5441. RFC 8751 has a child PCE
acting as PCC and sending PCRpt messages to parent PCE. But that has
no bearing on the fate of the above text.

Thanks,
Dhruv

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 22 Jul 2020 04:00:29 -0700

On July 22, 2020 at 12:25:00 AM, Dhruv Dhody wrote:

Dhruv:

Hi!

...
> > > (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.
> > >

Those changes are ok.

If no normative reference will be included, then I would still like to
see a discussion about the effects of not synchronizing, in this
specific case.  The text in rfc7399 is general.

> > > 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.
> > >

This goes back to the initial point: should
draft-litkowski-pce-state-sync be the normative reference?  If not,
then I think it is best to leave the details out.

> I can even live with removing the text completely.

If removing it, since the suggestion above is not leave sync
completely out of scope, then remove all other talk about PCRpt...

> no bearing on the fate of the above text.

No it doesn't.  But if there is a reference to include...

In the end, my interest here is for the specification to be complete.
If sync is out of scope then leave it out -- and better discuss the
effects of not properly sync'ing.  If it can be specified here (or
normatively pointed at), then please do it.  :-)

Thanks!

Alvaro.

---

From: Huaimo Chen <[email-masked]>
Date: Wed, 22 Jul 2020 18:18:42 +0000

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-masked]>
Sent: Tuesday, July 21, 2020 11:35 AM
To: Alvaro Retana via Datatracker <[email-masked]>; The IESG <[email-masked]>
Cc: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [Pce] Alvaro Retana's No Objection on draft-ietf-pce-stateful-pce-lsp-scheduling-19: (with COMMENT)

Huaimo:

Hi!

...
...

[HC2]: We will reread through the document carefully for "loose language" and
update it accordingly.

...

[HC2]: We will update the text according to Dhruv's suggestion.

[HC2]:  RFC 8751 has a child PCE acting as PCC and
sending PCRpt messages to its parent PCE.

[HC2]: We will move it to Normative References

Thanks!

Alvaro.

---

From: Huaimo Chen <[email-masked]>
Date: Wed, 22 Jul 2020 18:27:05 +0000

Hi Dhruv,

    Thank you very much for your valuable suggestions.
    We will update the document accordingly. Details are inline below with prefix [HC2].

Best Regards,
Huaimo
________________________________
From: Dhruv Dhody <[email-masked]>
Sent: Wednesday, July 22, 2020 12:24 AM
To: Alvaro Retana <[email-masked]>
Cc: Alvaro Retana via Datatracker <[email-masked]>; The IESG <[email-masked]>; pce-chairs <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [Pce] Alvaro Retana's No Objection on draft-ietf-pce-stateful-pce-lsp-scheduling-19: (with COMMENT)

Hi Huaimo, Alvaro,

<snip>

[HC2]: We will update the related text as you suggested.

[HC2]: We will remove the text completely.

[HC2]: Thanks much for the information.

Thanks,
Dhruv