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

[Robert Varga <[e-mail]>]

On 02/01/2016 02:36 PM, Julien Meuric wrote:
> Hi Robert.
>

Hello Julien,

> Thank you for your help to move this forward. Please find my comments 
> below [JM]. Note that a couple of your answers are not aligned with 
> the proposed resolutions currently included the I-D: I was fine with 
> these, therefore please make sure you are so that I can send to the IESG.
>

please see inline, I am pruning the items we have converged on...

> Julien
>
>
> Jan. 18, 2016 - [e-mail]:
[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
>>
>> The association between a PCEP session and PCE processes is something 
>> which I would consider an internal PCE detail, and it should be 
>> covered by the next sentence (e.g. raise PCErr 20/1).
> [JM] I still feel unwise to consider a lack of feedback as a proof of 
> synchronization. What if, from time to time, a PCRpt gets lost? I do 
> not think acknowledgement would be a pain to add, but its lack can 
> easily turn to that in operational situations.

The assumption here is that PCEP runs on top of TCP, so no PCRpts get 
lost on the network without also losing the session. The procedures for 
validating that the session is in fact synchronized (possibly on a 
periodic basis) are part of draft-ietf-pce-stateful-sync-optimizations. 
I think we can add some text around that.

>>>     - In section 5.5.1, it is not clear if an empty LSP Update
>>>     Request with a Delegate flag to 1 is an acceptable way for a PCE
>>>     to send a delegation acknowledgement: to be clarified.
>>>
>>> ### XXX Pending
>>
>> It is not, as that would be seen as a request to modify the LSP setup 
>> to empty. Such an acknowledgement would have to include full 
>> configuration as previously reported -- which would be handled as a 
>> normal update.
> [JM] The I-Ds says the contrary: to be checked. Note that empty could 
> be loose, which seems possible to handle at the signaling level.

I think this is clarified in -13 (section 5.7).

>
>>>     - The behavior associated to the resource limit per PCC rather
>>>     looks like a Notifcation than an Error (e.g., in RFC 5440,
>>>     cancelling a set of pending requests relies on PCNtf). Please
>>>     consider the use of Notification instead of Error here.
>>>
>>> ### XXX Pending
>>
>> Current wording is based on the assumption that the PCE has to have a 
>> consistent point-in-time view of the PCC's state. In this regard a 
>> PCRpt of a new LSP which exceeds PCE implementation-internal limit on 
>> the number of LSPs it supports would break that assumption, hence we 
>> chose PCErr. This makes it consistent with what would happen if that 
>> LSP is reported during initial state resynchronization.
> [JM] Please note that the current I-D uses "PCNtf", and I am fine with 
> that resolution. I was not questioning the expected behavior, which 
> must remain. I was just suggesting the expected type of message to be 
> consistent with RFC 5440: the PCC has not made anything wrong, it is 
> informed that the PCE no more accepts its reports similarly to the way 
> a PCE is able to tell about overload or cancel some requests.

I'll try to re-read the entire thing and report back.

>
>>>     - It would be nice to elaborate on the reason why the
>>>     SYMBOLIC-PATH-NAME MUST be included and not SHOULD.
>>>     - I do not see why SYMBOLIC-PATH-NAME may be included in SRP
>>>     Object: defining the LSP Object as its single place seems enough
>>>     and much simpler.
>>>
>>>
>>> ### XXX  Pending
>>
>> The MUST is there to maintain a single global identifier for the LSP. 
>> PLSP-ID is then used as a shorthand. I do not recollect the exact 
>> reasoning as to why the TLV can be in SRP, as the placement and 
>> semantics of that TLV has changed quite a bit over the past couple of 
>> years. If I were to venture a guess, I think it was retrofitted to 
>> allow the PCE to update the symbolic path name.
> [JM] OK about the "MUST". About SYMBOLIC-PATH-NAME in SRP, please 
> choose: either it is legacy and must be dropped (current version), or 
> there is a reason and it must be documented in the I-D.

It was introduced in -05 revision with the SRP object. We'll dig in 
history some more to see where this came from.

Bye,
Robert