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

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Jon,

On Wed, Oct 4, 2017 at 8:48 AM, Jonathan Hardwick <
[e-mail]> wrote:

> 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>"
>

I'd clear based on an update that heads this direction. Want to let me know
when the working group has had a chance to review the proposed text?

And thanks.

Spencer


> 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.
>
>
>