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

[Dhruv Dhody <[e-mail]>]

Hi Huaimo, Alvaro,

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


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

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