Spencer Dawkins has entered the following ballot position for draft-ietf-pce-pce-initiated-lsp-10: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pce-pce-initiated-lsp/ ---------------------------------------------------------------------- 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. ---------------------------------------------------------------------- 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 … _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
