Hi Robert, (snip)
Hello, donning the implementer (as opposed to co-author) hat, I have comments pertaining to draft-ietf-pce-pce-initiated-lsp, specifically to Section 6. In general it seems to contradict the general outline of the extension as stated in section 3.2 paragraph 4. The first paragraph clearly forbids the use of PCRpt D=0 for PCE- initiated LSPs. It is not clear whether this restriction applies to all PCRpts, or only the PCRpt solicited by the PCInitiate message. Section 3.2 paragraph 4 seems to indicate this applies to solicited PCRpts only, which is what makes sense. A clarification is definitely needed. But http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-10#section-5.5.1 says.. Note that for an LSP to remain delegated to a PCE, the PCC MUST set the Delegate flag to 1 on each LSP Status Report sent to the PCE. So the D flag must be set on all PCRpts (including the solicited (first) PCRpt and any other PCRpt message). Right, but that would also mean that a PCE-initiated LSP cannot be reported to backup PCEs, as that would mean the LSP is delegated to multiple PCEs at the same time... [Dhruv]: A clarification that one is referring to the PCE that initiated the LSP in the paragraph should clear that up. I am not sure what text in section 3.2 paragraph 4 is an issue? The specific text is this: Once instantiated, the delegation procedures for PCE-initiated LSPs are the same as for PCC initiated LSPs as described in [I-D.ietf-pce-stateful-pce<https://tools.ietf.org/html/draft-ietf-pce-pce-initiated-lsp-02#ref-I-D.ietf-pce-stateful-pce>]. This applies to the case of a PCE failure as well. Which is precisely what I understand you are implying in your response below. [Dhruv]: The third paragraph seems to be replacing the normal delegation mechanics with a PCInitiate-driven exchange. It does not specify whether it is legal for a PCE to send PCUpd(D=1) after a session flap or not. It feels like it is not legal and PCInitiate is intended to fully replace it, but that would contradict section 3.2 paragraph 4. This needs to be clarified. I think some clarification is needed. The text says.. In case of PCEP session failure, control over PCE-initiated LSPs reverts to the PCC at the expiration of the redelegation timeout. To obtain control of a PCE-initiated LSP, a PCE (either the original or one of its backups) sends a PCInitiate message, including just the SRP and LSP objects, and carrying the PLSP-ID of the LSP it wants to take control of. During state synchronization itself (full or incremental) the D flag could be set while reporting the status of PCE-Initiated LSP (with C flag set) if re-delegation is not done to another PCE. I feel the same behavior make sense for PCC-Initiated LSP as well incase one wants to delegate to the same PCE again after session down. It should not be mandatory to send PCInitiage message in all cases. Regards, Dhruv Bye, Robert My preference would be to remove pretty much all of this paragraph, bringing the mechanics to what section 3.2 outlines. Unfortunately there are already some implementations deployed, so we need to factor in the compatiblity with the installed base. Can we perhaps allocate another bit in the Stateful PCE Capability TLV and mark the current one as reserved/deprecated? Thanks, Robert On 12/01/2014 06:18 PM, julien.meu...@orange.com<mailto:julien.meu...@orange.com> wrote: Dear all, As planned, this message ignites a 3-week WG Last Call on both draft-ietf-pce-pce-initiated-lsp-02 and draft-ietf-pce-stateful-sync-optimizations-01. It will end on Monday December 22 at 11:59 PM, HST. Please send your comments to the PCE mailing list. Thanks, JP & Julien _____________________________________________________________________ _ ___________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ Pce mailing list Pce@ietf.org<mailto:Pce@ietf.org> https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@ietf.org<mailto:Pce@ietf.org> https://www.ietf.org/mailman/listinfo/pce
_______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
