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 - inami...@google.com:
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.
_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
