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 protected]>
Sent: Wednesday, July 22, 2020 12:24 AM
To: Alvaro Retana <[email protected]>
Cc: Alvaro Retana via Datatracker <[email protected]>; The IESG <[email protected]>;
pce-chairs <[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)
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.
[HC2]: We will update the related text as you suggested.
>
> > §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.
[HC2]: We will remove 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.
[HC2]: Thanks much for the information.
Thanks,
Dhruv
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
