Subject: [Pce] Spencer Dawkins' Discuss on draft-ietf-pce-pce-initiated-lsp-10: (with DISCUSS and COMMENT)

From: Spencer Dawkins <[email-masked]>
Date: Sun, 27 Aug 2017 17:16:51 -0700

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 …