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

[Jonathan Hardwick <[e-mail]>]

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.