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