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. _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
