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

Mon, 01 Feb 2016 10:30:15 -0800 

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 - [email protected]:

[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

_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce

Reply via email to