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

From: Ina Minei <[email-masked]>
Date: Mon, 2 May 2016 09:02:53 -0700

Julien,

Not sure where this draft stands now after the latest revisions which were
posted more than a month ago. Is there anything else needed from the
authors?

Thank you,

Ina

On Mon, Feb 1, 2016 at 10:29 AM, Robert Varga <[email-masked]> wrote:

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

---

From: Julien Meuric <[email-masked]>
Date: Tue, 3 May 2016 12:33:17 +0200

Hi Ina,

The status is the following:
- There used to be a couple of mismatches between Robert's comments and 
the wording of the I-D: if he is fine with the latest update, we are good;
- A parallel thread about stateless PCE has grown up to tackle an issue 
to be addressed as a comment on this I-D: it is now useful to have the 
authors joining that part of the discussion to reach a consensus on the 
resolution 
(https://mailarchive.ietf.org/arch/msg/pce/_ih3NcDK2_iy8xSHcquzm-q_2bs);
- With PCEPS I-D getting close to IANA, Jon refreshed the codepoint 
early allocation proposal not so long ago 
(https://mailarchive.ietf.org/arch/msg/pce/Jg2f8AGa9ZpVZup13YWzTHwkUD8): 
a feedback of stateful I-Ds' authors on that action would be welcome.

Thank you,

Julien

May. 02, 2016 - [email-masked]:
> Julien,
>
> Not sure where this draft stands now after the latest revisions which 
> were posted more than a month ago. Is there anything else needed from 
> the authors?
>
> Thank you,
>
> Ina
>
> On Mon, Feb 1, 2016 at 10:29 AM, Robert Varga <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>>     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.
>>
>
>>     Jan. 18, 2016 - [email-masked] <mailto:[email-masked]>:
>     [snip]
>>>>
>>>>         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
>>>     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.
>
>>>>         - 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
>>     [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.
>
>>>>         - 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
>
>