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

[Alvaro Retana <[e-mail]>]

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

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.




> > > §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?
> >
>
> In this case, the right reference is draft-litkowski-pce-state-sync to
> synchronize between PCEs using PCRpt/PCUpd.

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.


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

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


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

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.