Hi Spencer Many thanks for these comments. I'm picking up this thread and replying as PCE working group chair, as the authors are unavailable. I am very sorry for the delay.
Please see my proposed resolutions inline below, marked with "Jon>" Best regards Jon <snip> ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This ballot position would be Please Educate Me, if that was a choice, but that's not a choice. I'm sure we can clear this quickly. And I found this document very easy to read as a reviewer - thanks for that. I found a couple of places where SHOULDs seemed at least under-specified, and this one looked important. In this text, LSP State Synchronization procedures are described in section 5.4 of [I-D.ietf-pce-stateful-pce]. During State Synchronization, a PCC reports the state of its LSPs to the PCE using PCRpt messages, setting the SYNC flag in the LSP Object. For PCE-initiated LSPs, the PCC MUST also set the Create Flag in the LSP Object and MAY include the SPEAKER-ENTITY-ID TLV identifying the PCE that requested the LSP creation. At the end of state synchronization, the PCE SHOULD compare the reported PCE-Initiated LSPs with its configuration. For any mismatch, the PCE SHOULD send a PCInitiate message to initiate any missing LSPs and/or remove any LSPs that are not wanted. I’m having a hard time understanding why a PCE would not compare reported PCE-Initiated LSPs with its configuration, which is allowed by the first SHOULD. Does that mean you thought it was important to TRY to synchronize, but you’re not curious enough to check whether that worked? I can imagine reasons why you wouldn't try to fix the LSPs that weren't synchronized, at least not immediately, but you might also give guidance about one or more reasons why you wouldn't try, to help implementers understand what not doing what the SHOULD means, and make informed choices for their implementations. Jon> I definitely agree with you that, having received a snapshot from the PCC, there is no reason that the PCE would not then compare the PCC's state with its local copy i.e. the first SHOULD ought to be a MUST. The intention of the second SHOULD was to leave the PCE with some flexibility for dealing with clients that are out of sync. For example, perhaps the clients are slow, or perhaps the operator's policy is to prefer not to disrupt existing flows so long as the main characteristics of the flows are correct. These are just my invented examples, but we expect there might be valid operational reasons along these lines, so we wanted to the draft to allow the server the flexibility to choose whether it updates the flows, or not. Here is my proposed fix. OLD == as quoted above === NEW LSP State Synchronization procedures are described in section 5.4 of [RFC8231]. During State Synchronization, a PCC reports the state of its LSPs to the PCE using PCRpt messages, setting the SYNC flag in the LSP Object. For PCE-initiated LSPs, the PCC MUST also set the Create Flag in the LSP Object and MAY include the SPEAKER-ENTITY-ID TLV identifying the PCE that requested the LSP creation. At the end of state synchronization, the PCE MUST compare the reported PCE-Initiated LSPs with its configuration. For any mismatch, the PCE SHOULD send a PCInitiate message to initiate any missing LSPs and/or remove any LSPs that are not wanted. Under some circumstances, depending on the deployment, it might be preferable for a PCE not to send this PCInitiate immediately, or at all. For example, the PCC may be a slow device, or the operator might prefer not to disrupt active flows. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In this text, The State Timeout Interval timer ensures that a PCE crash does not result in automatic and immediate disruption for the services using PCE-initiated LSPs. PCE-initiated LSPs are not removed immediately upon PCE failure. Instead, they are cleaned up on the expiration of this timer. This allows for network cleanup without manual intervention. The PCC SHOULD support removal of PCE-initiated LSPs as one of the behaviors applied on expiration of the State Timeout Interval timer. The behavior SHOULD be picked based on local policy, and can result either in LSP removal, or in reverting to operator- defined default parameters. I found myself wondering why “The PCC SHOULD support removal of PCE-initiated LSPs” is a SHOULD, and not a MUST, but if it’s a SHOULD, you might say something about the effects of not supporting this, in order to help implementers make an informed decision about whether to support it. In the same text, I found myself wondering if there were other alternatives to local policy for the last SHOULD, which is, of course, the last stop on the way to asking why this isn’t a MUST … Jon> I agree that both of these statements ought to say MUST. I don't believe there are other alternatives for the local policy. _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
