Re: [Pce] Chair's Review of draft-ietf-pce-stateful-pce-11

[Julien Meuric <[e-mail]>]

Hi Ina,

Thank you for publishing the update. It looks like most comments are 
incorporated. Just a few remain open, see [JM] below.

Cheers,

Julien


Dec. 03, 2015 - [e-mail]:
> All the changes discussed in this thread have been incorporated in 
> version 13 published yesterday
>
> https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-13
>
> Thank you,
>
> Ina
>
>
>     <snip>
>
>
>             - Avoiding "positive acknowledgements for properly received
>             synchronization messages" has scalability benefits in normal
>             situations, but the PCC is blind and may keep on sending
>         PCRpt to
>             dead processes behind up PCEP sessions. Have you consider
>             acknowledgement, possibly using a compression mechanism
>         like the
>             one defined later in the I-D?
>
>         ### XXX Pending
>
> %%%  No, we did not think we needed positive acks because we are using 
> a TCP session (guaranteed delivery all the way to the PCE).
>
[JM] Yes, leaving the man in the middle case apart, we almost agree on 
that, but I believe it is not enough. Even if PCEP and TCP stacks are 
OK, the PCC still cannot know if the PCRpt has been processed by the PCE 
and/or properly stored in its DB. E.g., how can the PCC distinguish 
between the expected processing and a PCE considering some message as 
wrongly formed while not supporting the relevant error message?


<snip>


           - In section 5.5.3, assuming an LSP was delegated, does the
             reception by the PCC of a non empty LSP Update Request with a
             Delegate Flag to 0 trigger an error?

        ### XXX Pending

%%% No, this is a delegation return. I cleaned up the text, see below.

In order to keep a delegation, a PCE MUST set the Delegate flag to 1
    on each LSP Update Request sent to the PCC.  A PCE that no longer
    wishes to update an LSP's parameters SHOULD return the LSP delegation
    back to the PCC by sending an empty LSP Update Request which has the
    Delegate flag set to 0.  If a PCC receives a non-empty LSP Update
    Request with the Delegate flag set to 0, it MUST treat this as a
    delegation return.

[JM] That is quite difficult to fully understand. Delegation returns <=> 
flag set to 0 seems clear. But why are "empty" associated to "SHOULD" 
and "non-empty" to MUST? Rewording is required to make sure all 
sub-cases are covered.


>     <snip>
>
>
>             - In section 5.6.2, in case of new LSP, the very first message
>             sent by the PCC aims at getting a path. This is clearly
>         the role
>             of a PCReq message, and the I-D extends it to support the LSP
>             object including the delegation flag (section 7.3). However,
>             Figure 8 treats a new LSP the same way as reporting an
>         existing
>             LSP, i.e., using a PCRpt message. In this case, there is an
>             overlap between PCReq and PCRpt, which MUST be resolved
>         because
>             interoperability is at stake. Documenting the delegation
>         of a new
>             LSP deserves some new text and possibly figure, the
>         overlapping
>             specification of the PCRpt should be explicitly precluded.
>
>         ### This is historical confusion in the figure, from the time
>         when initiation was rolled up in the same document. I modified
>         the figure so it is clear this is for updating parameters only.
>
>      [JM] Seems addressed. Just to be confirmed when published and to
>     confront with draft-ietf-pce-pce-initiated-lsp.
>
[JM] Reading the new section 6.1, the <intended_path>/ERO being 
mandatory, the case of an empty ERO should be documented. I believe 
adding an error code to handle it would be enough.